On Thu, 2008-08-07 at 13:30 +0100, Gregory Stark wrote:
> 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?
Think of it as a promise to touch nothing except a specific set of
tables. Whether you lock/access the full set of tables in the visibility
group is up to you.
Visibility groups would likely have overhead, so specifying them more
loosely would allow reasonable administration, yet retain benefit.
> Is it always just a handful of heavily updated tables that you want to
> protect?
Possibly. It seems easier to specify what you might touch, since
security may prevent you even knowing about the existence of other
tables.
> 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.
Possibly
The main point is this information needs to be available on PGPROC, so
that new snapshots can see the visibility groups and then calculate
OldestXmin for each object as a result.
> 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.
I seem to recall we track which objects we have already locked. Perhaps
we would use the explicit visibility group to mark all objects we are
allowed to lock, or mark those to avoid, depending upon which is smaller
list. Then any attempt to lock a new object would be straightforwardly
refused. We must do that cheaply and so that precludes any use of shared
resources such as the lock table.
If you'd like to run with this, I doubt I will have time to do anything
with it this release.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
