Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-12-06T16:55:39Z
Lists: pgsql-hackers
* Robert Haas (robertmhaas@gmail.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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Keep rd_newRelfilenodeSubid across overflow.
- ae9aba69a860 9.3.0 cited
-
Reduce scope of changes for COPY FREEZE.
- 5457a130d3a6 9.3.0 cited
-
COPY FREEZE and mark committed on fresh tables.
- 8de72b66a2ed 9.3.0 cited