Обсуждение: [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
Вложения
"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
Вложения
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