Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit793c736

Browse files
author
Amit Kapila
committed
Doc: Update the documentation for row movement behavior across partitions.
In commitf16241b, we have changed the behavior for concurrent updatesthat move row to a different partition, but forgot to update the docs.Previously when an UPDATE command causes a row to move from one partitionto another, there is a chance that another concurrent UPDATE or DELETEmisses this row. However, now we raise a serialization failure error insuch a case.Reported-by: David RowleyAuthor: David Rowley and Amit KapilaBackpatch-through: 11 where it was introducedDiscussion:https://postgr.es/m/CAKJS1f-iVhGD4-givQWpSROaYvO3c730W8yoRMTF9Gc3craY3w@mail.gmail.com
1 parentf339a99 commit793c736

File tree

1 file changed

+13
-13
lines changed

1 file changed

+13
-13
lines changed

‎doc/src/sgml/ddl.sgml

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -3859,19 +3859,19 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
38593859
<para>
38603860
When an <command>UPDATE</command> causes a row to move from one
38613861
partition to another, there is a chance that another concurrent
3862-
<command>UPDATE</command> or <command>DELETE</command>misses this row.
3863-
Suppose session 1 is performing an <command>UPDATE</command> on a
3864-
partition key, and meanwhile a concurrent session 2 for which this row
3865-
is visible performs an <command>UPDATE</command> or
3866-
<command>DELETE</command> operation on this row. Session 2 can silently
3867-
miss therow if the row is deleted from the partition due to session
3868-
1's activity. In such case, session 2's
3869-
<command>UPDATE</command> or <command>DELETE</command>, being unaware of
3870-
the row movement thinks that the row has just been deleted and concludes
3871-
that there is nothing to be done for this row. In the usual case where
3872-
the tableisnot partitioned, or where there is no row movement,
3873-
session 2 would have identified the newlyupdated row and carried out
3874-
the<command>UPDATE</command>/<command>DELETE</command> on this new row
3862+
<command>UPDATE</command> or <command>DELETE</command>will get a
3863+
serialization failure error.Suppose session 1 is performing an
3864+
<command>UPDATE</command> on apartition key, and meanwhile a concurrent
3865+
session 2 for which this rowis visible performs an
3866+
<command>UPDATE</command> or <command>DELETE</command> operation on this
3867+
row. In such case, session 2's <command>UPDATE</command> or
3868+
<command>DELETE</command>, will detect the row movement and raise a
3869+
serialization failure error (which always returns with an SQLSTATE code
3870+
'40001'). Applications may wish to retry the transaction if this
3871+
occurs. In the usual case where the table is not partitioned, or where
3872+
thereisno row movement, session 2 would have identified the newly
3873+
updated row and carried out the
3874+
<command>UPDATE</command>/<command>DELETE</command> on this new row
38753875
version.
38763876
</para>
38773877
</listitem>

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp