Horton
Menu

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

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-12-06T00:57:56Z
Lists: pgsql-hackers 
On Wed, 2012-12-05 at 19:43 -0500, Tom Lane wrote:
> 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.

Oh, I see, it probably warrants some more discussion. It seems like we
could solve these problems if we narrow the conditions enough.

Anyway, the partial revert looks good, and the commit message seems
appropriate (essentially, the code got ahead of the discussion).

Regards,
	Jeff Davis

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.