On Tue, Aug 06, 2013 at 09:06:59AM +0200, Andres Freund wrote: > On 2013-08-05 13:09:31 -0400, Noah Misch wrote: > > When we call AtEOSubXact_Inval() or AtEOXact_Inval() with a relation still > > open, we can potentially get a relcache rebuild and therefore a syscache > > lookup as shown above. CommitSubTransaction() is also potentially affected, > > though I don't have an SQL-level test case for that. It calls > > CommandCounterIncrement() after moving to TRANS_COMMIT. That CCI had better > > find no invalidations of open relations, or we'll make syscache lookups. > > (In > > simple tests, any necessary invalidations tend to happen at the CCI in > > CommitTransactionCommand(), so the later CCI does in fact find nothing to > > do. > > I have little confidence that should be counted upon, though.) > > > How might we best rearrange things to avoid these hazards? > > Ok. After a good bit of code reading, I think this isn't an actual bug > but an overzealous Assert(). I think it should be > Assert(IsTransactionBlock()) not Assert(IsTransactionState());
IsTransactionBlock() is for higher-level things that care about actual use of BEGIN. It's false in the middle of executing a single-statement transaction, but that's of course a perfectly valid time for syscache lookups. > The reason for that is that when we do the AtEO(Sub)?Xact_Inval(), we've > already done a RecordTransactionAbort(true|false) and > CurrentTransactionState->state = TRANS_ABORT. So the visibility routines > have enough information to consider rows created by the aborted > transaction as invisible. > > I am not really happy with the RelationReloadIndexInfo()s in > RelationClearRelation() when we're in an aborted state, especially as > the comment surrounding them are clearly out of date, but I don't see a > bug there anymore. Interesting. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers