Re: vacuum vs heap_update_tuple() and multixactids - Mailing list pgsql-bugs

From Robert Haas
Subject Re: vacuum vs heap_update_tuple() and multixactids
Date
Msg-id CA+TgmoanPDKs1Rh+unOr-K7E6W8JKOFNAn0wxzvnhu1ZcOM8MQ@mail.gmail.com
Whole thread Raw
In response to Re: vacuum vs heap_update_tuple() and multixactids  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
On Wed, Dec 20, 2017 at 9:05 AM, Andres Freund <andres@anarazel.de> wrote:
> Indeed. I kinda wonder whether we hackishly solve this by simply
> returning true fore all pids if it's waiting for a cleanup lock. That's
> not actually that far from the truth... The big problem with that I see
> is very short waits that resolve themselves causing issues - but given
> that waiting for cleanup locks is really rare, that might not be too
> bad.

I'm wondering if that might cause random, spurious failures.  We go on
to the next step if we detect that the current step is waiting... and
the decisions we make about whether to do that cause differences in
the output.

>> <me thinks for a while>
>>
>> What if we add a hook to vacuum that lets you invoke some arbitrary C
>> code after each block, and then write a test module that uses that
>> hook to acquire and release an advisory lock at that point?  Then you
>> could do:
>
> I guess that'd work, albeit a bit invasive and specific to this
> test. Trying to come up with a concept that'll be generizable longer
> term would be neat.

True, but I'm not sure there's much hope of that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #14987: pg_dump fails due to postgis linking problem
Next
From: Jeff Janes
Date:
Subject: Order of columns in GROUP BY is significant to the planner.