Re: Re: [COMMITTERS] pgsql: Prevent "snapshot too old" from trying to return pruned TOAST tu - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Re: [COMMITTERS] pgsql: Prevent "snapshot too old" from trying to return pruned TOAST tu
Date
Msg-id CA+TgmoZzBJ0GHBsgkXMQwdonUF6uSLY+z6w-1B0bzNi+TKpA_g@mail.gmail.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Prevent "snapshot too old" from trying to return pruned TOAST tu  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Aug 5, 2016 at 11:05 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Aug 4, 2016 at 10:58 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> What is the reason?  We refuse to separate frontend and backend
>>> headers in any sort of principled way?
>
>> That was poorly phrased.  I'll try again: I can't see any reason for
>> using a macro here except that it allows frontend code to compile this
>> without breaking.
>
> Well, the alternative would be to put "#ifndef FRONTEND" around the
> static-inline function.  That's not very pretty either, and it's
> inconsistent with the existing precedent (ie, InitDirtySnapshot).
> Also, it presumes that a non-backend includer actually has defined
> FRONTEND; that seems to be the case for pg_xlogdump but I do not
> think we do that everywhere.

That may not be pretty, but it'd be a lot more transparent.  If I see
#ifndef FRONTEND, I think, oh, that's protecting some stuff that
shouldn't be included in front-end compiles.  If I see a macro, I not
necessarily think of the fact that this may be a way of preventing
that code from being compiled in front-end compiles.

>> Here's a patch.  Is this what you want?
>
> OK by me.

OK, committed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Column COMMENTs in CREATE TABLE?
Next
From: Peter Eisentraut
Date:
Subject: money type overflow checks