On Wed, Nov 23, 2011 at 9:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2011-11-23 22:47:39|
|Subject: Re: Not HOT enough|
|Previous:||From: Magnus Hagander||Date: 2011-11-23 22:36:57|
|Subject: Snapshot build updates|