From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Recreate Missing WAL Directories (from TODO) |
Date: | 2008-11-09 17:31:24 |
Message-ID: | 14B5F8A9-C88A-46D6-9BA2-F86CE8977F9F@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Nov 8, 2008, at 3:08 PM, Tom Lane wrote:
> "Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)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(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2008-11-09 17:37:36 | Re: auto_explain contrib moudle |
Previous Message | Andrew Dunstan | 2008-11-09 17:30:39 | Re: Spurious Kerberos error messages |