Обсуждение: [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