From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Date: | 2012-12-06 16:55:39 |
Message-ID: | 20121206165539.GT5162@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> I haven't looked at the committed patch - which seemed a bit
Disclaimer- neither have I, but..
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 said, I love the idea of having a way to drop tuples in w/o having
to go back and rewrite them three times..
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2012-12-06 17:02:53 | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Previous Message | Kevin Grittner | 2012-12-06 16:52:46 | Re: Serious problem: media recovery fails after system or PostgreSQL crash |