Re: includedir_internal headers are not self-contained - Mailing list pgsql-hackers

From Tom Lane
Subject Re: includedir_internal headers are not self-contained
Date
Msg-id 21095.1398701670@sss.pgh.pa.us
Whole thread Raw
In response to Re: includedir_internal headers are not self-contained  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: includedir_internal headers are not self-contained  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> ... which might or might not be the same one that libpgcommon was compiled
>> with, no?  I don't think you're really protecting yourself against version
>> skew that way.

> The CATALOG_VERSION dependency in that code is a mistake which I didn't
> notice back then.  I can't put too much thought into this issue at this
> time, but printing fork numbers rather than names seems pretty
> user-unfriendly to me.  Rather than a revert of the whole patch I
> would hope for some different solution, if possible, though I can't
> offer anything right now.

I think it would be okay to have a common/ module that encapsulates
fork names/numbers.  It's relpath() and particularly
TABLESPACE_VERSION_DIRECTORY that bother me from a dependency standpoint.

As far as pg_xlogdump goes, I agree that symbolic fork names are probably
nice, but I think the case for printing db/ts/rel OIDs as a pathname is a
whole lot weaker --- to my taste, that's actually an anti-feature.  So I
wouldn't mind dropping that dependency on relpath.  Not sure what to do
for Heikki's pg_rewind, though.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: allowing VACUUM to be cancelled for conflicting locks
Next
From: Robert Haas
Date:
Subject: Re: includedir_internal headers are not self-contained