"Tom Lane" <[EMAIL PROTECTED]> writes: > Simon Riggs <[EMAIL PROTECTED]> 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! ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org