Re: BUG #3401: PITR does not work in the case ofrecovery_target_xid = 'SELECT_only_transaction_ID' - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #3401: PITR does not work in the case ofrecovery_target_xid = 'SELECT_only_transaction_ID'
Date
Msg-id 23813.1182532029@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #3401: PITR does not work in the case ofrecovery_target_xid = 'SELECT_only_transaction_ID'  (Katsuhiko Okano <okano.katsuhiko@oss.ntt.co.jp>)
List pgsql-bugs
Katsuhiko Okano <okano.katsuhiko@oss.ntt.co.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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error message that is a bit misleading / weird result from || null
Next
From: Tom Lane
Date:
Subject: Re: BUG #3403: ver 8.2 can't add serial column to temp table,but 8.1 can