Re: preserve timestamps when installing headers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Kuzmenkov <akuzmenkov(at)timescale(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: preserve timestamps when installing headers
Date: 2022-01-04 21:21:43
Message-ID: 4119394.1641331303@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 06.12.21 12:15, Michael Paquier wrote:
>> FWIW, I am not on board with changing build semantics or any
>> assumptions the header installation relies on either, but I could see
>> a point in switching back to INSTALL_DATA instead of cp to be
>> consistent with the rest of the build, iff the argument made back in
>> 2005 about the performance of this code path does not hold anymore.

> I think you will find that it is still very slow.

That would likely depend on whether configure had found a suitable
"install" program or decided to fall back on config/install-sh.
The latter will definitely be horribly slow, but C-coded install
utilities are probably no slower than "cp".

However, there's another problem with using INSTALL_DATA as a solution
to this issue: why would you expect that to preserve timestamps?
install-sh won't. I see that /usr/bin/install (which configure picks
on my RHEL box) won't preserve them by default, but it has a -p
option to do so. I would not bet on that being portable to all of
the myriad of foo-install programs that configure will accept, though.

On the whole, I think we should just reject this proposal and move on.
The portability hazards seem significant, and it's really unclear
to me what the advantages are (per Peter's earlier comment).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Brindle 2022-01-04 21:51:18 Re: [PATCH v2] use has_privs_for_role for predefined roles
Previous Message Tom Lane 2022-01-04 20:56:39 Re: [PATCH v2] use has_privs_for_role for predefined roles