Re: Commits 8de72b and 5457a1 (COPY FREEZE)

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
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-06T00:43:08Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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.

From memory, the tqual.c code assumes that any tuple with XMIN_COMMITTED
couldn't possibly be from its own transaction, and thus it doesn't make
the tests that would be appropriate for a tuple that is from the current
transaction.  Maybe it's all right anyway (i.e. if we should always treat
such a tuple as good) but I don't recall exactly what's tested in those
paths.

			regards, tom lane


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Keep rd_newRelfilenodeSubid across overflow.

  2. Reduce scope of changes for COPY FREEZE.

  3. COPY FREEZE and mark committed on fresh tables.