On Sunday, June 24, 2012 11:37:26 PM Simon Riggs wrote: > On 24 June 2012 22:11, Andres Freund <and...@2ndquadrant.com> wrote: > > One interesting problem are table rewrites (truncate, cluster, some ALTER > > TABLE's) and dropping tables. Because we nudge SnapshotNow to the past > > view it had back when the wal record was created we get the old > > relfilenode. Which might have been dropped in part of the transaction > > cleanup... > > With most types thats not a problem. Even things like records and arrays > > aren't problematic. More interesting cases include VACUUM FULL $systable > > (e.g. pg_enum) and vacuum full'ing a table which is used in the *_out > > function of a type (like a user level pg_enum implementation).
> That's only a problem if you are generating changes to the relfilenode > rather than the relid. Hm. I can't follow so far. Could you paraphrase? > ISTM that this step differs depending upon whether we are generating > portable SQL, or whether we are generating changes for immediate > apply. I fear only generating changes for immediate, low-level apply is going to fly given the various interests people have voiced. > If it is the latter, then it should never actually happen because if a table > rewrite occurred and then committed we would never need to re-read earlier > WAL. > So treating this as a generic problem leads to some weird results that > we don't need to worry about cos they can't actually happen. Well, even if it were true that we don't need to worry about the state before a full-table rewritte - I don't think it is - we still need to be able to cope with CLUSTER or VACUUM FULL... Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
