I'm working on fixing the stale-toast-pointer problem discussed in http://archives.postgresql.org/message-id/2348.1319591...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers