On 2017-03-28 04:12:41 +0300, Stas Kelvich wrote:
>
> > On 28 Mar 2017, at 00:25, Andres Freund <andres@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...
> Is there any other scenarios where catalog readers are blocked except explicit lock
> on catalog table? Alters on catalogs seems to be prohibited.
VACUUM FULL on catalog tables (but that can't happen in xact => 2pc)
CLUSTER on catalog tables (can happen in xact)
ALTER on tables modified in the same transaction (even of non catalog
tables!), because a lot of routines will do a heap_open() to get the
tupledesc etc.
Greetings,
Andres Freund
