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