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

Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
Date: 2010-01-05 03:42:30
Message-ID: 603c8f071001041942k551ec54chafb8d69022929c6e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Mon, Jan 4, 2010 at 9:34 PM, Tom Lane <tgl(at)postgresql(dot)org> wrote:
> Log Message:
> -----------
> Remove too-smart-for-its-own-good optimization of not overwriting the output
> files when they haven't changed.  This confuses make because the build fails
> to update the file timestamps, and so it keeps on doing the action over again.

This doesn't seem like a good idea.  Not rebuilding the output files
also saves recompiling the things that depend on them.  For the BKI
files thast doesn't matter much, but for schemapg.h it might be
significant.  Certainly, if we move to generating more header files
this way, it WILL be significant.  If running the script is cheap (and
it should be), it's better to take that hit rather than recompiling a
whole mess of .c files unnecessarily.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Takahiro ItagakiDate: 2010-01-05 03:44:38
Subject: Re: Verifying variable names in pgbench
Previous:From: Robert HaasDate: 2010-01-05 03:33:47
Subject: Re: Verifying variable names in pgbench

pgsql-committers by date

Next:From: Tom LaneDate: 2010-01-05 03:51:34
Subject: Re: [COMMITTERS] pgsql: Remove too-smart-for-its-own-good optimization of not overwriting
Previous:From: Andrew DunstanDate: 2010-01-05 02:34:07
Subject: Re: pgsql: Get rid of the need for manual maintenance of the initial

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