From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Christoph Berg <cb(at)df7cb(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: includedir_internal headers are not self-contained |
Date: | 2014-04-28 16:14:30 |
Message-ID: | 21095.1398701670@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-04-28 16:21:55 | Re: includedir_internal headers are not self-contained |
Previous Message | Alvaro Herrera | 2014-04-28 15:52:31 | Re: allowing VACUUM to be cancelled for conflicting locks |