Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-12-05T23:47:38Z
Lists: pgsql-hackers
On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis <pgsql@j-davis.com> wrote: > After reading that thread, I still don't understand why it's unsafe to > set HEAP_XMIN_COMMITTED in those conditions. Even if it is, I would > think that a sufficiently narrow case -- such as CTAS outside of a > transaction block -- would be safe, along with some slightly broader > cases (like BEGIN; CREATE TABLE; INSERT/COPY). I haven't looked at the committed patch - which seemed a bit precipitous to me given the stage the discussion was at - but I believe the general issue with HEAP_XMIN_COMMITTED is that there might be other snapshots in the same transaction, for example from open cursors. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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