Skip site navigation (1) Skip section navigation (2)

Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY
Date: 2009-08-11 03:40:04
Message-ID: 603c8f070908102040g6e0ef714i4604b55e3b5d8055@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Mon, Aug 10, 2009 at 6:52 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Aug 10, 2009 at 4:31 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Yeah --- if there are any active patches against that code (a fact not
>>> in evidence) then reindenting now would break them now.  Leaving it till
>>> the next pgindent run seems fine to me.
>
>> But if there are patches against that code, then they've been broken
>> now
>
> Uh, no --- the point here is that something like two hundred lines of
> code were *not* changed by reindenting.  Diffs in that area would likely
> still apply.
>
>> and they will break again when the pgindent run is done.
>
> Only if they aren't applied by then.  One reason that we normally only
> run pgindent at the end of the devel cycle is that that's when
> (presumably) the smallest amount of patches remain outstanding.

OK, I get it.  Thanks for bearing with me.  The theory that the
smallest amount of patches remain outstanding at that point is
probably only true if the pgindent run is done relatively soon after
the last CommitFest.  In the 8.4 cycle, the pgindent run was done
something like 7 months after the start of the last CommitFest, by
which time a fair number of patches had accumulated.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-08-11 03:50:33
Subject: Re: machine-readable explain output v4
Previous:From: Bruce MomjianDate: 2009-08-11 01:51:03
Subject: Hot standby and synchronous replication status

pgsql-committers by date

Next:From: User MaosenDate: 2009-08-11 11:35:30
Subject: pgexternaltable - src: add func to read data from HDFS
Previous:From: Tom LaneDate: 2009-08-10 23:08:04
Subject: Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group