Date: Tue, 7 Mar 2023 14:47:05 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	Andres Freund <andres@anarazel.de>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Nathan Bossart <nathandbossart@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Use pg_pwritev_with_retry() instead of write() in
 dir_open_for_write() to avoid partial writes?
Message-ID: <20230307064705.tvpltmp6xjunyhju@jrouhaud>
References: <20230216190020.67rslbjq4tmo6cvh@awork3.anarazel.de>
 <Y+8qkqMWISW5Pta/@paquier.xyz>
 <20230217173114.kxnzc7wt7xtusnlv@awork3.anarazel.de>
 <Y/MGIhD8KFhfEBzz@paquier.xyz>
 <CALj2ACXr0Wjf1C70y=YGa_P_1rzPS0UT3fod0Ajx+gA3OkMpvQ@mail.gmail.com>
 <ZAVsPrZGF3b5Z1l2@paquier.xyz>
 <CA+hUKGK-FM0kpvAss+2s6=Fyj+w7d1LLB1mN6713v59uLjFE4w@mail.gmail.com>
 <CA+hUKGKtii2y4RgdQn6UPyyjLw6+jfbx_TRR5NUqBCdZWcEGhA@mail.gmail.com>
 <ZAa+Vq83PpSBMhlg@paquier.xyz>
 <CA+hUKGJtNnWWnz9C4Vw8M+NMkwcSo39HPN9MYZQOP1ToZ9KnDg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+hUKGJtNnWWnz9C4Vw8M+NMkwcSo39HPN9MYZQOP1ToZ9KnDg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20230307064705.tvpltmp6xjunyhju%40jrouhaud>
Precedence: bulk

On Tue, Mar 07, 2023 at 07:14:51PM +1300, Thomas Munro wrote:
> On Tue, Mar 7, 2023 at 5:32 PM Michael Paquier <michael@paquier.xyz> wrote:
> > On Tue, Mar 07, 2023 at 03:44:46PM +1300, Thomas Munro wrote:
> > > Oh, you already pushed a fix.  But now I'm wondering if it's useful to
> > > have old buggy compilers set to run with -Werror.
> >
> > Yes, as far as I can see when investigating the issue, this is an old
> > bug of gcc when detecting where the initialization needs to be
> > applied.  And at the same time the fix is deadly simple, so the
> > current statu-quo does not sound that bad to me.  Note that lapwing is
> > one of the only animals testing 32b builds, and it has saved from
> > quite few bugs over the years.
>
> Yeah, but I'm just wondering, why not run a current release on it[1]?
> Debian is one of the few distributions still supporting 32 bit
> kernels, and it's good to test rare things, but AFAIK the primary
> reason we finish up with EOL'd OSes in the 'farm is because they have
> been forgotten (the secondary reason is because they couldn't be
> upgraded because the OS dropped the [micro]architecture).

I registered lapwing as a 32b Debian 7 so I thought it would be expected to
keep it as-is rather than upgrading to all newer major Debian versions,
especially since there were newer debian animal registered (no 32b though
AFAICS).  I'm not opposed to upgrading it but I think there's still value in
having somewhat old packages versions being tested, especially since there
isn't much 32b coverage of those.  I would be happy to register a newer 32b
version, or even sid, if needed but the -m32 part on the CI makes me think
there isn't much value doing that now.

Now about the -Werror:

> BTW CI also tests 32 bit with -m32 on Debian, but with a 64 bit
> kernel, which probably doesn't change much at the level we care about,
> so maybe this doesn't matter much... just sharing an observation that
> we're wasting time thinking about an OS release that gave up the ghost
> in 2016, because it is running with -Werror.  *shrug*

I think this is the first time that a problem raised by -Werror on that old
animal is actually a false positive, while there were many times it reported
useful stuff.  Now this has been up for years before we got better CI tooling,
especially with -m32 support, so there might not be any value to have it
anymore.  As I mentioned at [1] I don't mind removing it or just work on
upgrading any dependency (or removing known buggy compiler flags) to keep it
without being annoying.  In any case I'm usually quite fast at reacting to any
problem/complaint on that animal, so you don't have to worry about the
buildfarm being red too long if it came to that.

[1] https://www.postgresql.org/message-id/20220921155025.wdixzbrt2uzbi6vz%40jrouhaud