> 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. In case of prepared lock of pg_class decoding will wait until it committed and then continue to decode. As well as anything in postgres that accesses pg_class, including inability to connect to database and bricking database if you accidentally disconnected before committing that tx (as you showed me some while ago :-). IMO it is issue of being able to prepare such lock, than of decoding. Is there any other scenarios where catalog readers are blocked except explicit lock on catalog table? Alters on catalogs seems to be prohibited. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
