Prev: one-off error in to_char formatting
Next: [HACKERS] Explicit psqlrc
From: Heikki Linnakangas on 5 Mar 2010 10:13
Greg Smith wrote:
> pg_controldata itself just reads the file in directly and dumps the
> data. There is a copy of it kept around all the time in shared memory
> though (ControlFile in xlog.c), protected by a LWLock. At a high level
> you can imagine a new function in xlog.c that acquires that lock, copies
> the block into a space the backend allocated for saving it, releases the
> lock, and then returns the whole structure. Then just wrap some number
> of superuser-only UDFs around it (I'd guess nobody wants regular ones
> able to hold a lock on ControlFile) and you've exposed the results to
> user-space.
>
> Two questions before I'd volunteer to write that:
>
> 1) How do you handle the situation where the pg_controldata is invalid?
> "Not read in yet" and "CRC is bad" are the two most obvious ones that
> can happen.

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.

> 2) While it's easy to say "I only want one or two of these values" and
> expose a whole set of UDFs to grab them individually (perhaps wrapping
> into a system view via that popular approach), I am concerned that
> people are going to call any single-value versions provided one at a
> time and get an inconsistent set. I think the only reasonable interface
> to this would not return a single field, it would pop out all of them so
> you got a matching set from the point in time the lock was held. And if
> that's the case, I'm not sure of the most reasonable UI is. Just return
> a whole row with a column for each field in the file, and then people
> can select out just the ones they want? (That's probably the right
> one)

Yeah, one column for field seems ok to me.

Which fields do you want to expose? Perhaps it would make sense to split
the functionality in a few user-defined functions: one to return static
information about the architecture and compilation options (alignment,
32-bin vs 64 bit, block sizes, etc.) one to return all the fields
regarding latest checkpoint, plus other functions for the rest that are
needed.

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

> Have re-raised these concerns to myself, this is usually the point in
> this exercise where I go "screw it, I'll just parse pg_controldata again
> instead" and do that instead. This is happening so much lately that I
> think Josh's suggestion it's just unworkable to keep going via that
> model forever has merit though. I find it hard to mark this 9.0
> territory though, given the data is not actually difficult to grab--and
> that trail is already well blazed, nothing new in this version.

I have no problem adding this to 9.0 if we have a solid proposal for the
UI. It's low risk and makes the life easier for people. People are
clearly missing this.

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
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: Greg Smith on 5 Mar 2010 13:28
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.

Once it's done, the UI is solid, all the data is known to be exposed in
the right way it turns out people wanted it to be, then do the simple
conversion it to grab from shared memory instead and add it as an
official 9.1 feature. I'm not feeling any pressure that this is a
must-fix item for the 9.0 release freeze--as warts here go, this is a
both a small one and one that doesn't have to be fixed in core, so two
strikes against it being critical.

I would rather have the ability to tweak on this for a few months to get
everything right, while being able to expose regular updates outside of
core, than to commit "this is the best we've got so far" just under the
wire for 9.0 without necessarily enough time to do it well. The few
messages that have shown up here already have made left me with the
optinion that just getting the requirements and preferred implementation
nailed down here is going to take a few rounds of development to work
out to everyone's satisfaction.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(a)2ndQuadrant.com www.2ndQuadrant.us


--
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 13:38
On 3/5/10 10:28 AM, Greg Smith wrote:
>
> I would rather have the ability to tweak on this for a few months to get
> everything right, while being able to expose regular updates outside of
> core, than to commit "this is the best we've got so far" just under the
> wire for 9.0 without necessarily enough time to do it well.

Oh, I wasn't proposing doing *anything* for 9.0. I wanted to get
something on the TODO list for 9.1. As far as I'm concerned, 9.0 is
closed to new ideas. We have enough bugs to fix as it is.

--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: Greg Smith on 5 Mar 2010 14:11
Josh Berkus wrote:
> Oh, I wasn't proposing doing *anything* for 9.0. I wanted to get
> something on the TODO list for 9.1. As far as I'm concerned, 9.0 is
> closed to new ideas. We have enough bugs to fix as it is.
>

I didn't get that initially from how you characterized this as "past
time" to add. It's at
http://wiki.postgresql.org/wiki/Todo#Point-In-Time_Recovery_.28PITR.29 now.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(a)2ndQuadrant.com www.2ndQuadrant.us


--
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 14:18

> I didn't get that initially from how you characterized this as "past
> time" to add. It's at
> http://wiki.postgresql.org/wiki/Todo#Point-In-Time_Recovery_.28PITR.29 now.

Sorry for not being clear. I took it for granted that since it's past
2/15, no non-critical patches would be even considered. And
pg_controldata certainly isn't critical.

--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

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