On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I believe that this is fundamentally unavoidable so long as we use > SnapshotNow to read catalogs --- which is something we've talked about > changing, but it will require a pretty major R&D effort to make it > happen. In the meantime, we have to go back to using > AccessExclusiveLock for table alterations. It doesn't help to have > a lower lock level if that means that concurrent transactions will > unpredictably fail instead of waiting.
Ouch. I wonder if we could avoid this anomaly by taking a throwaway MVCC snapshot at the beginning of each system catalog scan and using it just for the duration of that scan. If nothing that has touched the catalog commits while the scan is open, then this is logically equivalent to SnapshotNow. If something does commit in mid-scan, then we might not get the latest version of the row, but we should end up with exactly one. If it's not the latest one, we'll do the rebuild again upon seeing the next sinval message; in the meantime, the version we're using mustn't be too intolerably bad or it was an error not to use AccessExclusiveLock in the first place. IIUC, the problem with this approach is not correctness but performance. Taking snapshots is (currently) expensive. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
