Re: Queries about PostgreSQL PITR

Поиск
Список
Период
Сортировка
От Jayadevan M
Тема Re: Queries about PostgreSQL PITR
Дата
Msg-id OF66E87B1A.0F4F4C24-ON6525775E.002E098E-6525775E.002EB698@ibsplc.com
обсуждение исходный текст
Ответ на Re: Queries about PostgreSQL PITR  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Queries about PostgreSQL PITR  (Fujii Masao <masao.fujii@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: simple functions, huge overhead, no cache
Следующее
От: Andras Fabian
Дата:
Сообщение: Re: PG_DUMP very slow because of STDOUT ??