-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
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 future, it seems past time to
have a fo
18 matches
Mail list logo