PITR question

ohp@pyrenet.fr wrote:

Hi Every one.

At least I made PITR working however I still have 2 questions:

1) It seems there is a slight bug in this case:
select pg_backup_start('test);
... make backup
select pg_backup_end();
psql database
drp table.... note the time in logs
pg_ctl stop
rm -rf $PGDATA
restore backup
put the timestamp in recovery.conf and recover_inclusive=false
pg_ctl start

... you end up with a core dump (signal 6) and an error saying that you
can't stop before end of backup.

This is because it's the FIRST transaction after backup and ending restore
BEFORE this means ending before the end of backup...

Was this corrected? I don't see any followups to it in the archives.

2)

How do I restore EVERY database to the end of logs BUT one?
Same case here:
I wrongly droped a table so I restart and end the recovery before the drop
but I still want all the other DB in the cluster to go to the end of logs.
I ass/u/me I cant restore just the DB dir??

No, there is no way to restore just one database to an earlier time than
the others.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> wrote on 06.10.2004, 21:15:34:

ohp@pyrenet.fr wrote:

Hi Every one.

At least I made PITR working however I still have 2 questions:

1) It seems there is a slight bug in this case:
select pg_backup_start('test);
... make backup
select pg_backup_end();
psql database
drp table.... note the time in logs
pg_ctl stop
rm -rf $PGDATA
restore backup
put the timestamp in recovery.conf and recover_inclusive=false
pg_ctl start

... you end up with a core dump (signal 6) and an error saying that you
can't stop before end of backup.

This is because it's the FIRST transaction after backup and ending restore
BEFORE this means ending before the end of backup...

Was this corrected? I don't see any followups to it in the archives.

Not by me, though I was definitely working on crash recovery then. ;-)

Olivier is right in the explanation of this, but it doesn't seem that a
core dump is the appropriate response.

I'll correct this... though (for me) low prio fix should be done by
around last week Oct.

Apologies to Olivier and thanks to Bruce for re-raising the issue.

Best Regards,

Simon Riggs

<simon@2ndquadrant.com> writes:

ohp@pyrenet.fr wrote:

... you end up with a core dump (signal 6) and an error saying that you
can't stop before end of backup.

Was this corrected? I don't see any followups to it in the archives.

Not by me, though I was definitely working on crash recovery then. ;-)

Olivier is right in the explanation of this, but it doesn't seem that a
core dump is the appropriate response.

The error is intentional. The reason it's converted to a core dump is
simply that the whole of recovery is run as a critical section, and so
any fatal error is promoted to PANIC.

We could think about a different rule about whether to force a core dump
in these circumstances, but I can't say that I am very excited about it.
I'd rather have the dump and not need it than vice versa.

regards, tom lane

Tom Lane [mailto:tgl@sss.pgh.pa.us]
<simon@2ndquadrant.com> writes:

ohp@pyrenet.fr wrote:

... you end up with a core dump (signal 6) and an error

saying that you

can't stop before end of backup.

Was this corrected? I don't see any followups to it in the archives.

Not by me, though I was definitely working on crash recovery then. ;-)

Olivier is right in the explanation of this, but it doesn't seem that a
core dump is the appropriate response.

The error is intentional.

OK, thats cool.

Not like we're expecting anybody to try exactly that anyway...

Best Regards,

Simon Riggs