[PATCH] Recreate Missing WAL Directories (from TODO)
When performing a PITR copy of a data cluster, the pg_xlog directory
is generally omitted. As such, when starting the copy up for
replay/recovery, the WAL directories need to be recreated. This patch
checks to see whether XLOGDIR and XLOGDIR/archive_status exist on
XLOGStartup and if not, recreates them.
--
Jonah H. Harris, Senior DBA
myYearbook.com
Attachments:
arcstatdir.patchapplication/octet-stream; name=arcstatdir.patchDownload+53-2
"Jonah H. Harris" <jonah.harris@gmail.com> writes:
When performing a PITR copy of a data cluster, the pg_xlog directory
is generally omitted. As such, when starting the copy up for
replay/recovery, the WAL directories need to be recreated. This patch
checks to see whether XLOGDIR and XLOGDIR/archive_status exist on
XLOGStartup and if not, recreates them.
This has been suggested before but I'm unconvinced that it's a good
idea. It's reasonably common for pg_xlog to be a symlink. If you
neglect to re-establish the symlink then what would happen is that xlog
gets recreated on the data disk, and with no notice you are running in
a degraded mode.
It might be reasonable to auto-recreate XLOGDIR/archive_status, though.
regards, tom lane
On Sat, Nov 8, 2008 at 4:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
This has been suggested before but I'm unconvinced that it's a good
idea. It's reasonably common for pg_xlog to be a symlink. If you
neglect to re-establish the symlink then what would happen is that xlog
gets recreated on the data disk, and with no notice you are running in
a degraded mode.
Agreed on the basis that people sometimes forget to symlink. That's
the reason why I was echoing a message. Initially the message was
WARNING, but I degraded it to LOG.
It might be reasonable to auto-recreate XLOGDIR/archive_status, though.
Attached.
BTW, I have seen people create both pg_xlog and archive_status as
files, which is why I'm validating that in this function rather than
waiting for it to error-out later in the code.
--
Jonah H. Harris, Senior DBA
myYearbook.com
Attachments:
arcstatdir_v2.patchapplication/octet-stream; name=arcstatdir_v2.patchDownload+57-2
On Nov 8, 2008, at 3:08 PM, Tom Lane wrote:
"Jonah H. Harris" <jonah.harris@gmail.com> writes:
When performing a PITR copy of a data cluster, the pg_xlog directory
is generally omitted. As such, when starting the copy up for
replay/recovery, the WAL directories need to be recreated. This
patch
checks to see whether XLOGDIR and XLOGDIR/archive_status exist on
XLOGStartup and if not, recreates them.This has been suggested before but I'm unconvinced that it's a good
idea. It's reasonably common for pg_xlog to be a symlink. If you
neglect to re-establish the symlink then what would happen is that
xlog
gets recreated on the data disk, and with no notice you are running in
a degraded mode.
ISTM it'd be better still to have an official knob that allows you to
determine where pg_xlog lives. ISTR discussion about that, but I
don't see anything obvious in postgresql.conf or configure.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Decibel! <decibel@decibel.org> writes:
On Nov 8, 2008, at 3:08 PM, Tom Lane wrote:
... It's reasonably common for pg_xlog to be a symlink.
ISTM it'd be better still to have an official knob that allows you to
determine where pg_xlog lives. ISTR discussion about that, but I
don't see anything obvious in postgresql.conf or configure.
My recollection of the discussion is that we decided it was too
dangerous to make it "configurable" --- if you crash and restart and the
restart seizes on some other WAL directory to recover from, you're up
the proverbial creek.
(Come to think of it, this is also a reasonable argument for not letting
postmaster startup auto-create pg_xlog ...)
regards, tom lane
"Jonah H. Harris" <jonah.harris@gmail.com> writes:
On Sat, Nov 8, 2008 at 4:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
This has been suggested before but I'm unconvinced that it's a good
idea. It's reasonably common for pg_xlog to be a symlink. If you
neglect to re-establish the symlink then what would happen is that xlog
gets recreated on the data disk, and with no notice you are running in
a degraded mode.
Agreed on the basis that people sometimes forget to symlink. That's
the reason why I was echoing a message. Initially the message was
WARNING, but I degraded it to LOG.
Applied with minor stylistic tweaks and documentation update.
regards, tom lane
On Nov 9, 2008, at 11:44 AM, Tom Lane wrote:
Decibel! <decibel@decibel.org> writes:
On Nov 8, 2008, at 3:08 PM, Tom Lane wrote:
... It's reasonably common for pg_xlog to be a symlink.
ISTM it'd be better still to have an official knob that allows you to
determine where pg_xlog lives. ISTR discussion about that, but I
don't see anything obvious in postgresql.conf or configure.My recollection of the discussion is that we decided it was too
dangerous to make it "configurable" --- if you crash and restart
and the
restart seizes on some other WAL directory to recover from, you're up
the proverbial creek.(Come to think of it, this is also a reasonable argument for not
letting
postmaster startup auto-create pg_xlog ...)
What if the the location was recorded in something that's not meant
to be touched by users, such as pg_control? At that point we'd have a
command for actually moving it.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Decibel! <decibel@decibel.org> writes:
What if the the location was recorded in something that's not meant
to be touched by users, such as pg_control? At that point we'd have a
command for actually moving it.
[ shrug... ] Possible, perhaps, but I think we have more important
problems to expend development effort on. In particular the notion
of moving pg_xlog on-the-fly in a running database seems FAR more
difficult than it could possibly be worth.
regards, tom lane