Re: mvcc catalo gsnapshots and TopTransactionContext - Mailing list pgsql-hackers

From Tom Lane
Subject Re: mvcc catalo gsnapshots and TopTransactionContext
Date
Msg-id 1240.1391727022@sss.pgh.pa.us
Whole thread Raw
In response to Re: mvcc catalo gsnapshots and TopTransactionContext  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> (BTW, I see that the CLOBBER_CACHE_ALWAYS members of the buildfarm are
> unhappy with the IsTransactionState check in RelationIdGetRelation.
> Will look at that ... but it seems to be in initdb which breaks a lot
> of these rules anyway, so I think it's probably not significant.)

So what's happening is that in bootstrap mode, we run each BKI command
in a separate transaction.  (Since these transactions all use the same
XID, it's not clear what's the point of doing that rather than running
the whole BKI script as one transaction.  But it's been like that for
twenty years so I'm disinclined to mess with it.)  Bootstrap mode is
peculiar in that it expects relcache entries to stay open across these
"transactions", which we implement by keeping their refcnts positive.
Throwing CLOBBER_CACHE_ALWAYS into the mix means we do a relcache flush
during transaction start, during which RelationClearRelation tries to
rebuild the cache entries right away because they have positive refcnt,
triggering the Assert because it has to access system relations such as
pg_class and we're not in TRANS_INPROGRESS state yet.

So in short, the patch I proposed upthread fixes this, since it postpones
the actual cache entry reload into the main part of the transaction.

So rather than lobotomize that Assert with an IsBootstrapMode exception,
I think I'll just go ahead and commit this patch, with the cleanups
we discussed earlier.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Recovery inconsistencies, standby much larger than primary
Next
From: Tom Lane
Date:
Subject: Re: mvcc catalo gsnapshots and TopTransactionContext