I am in the middle of helping a customer recover from a situation where
a tablespace was missing when a machine was rebooted and postgres
restarted, and I'm wondering if we should not have some sort of check
for this on startup. Maybe we could check for the existence of the
PG_VERSION file
* Andrew Dunstan (and...@dunslane.net) wrote:
I am in the middle of helping a customer recover from a situation where
a tablespace was missing when a machine was rebooted and postgres
restarted, and I'm wondering if we should not have some sort of check
for this on startup. Maybe we
Andrew Dunstan and...@dunslane.net writes:
I am in the middle of helping a customer recover from a situation where
a tablespace was missing when a machine was rebooted and postgres
restarted, and I'm wondering if we should not have some sort of check
for this on startup. Maybe we could
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I am in the middle of helping a customer recover from a situation where
a tablespace was missing when a machine was rebooted and postgres
restarted, and I'm wondering if we should not have some sort of check
for this on startup.
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
... and do what?
In general, I think I'd probably prefer normal database startup to fail
if a tablespace is missing. That way I will know about it right then and
can remedy it. This is something that is much more likely to happen
Tom Lane wrote:
So what you're imagining is
* iterate through each symlink in $PGDATA/pg_tblspc
* check that PG_VERSION exists (and has the right contents??) in
each pointed-to directory
* fail if not
I guess this is reasonable, since we make a similar check for the core
data directory
Andrew Dunstan and...@dunslane.net writes:
I'm not sure about the initdb reference - there won't be any tablespaces
to check for during initdb, will there?
No, but I think pg_tblspc/ itself might not be there either. Just a
case to test your patch on ...
regards, tom
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I'm not sure about the initdb reference - there won't be any tablespaces
to check for during initdb, will there?
No, but I think pg_tblspc/ itself might not be there either. Just a
case to test your patch on ...
Andrew Dunstan wrote:
I am in the middle of helping a customer recover from a situation
where a tablespace was missing when a machine was rebooted and
postgres restarted,
Have you uncovered why the tablespace when missing?
and I'm wondering if we should not have some sort of check for this
Andrew Dunstan wrote:
I am in the middle of helping a customer recover from a situation
where a tablespace was missing when a machine was rebooted and
postgres restarted,
Have you uncovered why the tablespace went missing?
and I'm wondering if we should not have some sort of check for this
Andrew Chernow wrote:
Andrew Dunstan wrote:
I am in the middle of helping a customer recover from a situation
where a tablespace was missing when a machine was rebooted and
postgres restarted,
Have you uncovered why the tablespace went missing?
No. It's on a SAN, and I understand our
Anyway, from this POV all we really need to know is that the device
hosting this tablespace failed to mount when the machine was rebooted,
and then postgres restarted.
Good to know postgresql had nothing to do with the missing data. I
wasn't sure if it was user error, config problem or
12 matches
Mail list logo
