Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= writes: > On 12/30/2015 06:46 AM, Simon Riggs wrote: >> There is already long precedent about how to represent an XID with an >> epoch... and it is neither of those two formats. > IMHO, we have been telling users that XIDs are 32bits forever, so > showing a

Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

On 12/30/2015 06:46 AM, Simon Riggs wrote: On 30 December 2015 at 00:17, Joe Conway > wrote: On 12/29/2015 07:15 AM, Tom Lane wrote: > Yeah. Use of the same x/y notation with two different bases seems like > a recipe for confusion. It's probably too l

Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

On 30 December 2015 at 00:17, Joe Conway wrote: > On 12/29/2015 07:15 AM, Tom Lane wrote: > > Yeah. Use of the same x/y notation with two different bases seems like > > a recipe for confusion. It's probably too late to do anything about > > this for 9.5, but I'd be +1 for adopting Jose's sugges

Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

On 12/29/2015 07:15 AM, Tom Lane wrote: > Yeah. Use of the same x/y notation with two different bases seems like > a recipe for confusion. It's probably too late to do anything about > this for 9.5, but I'd be +1 for adopting Jose's suggestion or some > other formatting tweak in HEAD. I made the

Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= writes: > On 12/29/2015 01:18 PM, Heikki Linnakangas wrote: >> On 29/12/15 07:14, Joe Conway wrote: >>> Shouldn't it use "%X/%X", same as e.g. "Prior checkpoint location" and >>> all the other XIDs? >> No. The "locations" in the output are WAL locations. Those

Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

On 12/29/2015 01:18 PM, Heikki Linnakangas wrote: On 29/12/15 07:14, Joe Conway wrote: I wonder why "Latest checkpoint's NextXID" is formated like this: 8<- printf(_("Latest checkpoint's NextXID: %u/%u\n"), ControlFile.checkPointCopy.nextXidEpoch,

Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

On 29/12/15 07:14, Joe Conway wrote: I wonder why "Latest checkpoint's NextXID" is formated like this: 8<- printf(_("Latest checkpoint's NextXID: %u/%u\n"), ControlFile.checkPointCopy.nextXidEpoch, ControlFile.checkPo

[HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

I wonder why "Latest checkpoint's NextXID" is formated like this: 8<- printf(_("Latest checkpoint's NextXID: %u/%u\n"), ControlFile.checkPointCopy.nextXidEpoch, ControlFile.checkPointCopy.nextXid); 8<---

Re: [HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 12:41 PM, Alvaro Herrera wrote: > Joe Conway wrote: >> On 08/25/2015 11:28 AM, Alvaro Herrera wrote: >>> Joe Conway wrote: >>> Does anyone out there object to a non-backward compatible change to pg_controldata output? >>> >>>

Re: [HACKERS] pg_controldata output alignment regression

Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 I should have gotten my key signed when I had the chance :-( > On 08/25/2015 11:28 AM, Alvaro Herrera wrote: > > Joe Conway wrote: > > > >> Does anyone out there object to a non-backward compatible change > >> to pg_controldata

Re: [HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 11:28 AM, Alvaro Herrera wrote: > Joe Conway wrote: > >> Does anyone out there object to a non-backward compatible change >> to pg_controldata output? > > I don't (and thanks for taking care of it), but as I recall, > pg_upgrade reads a

Re: [HACKERS] pg_controldata output alignment regression

Joe Conway wrote: > Does anyone out there object to a non-backward compatible change to > pg_controldata output? I don't (and thanks for taking care of it), but as I recall, pg_upgrade reads and interprets pg_controldata output so it may need adjustment too. -- Álvaro Herrerahtt

Re: [HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 10:32 AM, Joe Conway wrote: > On 08/25/2015 10:28 AM, Tom Lane wrote: >> I was suggesting getting rid of "Current" in *all* the entries. >> What value does it add? > > I agree, it adds no value, and is a simple solution. > > Does anyon

Re: [HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 10:28 AM, Tom Lane wrote: > Joe Conway writes: >> On 08/24/2015 07:41 PM, Tom Lane wrote: >>> Seems to me we could s/Current //g, or s/ setting//g, or both, >>> and get rid of the problem without adding more whitespace. > >> I'd agree,

Re: [HACKERS] pg_controldata output alignment regression

Joe Conway writes: > On 08/24/2015 07:41 PM, Tom Lane wrote: >> Seems to me we could s/Current //g, or s/ setting//g, or both, and >> get rid of the problem without adding more whitespace. > I'd agree, except I think not everyone might be happy with that. The > surrounding lines look like: I was

Re: [HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2015 07:41 PM, Tom Lane wrote: > Joe Conway writes: >> Do we care that as of 9.5 pg_controldata output is not 100% >> aligned anymore? The culprit is: Current track_commit_timestamp >> setting: off Its value is shifted 2 characters to the rig

Re: [HACKERS] pg_controldata output alignment regression

Joe Conway writes: > Do we care that as of 9.5 pg_controldata output is not 100% aligned > anymore? The culprit is: > Current track_commit_timestamp setting: off > Its value is shifted 2 characters to the right with respect to all the > others. I think it ought to be fixed but thought I'd get op

[HACKERS] pg_controldata output alignment regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Do we care that as of 9.5 pg_controldata output is not 100% aligned anymore? The culprit is: Current track_commit_timestamp setting: off Its value is shifted 2 characters to the right with respect to all the others. I think it ought to be fixed but

Re: [HACKERS] pg_controldata gobbledygook

On Fri, Apr 26, 2013 at 08:51:23AM -0400, Robert Haas wrote: > On Fri, Apr 26, 2013 at 5:08 AM, Andres Freund wrote: > > I have to admit I don't see the point. None of those values is particularly > > interesting to anybody without implementation level knowledge and those > > will likely deal with

Re: [HACKERS] pg_controldata gobbledygook

On Fri, Apr 26, 2013 at 2:08 AM, Andres Freund wrote: > On 2013-04-25 23:07:02 -0400, Peter Eisentraut wrote: > > I'm not sure who is supposed to be able to read this sort of stuff: > > > > Latest checkpoint's NextXID: 0/7575 > > Latest checkpoint's NextOID: 49152 > > Latest chec

Re: [HACKERS] pg_controldata gobbledygook

On Fri, Apr 26, 2013 at 5:08 AM, Andres Freund wrote: > I have to admit I don't see the point. None of those values is particularly > interesting to anybody without implementation level knowledge and those > will likely deal with them just fine. And I find the version with the > shorter names far

Re: [HACKERS] pg_controldata gobbledygook

--On 25. April 2013 23:19:14 -0400 Tom Lane wrote: I think I've heard of scripts grepping the output of pg_controldata for this that or the other. Any rewording of the labels would break that. While I'm not opposed to improving the labels, I would vote against your second, abbreviated scheme

Re: [HACKERS] pg_controldata gobbledygook

On 2013-04-25 23:07:02 -0400, Peter Eisentraut wrote: > I'm not sure who is supposed to be able to read this sort of stuff: > > Latest checkpoint's NextXID: 0/7575 > Latest checkpoint's NextOID: 49152 > Latest checkpoint's NextMultiXactId: 7 > Latest checkpoint's NextMultiOffset

Re: [HACKERS] pg_controldata gobbledygook

On 26/04/13 18:53, Daniel Farina wrote: On Thu, Apr 25, 2013 at 9:34 PM, Tom Lane wrote: Alvaro Herrera writes: Tom Lane wrote: I think I've heard of scripts grepping the output of pg_controldata for this that or the other. Any rewording of the labels would break that. While I'm not opposed

Re: [HACKERS] pg_controldata gobbledygook

On Thu, Apr 25, 2013 at 9:34 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> I think I've heard of scripts grepping the output of pg_controldata for >>> this that or the other. Any rewording of the labels would break that. >>> While I'm not opposed to improving the labels, I

Re: [HACKERS] pg_controldata gobbledygook

Alvaro Herrera writes: > Tom Lane wrote: >> I think I've heard of scripts grepping the output of pg_controldata for >> this that or the other. Any rewording of the labels would break that. >> While I'm not opposed to improving the labels, I would vote against your >> second, abbreviated scheme be

Re: [HACKERS] pg_controldata gobbledygook

On Fri, Apr 26, 2013 at 12:22 AM, Peter Geoghegan wrote: > On Thu, Apr 25, 2013 at 8:07 PM, Peter Eisentraut wrote: > > Comments? > > +1 from me. > > I don't think that these particular changes would break WAL-E, > Heroku's continuous archiving tool, which has a class called > PgControlDataParse

Re: [HACKERS] pg_controldata gobbledygook

Tom Lane wrote: > I think I've heard of scripts grepping the output of pg_controldata for > this that or the other. Any rewording of the labels would break that. > While I'm not opposed to improving the labels, I would vote against your > second, abbreviated scheme because it would make things am

Re: [HACKERS] pg_controldata gobbledygook

On Thu, Apr 25, 2013 at 8:07 PM, Peter Eisentraut wrote: > Comments? +1 from me. I don't think that these particular changes would break WAL-E, Heroku's continuous archiving tool, which has a class called PgControlDataParser. However, it's possible to imagine someone being affected in a similar

Re: [HACKERS] pg_controldata gobbledygook

Peter Eisentraut writes: > The comments in the pg_control.h header file use much more pleasant > terms, which when put to use would lead to output similar to this: > Latest checkpoint's next free transaction ID: 0/7575 > Latest checkpoint's next free OID:49152

[HACKERS] pg_controldata gobbledygook

I'm not sure who is supposed to be able to read this sort of stuff: Latest checkpoint's NextXID: 0/7575 Latest checkpoint's NextOID: 49152 Latest checkpoint's NextMultiXactId: 7 Latest checkpoint's NextMultiOffset: 13 Latest checkpoint's oldestXID:1265 Latest checkpoint

Re: [HACKERS] pg_controldata doesn't report 64/32bit?

Am Samstag, 8. Dezember 2007 schrieb Josh Berkus: > Pretty much. We're supporting x86 64-bit servers for Solaris now, and > we need SMF to be able to check whether it can safely run x binaries > against y data. Well, the canonical way to do that is to start the server and see if it succeeds. Yo

Re: [HACKERS] pg_controldata doesn't report 64/32bit?

Simon, Sounds like Josh is asking for a way to find out the things that matter on an architecture and compare them with the relevant parts of the pg_control structure. The 32/64 bit thing was probably just his shorthand for that. Perhaps we should document how to perform a portability check?

Re: [HACKERS] pg_controldata doesn't report 64/32bit?

On Sat, 2007-12-08 at 02:46 -0500, Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > We could always tighten this up a bit by listing the alignment of a > > handful of built-in data types but I suppose there will always be > > holes in this area anyways. > > In theory yeah, but the n

Re: [HACKERS] pg_controldata doesn't report 64/32bit?

Gregory Stark <[EMAIL PROTECTED]> writes: > We could always tighten this up a bit by listing the alignment of a > handful of built-in data types but I suppose there will always be > holes in this area anyways. In theory yeah, but the note in pg_control.h still applies to every platform I've heard

Re: [HACKERS] pg_controldata doesn't report 64/32bit?

Gregory Stark <[EMAIL PROTECTED]> writes: > Argh, As soon as I sent it I realized even that's not right. The > alignments of our datums is specified by pg_type and doesn't vary by > platform. There has been some thought of making 8-byte data types like > bigint pass-by-value on 64-bit machines in w

Re: [HACKERS] pg_controldata doesn't report 64/32bit?

Gregory Stark wrote: "Gregory Stark" <[EMAIL PROTECTED]> writes: "Tom Lane" <[EMAIL PROTECTED]> writes: Josh Berkus <[EMAIL PROTECTED]> writes: I've just noticed that pg_controldata doesn't say anything about whether the database is 64-bit or 32-bit. That's because there is no such concept.

Re: [HACKERS] pg_controldata doesn't report 64/32bit?

"Gregory Stark" <[EMAIL PROTECTED]> writes: > Oh, I see what you meant now. Datum is a purely in-memory concept, it doesn't > actually reach disk. > > We could always tighten this up a bit by listing the alignment of a handful of > built-in data types but I suppose there will always be holes in th

Re: [HACKERS] pg_controldata doesn't report 64/32bit?

"Gregory Stark" <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: > >> Josh Berkus <[EMAIL PROTECTED]> writes: >>> I've just noticed that pg_controldata doesn't say anything about whether >>> the database is 64-bit or 32-bit. >> >> That's because there is no such concept. > > I

Re: [HACKERS] pg_controldata doesn't report 64/32bit?

"Tom Lane" <[EMAIL PROTECTED]> writes: > Josh Berkus <[EMAIL PROTECTED]> writes: >> I've just noticed that pg_controldata doesn't say anything about whether >> the database is 64-bit or 32-bit. > > That's because there is no such concept. I think the relevant concept is whether Datum is 32-bit o

Re: [HACKERS] pg_controldata doesn't report 64/32bit?

Josh Berkus <[EMAIL PROTECTED]> writes: > I've just noticed that pg_controldata doesn't say anything about whether > the database is 64-bit or 32-bit. That's because there is no such concept. > Since the data files can be > incompatible based on word length, shouldn't that be in pg_controldata?

[HACKERS] pg_controldata doesn't report 64/32bit?

Folks, I've just noticed that pg_controldata doesn't say anything about whether the database is 64-bit or 32-bit. Since the data files can be incompatible based on word length, shouldn't that be in pg_controldata? --Josh Berkus ---(end of broadcast)--

[HACKERS] pg_controldata

I modified pg_controldata to display a few new fields. Example output appears at the end of this message, and the cvs log is: Add a few new lines to display recently added fields in the ControlFile structure. Now includes the following new fields: integer/float date/time storage maximum lengt