> 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
No comments:
Post a Comment