Tom Lane wrote:
I wonder why backup_label isn't automatically removed
in normal crash recovery case.
Removing it automatically could be catastrophic if done
incorrectly, no?
It would be no less catastrophic if done incorrectly from outside the
postmaster; see for example the problems
Albe == Albe Laurenz laurenz.a...@wien.gv.at writes:
Albe Removing postmaster.pid can lead to a corrupt database.
Albe Removing backup_label means that one of your backups will go
Albe wrong, and a subsequent pg_stop_backup() will throw an error.
Albe If you have a cluster failover during
[ after further thought... ]
Andrew Gierth and...@tao11.riddles.org.uk writes:
How do you distinguish between these two scenarios:
1) you're starting up in a data dir where you crashed in the middle of
a backup
2) you're starting up in a data dir that is a restore of a base backup,
Hi,
On Wed, Nov 4, 2009 at 12:01 AM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
2) you're starting up in a data dir that is a restore of a base backup,
but no recovery.conf has been created
Is the scenario 2 (i.e., a normal crash recovery without recovery.conf)
supported in postgres?
Fujii Masao wrote:
When a crash occurs before calling pg_stop_backup(),
the subsequent crash recovery causes the FATAL error
and outputs the following HINT message.
If you are not restoring from a backup, try removing the file
\%s/backup_label\.
I wonder why backup_label isn't
Fujii Masao masao.fu...@gmail.com writes:
I wonder why backup_label isn't automatically removed
in normal crash recovery case.
Removing it automatically could be catastrophic if done incorrectly, no?
If that's intentional, a clusterware for shared disk
failover system should remove
Hi,
When a crash occurs before calling pg_stop_backup(),
the subsequent crash recovery causes the FATAL error
and outputs the following HINT message.
If you are not restoring from a backup, try removing the file
\%s/backup_label\.
I wonder why backup_label isn't automatically removed
in
