Re: Queries about PostgreSQL PITR - Mailing list pgsql-general

From Jayadevan M
Subject Re: Queries about PostgreSQL PITR
Date
Msg-id OF66E87B1A.0F4F4C24-ON6525775E.002E098E-6525775E.002EB698@ibsplc.com
Whole thread Raw
In response to Re: Queries about PostgreSQL PITR  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Queries about PostgreSQL PITR  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-general
Hi,
>Because you didn't disable recovery_target_inclusive, I guess.
>
http://www.postgresql.org/docs/8.4/static/continuous-archiving.html#RECOVERY-TARGET-INCLUSIVE
Thanks. I was almost sure this will fix it. But the issue seems to be
something else. Even if I give a time that is a few more minutes before
what I got from select now(), it is always moving upto/or just before
(depending on the above parameter) transaction id 676. The ooutput reads
 LOG:  recovery stopping before commit of transaction 676, time 2010-07-09
07:49:26.580518+05:30

Is there a way to find out the transaction ids and corresponding SQLs,
timeline etc? May be doing the recovery in debug/logging mode or something
like that?

Regards,
Jayadevan





DISCLAIMER:

"The information in this e-mail and any attachment is intended only for
the person to whom it is addressed and may contain confidential and/or
privileged material. If you have received this e-mail in error, kindly
contact the sender and destroy all copies of the original communication.
IBS makes no warranty, express or implied, nor guarantees the accuracy,
adequacy or completeness of the information contained in this email or any
attachment and is not liable for any errors, defects, omissions, viruses
or for resultant loss or damage, if any, direct or indirect."






pgsql-general by date:

Previous
From: Dave Page
Date:
Subject: Re: simple functions, huge overhead, no cache
Next
From: Andras Fabian
Date:
Subject: Re: PG_DUMP very slow because of STDOUT ??