On 2017-03-28 03:30:28 +0100, Simon Riggs wrote: > 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?
It can't do much about it, so not really. A lot of the functions dealing with datatypes (temporarily) lock relations. Both the actual user tables, and system catalog tables (cache lookups...). > 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. That's not a self deadlock, and we don't don't do session locks outside of operations like CIC? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
