Re: BUG #3401: PITR does not work in the case ofrecovery_target_xid = 'SELECT_only_transaction_ID'

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Katsuhiko Okano <okano(dot)katsuhiko(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3401: PITR does not work in the case ofrecovery_target_xid = 'SELECT_only_transaction_ID'
Date: 2007-06-22 17:07:09
Message-ID: 23813.1182532029@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Katsuhiko Okano <okano(dot)katsuhiko(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Simon Riggs wrote:
>> How did you come to choose an xid of this nature?

> specify log_statement = 'all' and log_line_prefix = '[%x]' in postgresql.conf
> (I know this approach is not useful and hardly used on actual system management.)

No, it's not very useful because you can't be sure that the order of
commit records in the WAL file will match what you see in the postmaster
log. If the transactions are sufficiently well spread apart in time
that you *can* be sure of that, you might as well use timestamps anyway.
The reason for having the XID option in recovery.conf at all is to allow
an exact stop point specification when a timestamp is too inaccurate
--- but in a situation like that, you'd really have to have grovelled
through the WAL file with some kind of dump tool to determine which XID
you want to specify.

BTW, as of 8.3 commit timestamps have full gettimeofday() precision,
they're not just time_t values; so the use-case for stopping by XID
is even narrower than it used to be.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2007-06-22 18:51:31 Re: BUG #3403: ver 8.2 can't add serial column to temp table, but 8.1 can
Previous Message Tom Lane 2007-06-22 15:26:26 Re: Error message that is a bit misleading / weird result from <xid> || null