database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-08 07:21:33 +03:00
Code

Doc: Update the documentation for row movement behavior across partitions.

Browse Source 
In commit f16241bef7c, we have changed the behavior for concurrent updates
that move row to a different partition, but forgot to update the docs.
Previously when an UPDATE command causes a row to move from one partition
to another, there is a chance that another concurrent UPDATE or DELETE
misses this row.  However, now we raise a serialization failure error in
such a case.

Reported-by: David Rowley
Author: David Rowley and Amit Kapila
Backpatch-through: 11 where it was introduced
Discussion: https://postgr.es/m/CAKJS1f-iVhGD4-givQWpSROaYvO3c730W8yoRMTF9Gc3craY3w@mail.gmail.com
This commit is contained in:
Amit Kapila 2019-02-07 09:02:45 +05:30
parent 2f54166668
commit d850af428d
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
doc/src/sgml/ddl.sgml
View File

@ -3359,19 +3359,19 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
<para>
When an <command>UPDATE</command> causes a row to move from one
partition to another, there is a chance that another concurrent
<command>UPDATE</command> or <command>DELETE</command> misses this row.
Suppose session 1 is performing an <command>UPDATE</command> on a
partition key, and meanwhile a concurrent session 2 for which this row
is visible performs an <command>UPDATE</command> or
<command>DELETE</command> operation on this row. Session 2 can silently
miss the row if the row is deleted from the partition due to session
1's activity. In such case, session 2's
<command>UPDATE</command> or <command>DELETE</command>, being unaware of
the row movement thinks that the row has just been deleted and concludes
that there is nothing to be done for this row. In the usual case where
the table is not partitioned, or where there is no row movement,
session 2 would have identified the newly updated row and carried out
the <command>UPDATE</command>/<command>DELETE</command> on this new row
<command>UPDATE</command> or <command>DELETE</command> will get a
serialization failure error. Suppose session 1 is performing an
<command>UPDATE</command> on a partition key, and meanwhile a concurrent
session 2 for which this row is visible performs an
<command>UPDATE</command> or <command>DELETE</command> operation on this
row. In such case, session 2's <command>UPDATE</command> or
<command>DELETE</command>, will detect the row movement and raise a
serialization failure error (which always returns with an SQLSTATE code
'40001'). Applications may wish to retry the transaction if this
occurs. In the usual case where the table is not partitioned, or where
there is no row movement, session 2 would have identified the newly
updated row and carried out the
<command>UPDATE</command>/<command>DELETE</command> on this new row
version.
</para>
</listitem>