On Wed, Nov 23, 2011 at 9:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> My patch actually improves the speed of snapshots, rather than slowing
>> them as Tom's would.
>
> It can be arbitrarily fast if it doesn't have to get the right answer.
(LOL) - laughing with you
> Unfortunately, you're not producing the right answer. You can not
> exclude XIDs in other databases from the snapshot, at least not unless
> you know that the snapshot will not be used for examining any shared
> catalogs ... and GetSnapshotData certainly cannot know that.
>
> I think that the idea of computing a different cutoff on the
> probably-rare occasions where we need to prune a shared catalog page
> has some merit, but the change you are currently proposing to
> GetSnapshotData flat out does not work.
All true, but I already said that myself in a direct reply to you 2 hours ago.
And I proposed a solution, which was to use SnapshotNow as an override
for user queries against shared catalog tables.
Computing two cutoffs is overkill for the rare event of pruning a
shared catalog page. I did think of that already and its not a good
solution. I'm tempted by the idea of getting rid of multiple databases
altogether. The hassle of supporting that feature far outweighs the
fairly low benefit.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
