Re: vacuum vs heap_update_tuple() and multixactids

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: vacuum vs heap_update_tuple() and multixactids
Дата
Msg-id CA+TgmoanPDKs1Rh+unOr-K7E6W8JKOFNAn0wxzvnhu1ZcOM8MQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: vacuum vs heap_update_tuple() and multixactids  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #14987: pg_dump fails due to postgis linking problem
Следующее
От: Jeff Janes
Дата:
Сообщение: Order of columns in GROUP BY is significant to the planner.