Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> Greg Smith wrote:
>> 1) How do you handle the situation where the pg_controldata is invalid?
> If the data in pg_control are invalid, the database won't start up, so
> by the time you're running the user-defined-functions the data really
> ought be valid.
Yeah. If you are pulling from the shared-memory copy this is an
entirely idle concern. If that data is not correct we have *way* worse
concerns than whether some UDF or other is going to go crazy.
> Which fields do you want to expose?
That's actually the part of this that concerns me most. The data that
is in pg_control is really somewhat ad-hoc, particularly the items that
have to do with checking database compatibility. I'm not comfortable
with the notion that we should expose all and only these fields, and
even less so with the idea that they should be tied together at the SQL
level.
What I'd prefer to see is a use-case presented and an API defined to
solve that case (or those cases, as the case may be). If pulling data
from pg_control is the best solution, great. But "let's expose
pg_control" seems like a backwards design approach.
(FWIW, my recollection of the original design intention for
pg_controldata was that it was meant as a troubleshooting tool if the
database wouldn't start up. I'm somewhat bemused to hear that people
are trying to use it as part of production scripts. It wasn't meant to
produce machine-readable output, much less to give values that you could
rely on with respect to a running server.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
