Excerpts from Tom Lane's message of vie jun 17 13:22:40 -0400 2011: > 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.
Hmm, would there be a problem if a scan on catalog A yields results from supposedly-running transaction X but another scan on catalog B yields result from transaction Y? (X != Y) For example, a scan on pg_class says that there are N triggers but scanning pg_trigger says N-1? -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
