Re: MVCC catalog access - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: MVCC catalog access
Date
Msg-id 51AF4F33.7080203@2ndQuadrant.com
Whole thread Raw
In response to Re: MVCC catalog access  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On 06/05/2013 04:28 PM, Greg Stark wrote:
> On Wed, May 22, 2013 at 3:18 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> We've had a number of discussions about the evils of SnapshotNow.  As
>> far as I can tell, nobody likes it and everybody wants it gone, but
>> there is concern about the performance impact.
> I was always under the impression that the problem was we weren't
> quite sure what changes would be needed to make mvcc-snapshots work
> for the catalog lookups. The semantics of SnapshotNow aren't terribly
> clear either but we have years of experience telling us they seem to
> basically work. Most of the problems we've run into we either have
> worked around in the catalog accesses. Nobody really knows how many of
> the call sites will need different logic to behave properly with mvcc
> snapshots.
>
> I thought there were many call sites that were specifically depending
> on seeing dirty reads to avoid race conditions with other backends --
> which probably just narrowed the race condition or created different
> ones. If you clean those all up it will be probably be cleaner and
> better but we don't know how many such sites will need to be modified.
> I'm not even sure what "clean them up" means. You can replace checks
> with things like constraints and locks but the implementation of
> constraints and locks will still need to use SnapshotNow surely?
I guess that anything that does *not* write should be happier with
MVCC catalogue, especially if there has been any DDL after its snapshot.

For writers the ability to compare MVCC and SnapshotNow snapshots
would tell if they need to take extra steps.

But undoubtedly the whole thing would be lot of work.

-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ




pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Vacuum, Freeze and Analyze: the big picture
Next
From: Andrew Dunstan
Date:
Subject: JSON and unicode surrogate pairs