Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group