On 28 March 2017 at 02:25, Andres Freund <and...@anarazel.de> wrote: > On 2017-03-28 04:12:41 +0300, Stas Kelvich wrote: >> >> > On 28 Mar 2017, at 00:25, Andres Freund <and...@anarazel.de> wrote: >> > >> > Hi, >> > >> > On 2017-03-28 00:19:29 +0300, Stas Kelvich wrote: >> >> Ok, here it is. >> > >> > On a very quick skim, this doesn't seem to solve the issues around >> > deadlocks of prepared transactions vs. catalog tables. What if the >> > prepared transaction contains something like LOCK pg_class; (there's a >> > lot more realistic examples)? Then decoding won't be able to continue, >> > until that transaction is committed / aborted? >> >> But why is that deadlock? Seems as just lock. > > If you actually need separate decoding of 2PC, then you want to wait for > the PREPARE to be replicated. If that replication has to wait for the > to-be-replicated prepared transaction to commit prepared, and commit > prepare will only happen once replication happened...
Surely that's up to the decoding plugin? If the plugin takes locks it had better make sure it can get the locks or timeout. But that's true of any resource the plugin needs access to and can't obtain when needed. This issue could occur now if the transaction tool a session lock on a catalog table. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
