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

Commitd850af4

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 parent2f54166 commitd850af4

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
@@ -3359,19 +3359,19 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
33593359
<para>
33603360
When an <command>UPDATE</command> causes a row to move from one
33613361
partition to another, there is a chance that another concurrent
3362-
<command>UPDATE</command> or <command>DELETE</command>misses this row.
3363-
Suppose session 1 is performing an <command>UPDATE</command> on a
3364-
partition key, and meanwhile a concurrent session 2 for which this row
3365-
is visible performs an <command>UPDATE</command> or
3366-
<command>DELETE</command> operation on this row. Session 2 can silently
3367-
miss therow if the row is deleted from the partition due to session
3368-
1's activity. In such case, session 2's
3369-
<command>UPDATE</command> or <command>DELETE</command>, being unaware of
3370-
the row movement thinks that the row has just been deleted and concludes
3371-
that there is nothing to be done for this row. In the usual case where
3372-
the tableisnot partitioned, or where there is no row movement,
3373-
session 2 would have identified the newlyupdated row and carried out
3374-
the<command>UPDATE</command>/<command>DELETE</command> on this new row
3362+
<command>UPDATE</command> or <command>DELETE</command>will get a
3363+
serialization failure error.Suppose session 1 is performing an
3364+
<command>UPDATE</command> on apartition key, and meanwhile a concurrent
3365+
session 2 for which this rowis visible performs an
3366+
<command>UPDATE</command> or <command>DELETE</command> operation on this
3367+
row. In such case, session 2's <command>UPDATE</command> or
3368+
<command>DELETE</command>, will detect the row movement and raise a
3369+
serialization failure error (which always returns with an SQLSTATE code
3370+
'40001'). Applications may wish to retry the transaction if this
3371+
occurs. In the usual case where the table is not partitioned, or where
3372+
thereisno row movement, session 2 would have identified the newly
3373+
updated row and carried out the
3374+
<command>UPDATE</command>/<command>DELETE</command> on this new row
33753375
version.
33763376
</para>
33773377
</listitem>

0 commit comments

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