Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 29, 2010 at 3:32 PM, Heikki Linnakangas
That only affects the error message and is harmless otherwise, but I
thought I'd mention it. I'll fix it, unless someone wants to argue that
its more useful to print the raw return
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
Yes. Please see the existing code in the postmaster that prints
subprocess exit codes, and duplicate it (or perhaps refactor so you can
avoid code duplication; though translatability of messages might limit
what
Heikki Linnakangas escribió:
Here's what I came up with. Translatability indeed makes it pretty hard,
I ended up copy-pasting.
Looks sane to me too; msgmerge segfaults though so I couldn't test. Two
minor comments:
+ /*--
+ translator: %s is a noun phrase
On Wed, Feb 10, 2010 at 4:47 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Here's what I came up with. Translatability indeed makes it pretty hard,
I ended up copy-pasting.
BTW, I don't think I'm going to bother or risk back-patching this. It
was harmless, and for forensic
Mason Hale wrote:
Given that this situation did NOT actually cause corruption, rather the
error message was mangled such that it suggested corruption, I offer this
revised suggestion for update to the documentation:
Important note: It is critical the trigger file be created with permissions
On Fri, Jan 29, 2010 at 11:49 PM, Mason Hale ma...@onespot.com wrote:
While I did not remove the trigger file, I did rename recovery.conf to
recovery.conf.old.
That file contained the recovery_command configuration that identified the
trigger file. So that rename should have eliminated the
On Fri, Jan 29, 2010 at 12:03 AM, Mason Hale ma...@onespot.com wrote:
Of course the best solution is to avoid this issue entirely. Something as
easy to miss as file permissions should not cause data corruption,
especially in the process meant to fail over from a crashing primary
database.
Hello Fujii --
Thanks for the clarification. It's clear my understanding of the recovery
process is lacking.
My naive assumption was that Postgres would recover using whatever files
were available
and if it had run out of files it would stop there and come up. And that if
recovery.conf were
On Fri, Jan 29, 2010 at 11:02 AM, Fujii Masao masao.fu...@gmail.com wrote:
You seem to focus on the above trouble. I think that this happened because
recovery.conf was deleted and restore_command was not given. In fact, the
WAL file (e.g., pg_xlog/00023C8200A3) required for recovery
Robert Haas wrote:
On Fri, Jan 29, 2010 at 11:02 AM, Fujii Masao masao.fu...@gmail.com wrote:
You seem to focus on the above trouble. I think that this happened because
recovery.conf was deleted and restore_command was not given. In fact, the
WAL file (e.g., pg_xlog/00023C8200A3)
If the sysadmin had left the recovery.conf and removed the trigger file,
pg_standby in restore_command would have restored all WAL files required
for recovery, and recovery would advance well.
That may be true, but it's certainly seems unfortunate that we don't
handle this case a bit
Actually, I think there's a tiny harmless bug in the server too. When it
prints the error message:
2010-01-18 21:08:31 UTC ()FATAL: could not restore file
00023C8200D8 from archive: return code 65280
That return code is not the return code that came from the
restore_command. Ie if
On Fri, Jan 29, 2010 at 3:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Actually, I think there's a tiny harmless bug in the server too. When it
prints the error message:
2010-01-18 21:08:31 UTC ()FATAL: could not restore file
00023C8200D8 from archive:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 29, 2010 at 3:32 PM, Heikki Linnakangas
That only affects the error message and is harmless otherwise, but I
thought I'd mention it. I'll fix it, unless someone wants to argue that
its more useful to print the raw return value of system(),
Mason Hale wrote:
ERROR: could not remove /tmp/pgsql.trigger.5432: Operation not
permittedtrigger file found
ERROR: could not remove /tmp/pgsql.trigger.5432: Operation not permitted
This file was not looked until after the attempt to recover was
aborted. Clearly the permissions on
Hello Heikki --
Thank you for investigating this issue and clearing up this mystery.
I do not believe it is obvious that the postgres process needs to be able to
remove the trigger file.
My naive assumption was that the trigger file was merely a flag to signal
that recovery mode needed to be
On Fri, Jan 29, 2010 at 12:03 AM, Mason Hale ma...@onespot.com wrote:
Of course the best solution is to avoid this issue entirely. Something as
easy to miss as file permissions should not cause data corruption,
especially in the process meant to fail over from a crashing primary
database.
I
Hello --
We are using PostgreSQL 8.3.8 with a Warm Standy (PITR) setup.
Recently we experienced a failure on our primary database server and
when we attempted to fail over to the standby server it would not come
up.
This configuration has been tested previously (we've successfully
transferred
18 matches
Mail list logo
