I'm working on fixing the stale-toast-pointer problem discussed in
http://archives.postgresql.org/message-id/2348.1319591170@sss.pgh.pa.us
In that thread, it was pointed out that it's unsafe to fetch a toasted
value unless we are advertising a MyProc->xmin that's old enough to
prevent removal of the tuple holding the toast pointer. Otherwise,
someone could commit a deletion of that tuple and its subsidiary toast
tuples after we decide it's good, and then VACUUM could remove the toast
tuples before we finish fetching the toast tuples. I tried to add an
Assert that at least checks that we're advertising *some* xmin at the
start of toast_fetch_datum():
Assert(TransactionIdIsNormal(MyProc->xmin));
The regression tests run through without complaint with this in place,
but initdb blows up while processing system_views.sql. I found that the
problem is that exec_simple_query() issues a CommandCounterIncrement
between queries while not holding any snapshot. (exec_simple_query
itself doesn't take one because the queries are all utility commands,
ie CREATE VIEW. PortalRunUtility does take a snapshot while running
CREATE VIEW, but then drops it again.) This causes a relcache flush
and reload for the just-created view (since it was just created,
RelationFlushRelation tries to rebuild not just drop the relcache
entry). If the view's rule is long enough to be toasted, boom!
Now, in fact this access pattern is perfectly safe, because if the view
was created in the current transaction then there's no way for VACUUM to
remove the tuples describing it. The whole thing seems rather delicate,
and yet I can't put my finger on anyplace that's doing something wrong.
I'm going to commit the patch without this Assert, but I wonder if
anyone has ideas about either a better test for dangerous fetches,
or a way to rejigger the code to make this test work.
regards, tom lane