agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Ranier Vilela <ranier.vf@gmail.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Tomas Vondra <tomas@vondra.me>
Cc: Noah Misch <noah@leadboat.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andrey M. Borodin <x4mmm@yandex-team.ru>
Subject: Re: Confine vacuum skip logic to lazy_scan_skip
Date: Thu, 27 Feb 2025 13:08:47 -0500
Message-ID: <2600078.1740679727@sss.pgh.pa.us> (raw)
In-Reply-To: <qphdlszwk3z2w4w6chs4tfheujtpanyayljdijd4fvsdsiq6sl@menvperc55q6>
References: <CA+hUKG+g6aXpi2FEHqeLOzE+xYw=OV+-N5jhOEnnV+F0USM9xA@mail.gmail.com>
<CA+hUKGJ84L0yFD2S05WeCOXmBgBcYb2S5wMmzyohcMJeCwgksw@mail.gmail.com>
<3915749.1739574230@sss.pgh.pa.us>
<CA+hUKGKgHs9xjOZrjjuaEoYSxBvQiYOgDDQiQ6yTSzqFwx6d2Q@mail.gmail.com>
<CAAKRu_Z35kymRA5ru1TeAZtnOd46o7iDCyJgF9P8TH5geKy46A@mail.gmail.com>
<CA+hUKGL8bAsQNj-bB_qxFFzoQW+RMZ3P3zK2SVa6b08G55BdRg@mail.gmail.com>
<626104.1739729538@sss.pgh.pa.us>
<CAAKRu_ZE21Q5ic03bHgAAz5YV6gm7Yu3V9eKnLiDtkh5=0porw@mail.gmail.com>
<CAEudQAr_QXGB2DaK+BhTHuzw76FZCFSp54mzT3MSDn0E5XbcTA@mail.gmail.com>
<l4xcxe5ekugabzcgwqocg6v7qgbzanxh7pstmgddm6y6i4honk@7lpjn3bf6ytz>
<qphdlszwk3z2w4w6chs4tfheujtpanyayljdijd4fvsdsiq6sl@menvperc55q6>
Andres Freund <andres@anarazel.de> writes:
> Ah, no, it isn't. But I still think the coverity alert and the patch don't
> make sense, as per the below:
Coverity's alert makes perfect sense if you posit that Coverity
doesn't assume that this read_stream_next_buffer call will
only be applied to a stream that has per_buffer_data_size > 0.
(Even if it did understand that, I wouldn't assume that it's
smart enough to see that the fast path will never be taken.)
I wonder if it'd be a good idea to add something like
Assert(stream->distance == 1);
Assert(stream->pending_read_nblocks == 0);
Assert(stream->per_buffer_data_size == 0);
+ Assert(per_buffer_data == NULL);
in read_stream_next_buffer. I doubt that this will shut Coverity
up, but it would help to catch caller coding errors, i.e. passing
a per_buffer_data pointer when there's no per-buffer data.
On the whole I doubt we can get rid of this warning without some
significant redesign of the read_stream API, and I don't think
it's worth the trouble. Coverity is a tool not a requirement.
I'm content to just dismiss the warning.
regards, tom lane
view thread (81+ messages) latest in thread
Message-ID: <2600078.1740679727@sss.pgh.pa.us>
Permalink: ../2600078.1740679727@sss.pgh.pa.us/
Also on: postgresql.org/message-id/2600078.1740679727@sss.pgh.pa.us
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, ranier.vf@gmail.com, melanieplageman@gmail.com, thomas.munro@gmail.com, sawada.mshk@gmail.com, tomas@vondra.me, noah@leadboat.com, vignesh21@gmail.com, hlinnaka@iki.fi, byavuz81@gmail.com, robertmhaas@gmail.com, x4mmm@yandex-team.ru
Subject: Re: Confine vacuum skip logic to lazy_scan_skip
In-Reply-To: <2600078.1740679727@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox