Monday, August 25, 2008

Re: [HACKERS] initdb change

On Mon, 25 Aug 2008 09:42:21 -0700
David Fetter <david@fetter.org> wrote:

> > We either need to provide a way to initialize it at initdb, allow
> > xlogs to be in table space or add a GUC for the location.
>
> There's already a way to specify where xlogs should be via
> -X/--xlogdir.

Sorry should have checked 8.3 initdb instead of 8.2.

> What that doesn't do is put the xlogdir where a DBA
> would naturally expect to find it. When that DBA doesn't find it in
> the place they expect, very bad knock-on decisions are likely to
> result.

O.k. when using 8.3 I did this:

initdb -D /tmp/foo -X /tmp/xlogs

And I got:

/tmp/foo/pg_xlog which is a link to /tmp/xlogs

That seems perfectly logical. If I (without removing the old initdb) do
this:

/usr/lib/postgresql/8.3/bin/initdb -D /tmp/bar -X /tmp/xlog

I get:

initdb: directory "/tmp/xlog" exists but is not empty
If you want to store the transaction log there, either
remove or empty the directory "/tmp/xlog".
initdb: removing data directory "/tmp/bar"

I just reread your original message a little slower and see that what
you want is if:

/var/lib/pgsql/data/ exists but is empty you can initdb within that
directory. However if there is anything in it you can not. You are
asking that if pg_xlog exists but is empty that we still be able to use
the DATADIR and you can pass existing so that it will also use pg_xlog
if it is empty.

My take would be to not add a new flag. Instead to implicitly allow it.
If initdb finds that DATADIR and pg_xlog is empty it will use both.


Sincerely,

Joshua D. Drake


>
> Cheers,
> David.


--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

No comments: