Re: exposing pg_controldata and pg_config as functions

fOn Mon, Jan 18, 2016 at 01:54:02PM -0800, Joe Conway wrote:
> On 01/18/2016 01:47 PM, Bruce Momjian wrote:
> > On Sun, Jan 17, 2016 at 02:24:46PM -0800, Joe Conway wrote:
> >> On 01/16/2016 06:02 AM, Michael Paquier wrote:
> >>> On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> >>>> 1) Change NextXID output format from "%u/%u" to "%u:%u"
> >>>> (see recent hackers thread)
> >>>
> >>> ! printf(_("Latest checkpoint's NextXID: %u/%u\n"),
> >>> ControlFile.checkPointCopy.nextXidEpoch,
> >>> ControlFile.checkPointCopy.nextXid);
> >>> printf(_("Latest checkpoint's NextOID: %u\n"),
> >>> --- 646,652 ----
> >>> ControlFile.checkPointCopy.ThisTimeLineID);
> >>> printf(_("Latest checkpoint's full_page_writes: %s\n"),
> >>> ControlFile.checkPointCopy.fullPageWrites ? _("on") : _("off"));
> >>> ! printf(_("Latest checkpoint's NextXID: %u:%u\n"),
> >>> This should be definitely a separate patch.
> >>
> >> Ok. Notwithstanding Simon's reply, there seems to be consensus that this
> >> is the way to go. Will commit it this way unless some additional
> >> objections surface in the next day or so.
> >
> > FYI, this slash-colon change will break pg_upgrade unless it is patched.
> > Dp you want a patch from me?
>
> Didn't realize that -- yes please.

Sure, attached, and it would be applied only to head, where you change
pg_controldata. pg_upgrade has to read the old and new cluster's
pg_controldata. We could get more sophisticated by checking the catalog
version number where the format was changed, but that doesn't seem worth
it, and is overly complex because we get the catalog version number from
pg_controldata, so you would be adding a dependency in ordering of the
pg_controldata entries.

I can test all suppored Postgres versions with pg_upgrade once you apply
the patch, but I think it will be fine.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +