Re: Commits 8de72b and 5457a1 (COPY FREEZE) - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Date
Msg-id 1354816613.11983.1.camel@jdavis
Whole thread Raw
In response to Re: Commits 8de72b and 5457a1 (COPY FREEZE)  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Commits 8de72b and 5457a1 (COPY FREEZE)  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Thu, 2012-12-06 at 11:55 -0500, Stephen Frost wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
> When I last recall this discussion (likely in some bar in Europe), the
> problem was also that an independent session would be able to:
> 
> a) see that the table exists (due to SnapshotNow being used for lookups)
> b) see rows in the table
> 
> Part 'a' is something which I think would be good to fix (but hard),
> and it sounds like this patch might make part 'b' happen, which I think
> makes the part 'a' problem worse.  I'm guessing this isn't a problem for
> the TRUNCATE case because the second session would still be looking at
> the pre-TRUNCATE files on disk, right?  Is that reference to exactly
> which files on disk to look at being used to address the CREATE problem
> too..?

That isn't a problem, because the other session won't see the tuple in
pg_class until the creating transaction commits, at which point the rows
have committed, too (because this would only kick in when the rows are
loaded in the same transaction as the CREATE).

So, yes, it's like TRUNCATE in that regard.

Regards,Jeff Davis




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Fix for pg_upgrade status display
Next
From: Simon Riggs
Date:
Subject: Re: Functional dependency in GROUP BY through JOINs