Joe Conway m...@joeconway.com 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:
-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
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
On Sat, Mar 6, 2010 at 12:13 AM, Heikki Linnakangas
heikki.linnakan...@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
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
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
-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
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,
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.
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
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
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.
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
(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
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
2010/3/4 Josh Berkus j...@agliodbs.com:
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
On Thu, Mar 04, 2010 at 10:54:15PM +0100, Magnus Hagander wrote:
2010/3/4 Josh Berkus j...@agliodbs.com:
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
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 j...@agliodbs.com:
pg_controldata --catalog_version
Even better would be the ability to get everything which is in
pg_controldata currently as part of a system
18 matches
Mail list logo
