[EMAIL PROTECTED] writes:
>> Well, it doesn't *require* it, but if you actually *use* the patch in
>> the proposed way then you end up with the error-prone need to specify
>> the correct combination of -C and -D on the command line. I think what
>> people are questioning is whether we can't find a variant solution that
>> avoids that risk.
> This is completely wrong with regards to the patch. The patch "allows"
> "-D" on the command line, just like you can override the socket port,
> number of buffers, and other options, but the intention is that you do NOT
> use the "-D" option.
Well, yeah, if you are considering only the single-database case (or
even the separate-config-for-every-database case) then you could put
"datadir = foo" in the config file and not use -D. The complaints are
basically coming from the fact that this doesn't seem to scale up to
more complex cases. To make use of shared config files you'd have
to start the postmaster with both -C and -D, and I for one think that's
risky. Plus it negates the claimed documentation benefit, since the
filesystem contains no indication (or a wrong one) of which data dirs
use the config file.
If we're going to tackle this problem then I'd like to see a solution
that works conveniently in the general case of N config files each being
used by multiple databases. If we don't solve the general case then
we'll just have to revisit the problem again sometime soon ... and one
of the things we avoid when possible is API thrashing. If we have to
break DBAs' established habits to improve things, then so be it, but
let's not do so only to do it over again in the next release.
>> Separate -C and -D would make sense if it were a many-to-many
>> relationship (ie, you could sensibly use many different configs with the
>> same data dir), but the case for multiple configs with one data dir
>> seems pretty weak to me, and outweighed by the risk factors.
> I hear "risk" but what risk?
Two specific risks were pointed out already: starting a production
server with fsync=off risks data loss, and starting it with the wrong
pg_hba.conf risks security breaches (eg, letting the developer weenies
into the payroll database ;-)). But those same settings would very
likely be in use "next door" for a development database. With separate
config and data it's real easy to foresee a DBA making the wrong
association, if there's nothing in the filesystem to strongly tie a
data directory to the config it should be used with. I think the
feature needs to be designed to minimize that risk.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
