Re: Tom Lane 2014-05-02 <9995.1398994...@sss.pgh.pa.us>
> >> The patch is certainly too invasive to consider back-patching into
> >> 9.3, though.
Understood.
> > I feel unsure about this. I agree the patch is quite invasive. Leaving
> > 9.3 in a broken state seems problematic. In particular I'
Alvaro Herrera writes:
> Tom Lane wrote:
>> The patch is certainly too invasive to consider back-patching into
>> 9.3, though.
> I feel unsure about this. I agree the patch is quite invasive. Leaving
> 9.3 in a broken state seems problematic. In particular I'm not sure
> what would Debian do a
Tom Lane wrote:
> I wrote:
> > How about we change common/relpath.[hc] to export a single version of
> > relpath() that takes its arguments as separate plain OIDs, and then
> > make the other versions wrappers that are only declared in some
> > backend header? The wrappers could possibly be macros
Andres Freund writes:
> On 2014-04-28 13:20:47 -0400, Tom Lane wrote:
>> Printing anything other than the relation OID here is irrelevant,
>> misleading, and inconsistent with our practice everywhere else.
> I don't think it's really comparable to the other scenarios. We should
> print the oid, j
I wrote:
> How about we change common/relpath.[hc] to export a single version of
> relpath() that takes its arguments as separate plain OIDs, and then
> make the other versions wrappers that are only declared in some
> backend header? The wrappers could possibly be macros, allowing
> things like p
On 04/29/2014 06:00 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 04/29/2014 02:56 AM, Heikki Linnakangas wrote:
On 04/28/2014 10:32 PM, Tom Lane wrote:
Meh. I still think it's a bad idea to have CATALOG_VERSION_NO getting
compiled into libpgcommon.a, where there will be no way to cross-chec
Andrew Dunstan writes:
> On 04/29/2014 02:56 AM, Heikki Linnakangas wrote:
>> On 04/28/2014 10:32 PM, Tom Lane wrote:
>>> Meh. I still think it's a bad idea to have CATALOG_VERSION_NO getting
>>> compiled into libpgcommon.a, where there will be no way to cross-check
>>> that it matches anything.
On 04/29/2014 02:56 AM, Heikki Linnakangas wrote:
On 04/28/2014 10:32 PM, Tom Lane wrote:
Robert Haas writes:
I have to admit it's been a few years since I've had to play with
WAL_DEBUG, so I don't really remember what I was trying to do. But I
don't see any real argument that three slash-se
On 04/28/2014 10:32 PM, Tom Lane wrote:
Robert Haas writes:
I have to admit it's been a few years since I've had to play with
WAL_DEBUG, so I don't really remember what I was trying to do. But I
don't see any real argument that three slash-separated numbers will be
more useful to somebody who
On 2014-04-28 13:20:47 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane wrote:
> >> 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 we
Robert Haas writes:
> I have to admit it's been a few years since I've had to play with
> WAL_DEBUG, so I don't really remember what I was trying to do. But I
> don't see any real argument that three slash-separated numbers will be
> more useful to somebody who has to dig through this than a path
On Mon, Apr 28, 2014 at 2:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 28, 2014 at 1:20 PM, Tom Lane wrote:
>>> It's more verbose, it's not actually any more information, and in many
>>> cases it's actively misleading, because what's printed is NOT the real
>>> file name --- it om
On 2014-04-28 14:44:16 -0400, Robert Haas wrote:
> > BTW, for the same reasons I'm less than impressed with the uses of
> > relpath in error messages in, eg, reorderbuffer.c:
> >
> > relation = RelationIdGetRelation(reloid);
> >
> > if (relation == NULL)
> >
Robert Haas writes:
> On Mon, Apr 28, 2014 at 1:20 PM, Tom Lane wrote:
>> It's more verbose, it's not actually any more information, and in many
>> cases it's actively misleading, because what's printed is NOT the real
>> file name --- it omits segment numbers for instance. As a particularly
>>
On Mon, Apr 28, 2014 at 1:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane wrote:
>>> 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 we
Robert Haas writes:
> On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane wrote:
>> 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.
On Mon, Apr 28, 2014 at 12:14 PM, Tom Lane wrote:
> Alvaro Herrera 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 d
Alvaro Herrera 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
Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 04/28/2014 04:51 PM, Tom Lane wrote:
> >> I'm not even worried about which headers this program uses. What I'm
> >> worried about is that you've got CATALOG_VERSION_NO compiled into a
> >> non-server executable. Is that really such a great idea
Heikki Linnakangas writes:
> On 04/28/2014 04:51 PM, Tom Lane wrote:
>> I'm not even worried about which headers this program uses. What I'm
>> worried about is that you've got CATALOG_VERSION_NO compiled into a
>> non-server executable. Is that really such a great idea? Wouldn't it be
>> bette
On 04/28/2014 04:51 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 04/28/2014 03:29 PM, Christoph Berg wrote:
Re: Heikki Linnakangas 2014-04-28 <535e09b7.3090...@vmware.com>
I'm using it in the pg_rewind tool. It needs to know how to map relfilenodes
to physical files.
Isn't pg_rewind s
Heikki Linnakangas writes:
> On 04/28/2014 03:29 PM, Christoph Berg wrote:
>> Re: Heikki Linnakangas 2014-04-28 <535e09b7.3090...@vmware.com>
>>> I'm using it in the pg_rewind tool. It needs to know how to map relfilenodes
>>> to physical files.
>> Isn't pg_rewind so low-level server-close that i
On 04/28/2014 03:29 PM, Christoph Berg wrote:
Re: Heikki Linnakangas 2014-04-28 <535e09b7.3090...@vmware.com>
Comments? If there's anyone who has a really good use-case for using
relpath() from outside the backend, better speak up.
I'm using it in the pg_rewind tool. It needs to know how to m
Re: Heikki Linnakangas 2014-04-28 <535e09b7.3090...@vmware.com>
> >Comments? If there's anyone who has a really good use-case for using
> >relpath() from outside the backend, better speak up.
>
> I'm using it in the pg_rewind tool. It needs to know how to map relfilenodes
> to physical files.
>
On 04/27/2014 11:33 PM, Tom Lane wrote:
I wrote:
On closer inspection, the issue here is really that putting relpath.h/.c
in common/ was completely misguided from the get-go. It's unnecessary:
there's nothing outside the backend that uses it, except for
contrib/pg_xlogdump which could very easi
On 2014-04-27 16:55:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-27 16:33:29 -0400, Tom Lane wrote:
> >> According to the commit message, the point of that was to allow
> >> pg_xlogdump to use relpath(), but I do not see it doing so;
>
> > Well, pg_xlogdump.c itself doesn't us
Andres Freund writes:
> On 2014-04-27 16:33:29 -0400, Tom Lane wrote:
>> According to the commit message, the point of that was to allow
>> pg_xlogdump to use relpath(), but I do not see it doing so;
> Well, pg_xlogdump.c itself doesn't use it, but some of the desc routines
> do. Like e.g. xact_d
Hi,
On 2014-04-27 16:33:29 -0400, Tom Lane wrote:
> > So it seems to me the right fix for the relpath end of it is to push most
> > of relpath.c back where it came from, which I think was backend/catalog/.
>
> In short, what I'm proposing here is to revert commit
> a73018392636ce832b09b5c31f6ad1f
I wrote:
> On closer inspection, the issue here is really that putting relpath.h/.c
> in common/ was completely misguided from the get-go. It's unnecessary:
> there's nothing outside the backend that uses it, except for
> contrib/pg_xlogdump which could very easily do without it. And relpath.h
>
Christoph Berg writes:
> Re: Tom Lane 2014-04-26 <21449.1398524...@sss.pgh.pa.us>
>> Clearly, the idea that common/ is server-only is broken.
> The next step should probably be something like this:
Somebody who's spent more time than I have on the "make install" support
will have to comment on t
Re: Tom Lane 2014-04-26 <21449.1398524...@sss.pgh.pa.us>
> > internal/postgres_fe.h includes
> > common/fe_memutils.h which includes
> > utils/palloc.h
>
> Hm. It seems rather fundamentally broken to me that frontend code is
> including palloc.h --- that file was never intended to be fronte
I wrote:
> Christoph Berg writes:
>> $ grep -r include 9.4/server/common/ | grep \"
>> 9.4/server/common/fe_memutils.h:#include "utils/palloc.h"
>> 9.4/server/common/relpath.h:#include "catalog/catversion.h" /* pgrminclude
>> ignore */
>> 9.4/server/common/relpath.h:#include "storage/relfilenode.
Christoph Berg writes:
> internal/postgres_fe.h includes
> common/fe_memutils.h which includes
> utils/palloc.h
Hm. It seems rather fundamentally broken to me that frontend code is
including palloc.h --- that file was never intended to be frontend-safe,
and the #ifdefs that I see in it tod
33 matches
Mail list logo
