From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Visibility Groups |
Date: | 2008-08-07 14:50:39 |
Message-ID: | 873algkhfk.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>> 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.
>
> I think this would be a lot of mechanism and complication that will go
> completely unused in the field. It'll be impossible even to explain let
> alone to use effectively, for anyone who's not intensely steeped in the
> details of MVCC.
I think Simon's interface was overly complex but if we can simplify it then it
could be useful. As Grittner mentioned implicit queries could make use of it
automatically. Also pg_dump or Slony could make use of it automatically.
And while Alvaro is absolutely right that we should take care of the
inaccessible records between an old long-running transaction and more recently
started transactions that doesn't really completely solve the problem. If you
have a large table consisting of old records which are gradually being
replaced with newer records a long-running transaction will prevent any of
those old records from being vacuumed.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-08-07 14:56:10 | Re: Infrastructure changes for recovery |
Previous Message | Robert Haas | 2008-08-07 14:49:38 | Re: Visibility Groups |