> I've discovered (with SQLsmith) that the new possible error makes
> pg_prewarm/autoprewarm fail when the error triggered during it's
> initialization and then another instance tries to acquire apw_state->lock.
From just a quick look at this, it does not seem to be the fault
of the error message itself, but because we no longer can
tolerate leaks in new tranche IDs. Currently the function shows:
/* XXX: this tranche is leaked */
tranche_id = LWLockNewTrancheId("test_dsa");
the test_dsa_resowners seems to not be handling
such scenarios and releasing locks, etc somewhere. If you modify
the function test_dsa_resowners and only keep the
LWLockNewTrancheId call, like this:
"
PG_FUNCTION_INFO_V1(test_dsa_resowners);
Datum
test_dsa_resowners(PG_FUNCTION_ARGS)
{
LWLockNewTrancheId("test_dsa");
PG_RETURN_VOID();
}
"
it does not repro.
Not really sure why this required "debug_parallel_query"
to be ON either, but that option itself should also be
used with caution.
I am not sure we need to do anything about this.
--
Sami Imseih
Amazon Web Services (AWS)
