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

Commitb4e3dc7

Browse files
author
Amit Kapila
committed
Update the docs and comments for decoding of prepared xacts.
Commita271a1b introduced decoding at prepare time in ReorderBuffer.This can lead to deadlock for out-of-core logical replication solutionsthat uses this feature to build distributed 2PC in case such transactionslock [user] catalog tables exclusively. They need to inform users to nothave locks on catalog tables (via explicit LOCK command) in suchtransactions.Reported-by: Andres FreundDiscussion:https://postgr.es/m/20210222222847.tpnb6eg3yiykzpky@alap3.anarazel.de
1 parent6148656 commitb4e3dc7

File tree

2 files changed

+38
-0
lines changed

2 files changed

+38
-0
lines changed

‎doc/src/sgml/logicaldecoding.sgml

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1228,5 +1228,29 @@ stream_commit_cb(...); <-- commit of the streamed transaction
12281228
that name pattern will not be decoded as a two-phase commit transaction.
12291229
</para>
12301230

1231+
<para>
1232+
The users that want to decode prepared transactions need to be careful about
1233+
below mentioned points:
1234+
1235+
<itemizedlist>
1236+
<listitem>
1237+
<para>
1238+
If the prepared transaction has locked [user] catalog tables exclusively
1239+
then decoding prepare can block till the main transaction is committed.
1240+
</para>
1241+
</listitem>
1242+
1243+
<listitem>
1244+
<para>
1245+
The logical replication solution that builds distributed two phase commit
1246+
using this feature can deadlock if the prepared transaction has locked
1247+
[user] catalog tables exclusively. They need to inform users to not have
1248+
locks on catalog tables (via explicit <command>LOCK</command> command) in
1249+
such transactions.
1250+
</para>
1251+
</listitem>
1252+
</itemizedlist>
1253+
</para>
1254+
12311255
</sect1>
12321256
</chapter>

‎src/backend/replication/logical/decode.c

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -362,6 +362,20 @@ DecodeXactOp(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
362362
break;
363363
}
364364

365+
/*
366+
* Note that if the prepared transaction has locked [user]
367+
* catalog tables exclusively then decoding prepare can block
368+
* till the main transaction is committed because it needs to
369+
* lock the catalog tables.
370+
*
371+
* XXX Now, this can even lead to a deadlock if the prepare
372+
* transaction is waiting to get it logically replicated for
373+
* distributed 2PC. Currently, we don't have an in-core
374+
* implementation of prepares for distributed 2PC but some
375+
* out-of-core logical replication solution can have such an
376+
* implementation. They need to inform users to not have locks
377+
* on catalog tables in such transactions.
378+
*/
365379
DecodePrepare(ctx,buf,&parsed);
366380
break;
367381
}

0 commit comments

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