-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> (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 produ
Joe Conway writes:
> I have not bothered to start a pgfoundry project yet -- thoughts?
For the visibility of the project, pgfoundry is still a good idea it
seems, even if you still have to register separately for the online
catalogue:
http://www.postgresql.org/download/products/1
Now, AFAIUI,
On Sat, Mar 6, 2010 at 12:13 AM, Heikki Linnakangas
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 RED
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 directi
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
> p
> (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-
Heikki Linnakangas 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
> 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 consider
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
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
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'
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 lo
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I do find it a bit hard to imagine that any program capable of shelling
> out to call pg_controldata and doing something with the output would hit
> a major hurdle parsing the format that's already there.
+1
> 1) How do you handle the situ
Magnus Hagander wrote:
Huh? It's fixed with, you don't need regexps for that. Just split the
string apart.
Taking options for single fields might have a better usecase, of course :-)
I do find it a bit hard to imagine that any program capable of shelling
out to call pg_controldata and doin
On 03/04/2010 02:09 PM, Joshua Tolley wrote:
> On Thu, Mar 04, 2010 at 10:54:15PM +0100, Magnus Hagander wrote:
>> 2010/3/4 Josh Berkus :
>>> pg_controldata --catalog_version
>>>
>>> Even better would be the ability to get everything which is in
>>> pg_controldata currently as part of a system view
On Thu, Mar 04, 2010 at 10:54:15PM +0100, Magnus Hagander wrote:
> 2010/3/4 Josh Berkus :
> > pg_controldata --catalog_version
> >
> > Even better would be the ability to get everything which is in
> > pg_controldata currently as part of a system view in a running
> > PostgreSQL; I can get most of
2010/3/4 Josh Berkus :
> All,
>
> Currently, the only way for admin scripts to get individual data items
> out of pg_controldata (such as the next XID or the catalog version) is
> via grep and regex. Given that people are going to be relying on some of
> this data for replication admin in the futur
17 matches
Mail list logo
