Prev: one-off error in to_char formatting
Next: [HACKERS] Explicit psqlrc
From: Tom Lane on 5 Mar 2010 16:36
Heikki Linnakangas <heikki.linnakangas(a)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(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Josh Berkus on 5 Mar 2010 18:03

> (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.)

I'll have a more detailed list when I've gotten further with testing HS/SR.

--Josh Berkus

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

From: Bruce Momjian on 6 Mar 2010 20:59
Tom Lane wrote:
> (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.)

pg_migrator reads/parses the output of pg_controldata for cluster
compatibility checking and for setting counters.

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do

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

From: Joe Conway on 8 Mar 2010 19:59
On 03/05/2010 10:28 AM, Greg Smith wrote:
> Heikki Linnakangas wrote:
>> Then again, if you don't use the copy in shared memory but just open the
>> pg_control file and read it in the UDF, you could implement this as a
>> pgfoundry module that works with older versions too.
>
> This is the direction I'd prefer to see this go in a 9.0 context. It's
> easy enough to build a fully functional version that lives works via the
> same proposed final UDF interface, just with the extra step of reading
> the file. Get that working, and you just added a useful module
> supporting all the way back to 8.2 (I think--not sure if there's been
> any other changes that would break this) that people would love to have.

FWIW, here is a quick and dirty effort:

http://www.joeconway.com/source_code/pg_controldata.tar.gz

It turns out some minor changes are needed for 8.4 or earlier as some
attributes have been added to ControlFileData. Once we get general
agreement I can do that too. I have not bothered to start a pgfoundry
project yet -- thoughts?

Joe

From: Fujii Masao on 8 Mar 2010 20:06
On Sat, Mar 6, 2010 at 12:13 AM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> The REDO location of last checkpoint might deserve a function of its
> own, like we have pg_last_xlog_replay_location() and
> pg_last_xlog_receive_location().

Agreed. I submitted the patch which introduces new function returning
the REDO location of last checkpoint, on other thread.
http://archives.postgresql.org/pgsql-hackers/2010-03/msg00334.php

Are you planning to apply the patch until 9.0 release?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: one-off error in to_char formatting
Next: [HACKERS] Explicit psqlrc