"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Simon Riggs <simon@2ndquadrant.com> writes:
>> On Fri, 2008-01-11 at 19:23 -0500, Tom Lane wrote:
>>> [ blanches... ] Can you say "security hole"?
>
>> Static on the line, sorry.
>> I'm hearing "useful superuser-only capability". ;-)
>
> It would be far *more* useful if it didn't have to be superuser-only.
> And since the actual details of the snapshot content are really of
> zero interest to the user, I think making it pass through his hands
> is simply misdesign.
Well we already have the snapshot appearing in txid_current_snapshot(). It
wouldn't be too hard to go through that and verify that it satisfies the
current minimum requirements (xmin >= globalxmin and all visible xids are
committed).
The risk is that it would impose restrictions on what we can do in the future.
We were talking about doing snapshot bookkeeping which would allow us to
vacuum transactions which are known invisible to everyone even if they haven't
passed globalxmin yet. This might make it harder to do that.
If we instead pass in an xid or virtualxid for a live transaction to adopt the
serializable snapshot of that snapshot then we can be sure it doesn't change
any invariants about what snapshots can appear in the future. So vacuuming
strategy wouldn't have to change at all.
The flip side is that that limits the use cases the feature could be used for.
You wouldn't be able to store snapshots in a table somewhere so you can
generate old reports or something like that.
To do something like that the user would have to create a prepared transaction
to save the snapshot. I think that makes sense though since effectively it's
just requiring that the user explicitly do what would otherwise be a hidden
implicit requirement -- that the user do something to hold globalxmin back to
avoid having the snapshots expire.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!
