Robert Haas <robertmh...@gmail.com> writes: > I like this feature a lot, but it's hard to imagine that any of the > fixes anyone has so far suggested can be implemented without > collateral damage. Nor is there any certainty that this is the last > bug.
And in fact, here's something else to worry about: consider pg_dump. pg_dump is pretty heavily reliant on backend catalog-interpretation code (such as ruleutils.c) that mostly runs on SnapshotNow time. But it also does a fair amount of work on the basis of its own inspection of the catalogs, which is done according to the serializable snapshot it gets at the beginning of the dump run. If these two views of a table's schema aren't consistent, you might get a pg_dump error, but it's at least as likely that you'll get a silently incorrect dump. pg_dump tries to minimize the risk by taking AccessShareLock right away on each table it's going to dump. This is not perfect but it at least results in a narrow window for conflicting table changes to occur. However, that strategy has been blown out of the water by the ALTER TABLE lock strength reduction. There is now a *very* wide window for concurrent ALTERs to occur and possibly break the dump results. As far as I can see, the only simple way to return pg_dump to its previous level of safety while retaining this patch is to make it take ShareUpdateExclusiveLocks, so that it will still block all forms of ALTER TABLE. This is rather unpleasant, since it will also block autovacuum for the duration of the dump. In the long run, we really ought to fix things so that ruleutils.c runs on the transaction snapshot, but that's a massive rewrite that is certainly not getting done for 9.1, and will likely result in considerable code bloat :-(. (BTW, I just noticed that dumpSchema does a pretty fair amount of work before it gets around to calling getTables, which is where said locks get taken. Seems like we'd better rearrange the order of operations there...) 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