Simon Riggs wrote: > > This costs no performance; if anything it should be faster than now, > > because we'll be replacing expensive transaction state probes with > > relatively-cheap searches of an XID array that should almost always > > be quite short. > > > > With this approach, we would have no serialization anomalies from single > > transactions committing while a scan is in progress. ?There could be > > anomalies resulting from considering an earlier XID to be in-progress > > while a later XID is considered committed (because we didn't observe > > it until later). ?So far as I can see offhand, the impact of that would > > be that there might be multiple versions of a tuple that are considered > > good, but never that there would be no version considered good (so long > > as the other XIDs simply updated the tuple and didn't delete it). ?I > > think this would be all right, since the scan would just seize on the > > first good version it finds. ?As you argue above, if that's not good > > enough for our purposes then the updater(s) should have taken a stronger > > lock. > > I liked this idea, so began to prototype the code. My rough hack is > attached, for the record. > > One thing that occurs to me about this is that SnapshotNow with or > without these changes returns the latest committed row and ignores > in-progress changes. > > Accepting an older version of the definition will always be > potentially dangerous. I can't see a way of doing this that doesn't > require locking - for changes such as new constraints we need to wait > until in progress changes are complete. > > So maybe this idea is worth doing, but I don't think it helps us much > reduce lock levels for DDL.
Just confirming we decided not to persue this. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
