> On 21 Apr 2024, at 23:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>>> On 6 Apr 2024, at 01:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> (So now I'm wondering why *only* copperhead has shown this so far.
>>> Are our other cross-version-upgrade testing animals AWOL?)
>
>> Clicking around searching for Xversion animals I didn't spot any, but without
>> access to the database it's nontrivial to know which animal does what.
>
> I believe I see why this is (or isn't) happening. The animals
> currently running xversion tests are copperhead, crake, drongo,
> and fairywren. copperhead is using the makefiles while the others
> are using meson. And I find this in
> src/test/modules/test_pg_dump/meson.build (from 3f0e786cc):
>
> # doesn't delete its user
> 'runningcheck': false,
>
> So the meson animals are not running the test that sets up the
> problematic data.
ugh =/
> I think we should remove the above, since (a) the reason to have
> it is gone, and (b) it seems really bad that the set of tests
> run by meson is different from that run by the makefiles.
Agreed.
> However, once we do that, those other three animals will presumably go
> red, greatly complicating detection of any Windows-specific problems.
> So I'm inclined to not do it till just before we intend to commit
> a fix for the underlying problem. (Enough before that we can confirm
> that they do go red.)
Agreed, we definitely want that but compromising the ability to find Windows
issues at this point in the cycle seems bad.
> ... were you going to look at it? I can take a whack if it's
> too far down your priority list.
I took a look at this, reading code and the linked thread. My gut feeling is
that Stephen is right in that the underlying bug is these privileges ending up
in pg_init_privs to begin with. That being said, I wasn't able to fix that in
a way that doesn't seem like a terrible hack. The attached POC hack fixes it
for me but I'm not sure how to fix it properly. Your wisdom would be much appreciated.
Clusters which already has such entries aren't helped by a fix for this though,
fixing that would either require pg_dump to skip them, or pg_upgrade to have a
check along with instructions for fixing the issue. Not sure what's the best
strategy here, the lack of complaints could indicate this isn't terribly common
so spending cycles on it for every pg_dump might be excessive compared to a
pg_upgrade check?
--
Daniel Gustafsson