Horton

Re: [REVIEW] pg_last_xact_insert_timestamp

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp>, pgsql-hackers@postgresql.org
Date: 2011-10-02T21:35:31Z
Lists: pgsql-hackers

Commits

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

  1. Treat 2PC commit/abort the same as regular xacts in recovery.

Robert Haas <robertmhaas@gmail.com> writes:
> It occurs to me that pgstat_report_xact_end_timestamp doesn't really
> need to follow the protocol of bumping the change count before and
> after bumping the timestamp.  We elsewhere assume that four-byte reads
> and writes are atomic, so there's no harm in assuming the same thing
> here (and if they're not... then the change-count thing is pretty
> dubious anyway).  I think it's sufficient to just set the value, full
> stop.

I agree you can read the value without that, but I think that setting
it should still bump the change count.  Otherwise there's no way for
another process to collect the whole struct and be sure that it's
self-consistent.  We may not have a critical need for that right now,
but it's silly to foreclose the possibility to save a cycle or so.

			regards, tom lane