"Simon Riggs" <[EMAIL PROTECTED]> writes: > Currently, we calculate a single OldestXmin across all snapshots on the > assumption that any transaction might access any table. > > I propose creating "Visibility Groups" that *explicitly* limit the > ability of a transaction to access data outside its visibility group(s). > By default, visibility_groups would be NULL, implying potential access > to all tables. > > Once set, any attempt to lock an object outside of a transactions > defined visibility_groups will result in an error: > ERROR attempt to lock table outside of visibility group(s): foo > HINT you need to set a different value for visibility_groups > A transaction can only ever reduce or restrict its visibility_groups, it > cannot reset or add visibility groups.
Hm, so backing up a bit from the specific proposed interface, the key here is being able to explicitly mark which tables your transaction will need in the future? Is it always just a handful of heavily updated tables that you want to protect? In that case we could have a lock type which means "I'll never need to lock this object". Then a session could issue "LOCK TABLE foo IN INACCESSIBLE MODE" or something like that. That requires people to hack up their pg_dump or replication script though which might be awkward. Perhaps the way to do that would be to preemptively take locks on all the objects that you'll need, then have a command to indicate you won't need any further objects beyond those. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers