Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Дата
Msg-id 19213.1431112929@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Actually, looking closer, the quoted code is simply not broken without
>> RELCACHE_FORCE_RELEASE: without that, neither heap_close nor index_close
>> will do anything that could cause a cache flush.  So while it's certainly
>> good pratice to move that lappend_oid call up, it does not explain the
>> observed symptoms.  We still need some more investigation here.

> Couldn't a cache flush request come from another backend?  Although this
> isn't being run in a parallel group, is it?  Maybe a delayed signal that
> happens to show up late at just the right time?  Dunno if we've ever
> actually seen that but the thought occured to me.

A signal could certainly have arrived in that interval, but it wouldn't be
serviced in that interval --- or if it was, we have far worse problems
than this one.  Nothing interesting should happen except at (at least) a
CHECK_FOR_INTERRUPTS() point, and there is none in this code sequence.

I'm back to suspecting that the indcheckxmin issue is the true cause of
the buildfarm failure, though we lack an explanation why Andres failed
to reproduce it ...
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Следующее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Proposal : REINDEX xxx VERBOSE