Re: Assertion failing in master, predicate.c

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: Assertion failing in master, predicate.c
Дата
Msg-id 09359045-9919-b9d9-d458-17e2b9f28c1b@gmail.com
обсуждение исходный текст
Ответ на Re: Assertion failing in master, predicate.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Assertion failing in master, predicate.c  (Mark Dilger <hornschnorter@gmail.com>)
Список pgsql-hackers

On 11/22/19 11:07 AM, Tom Lane wrote:
> Mark Dilger <hornschnorter@gmail.com> writes:
>> On 11/21/19 8:03 PM, Tom Lane wrote:
>>> I also confirm that it only happens in HEAD, not v12.  I've not
>>> actually bisected, but a look at the git history for predicate.c
>>> sure makes it look like db2687d1f ("Optimize PredicateLockTuple")
>>> must be to blame.
> 
>> `git bisect` shows the problem occurs earlier than that, and by
>> chance the first bad commit was one of yours.  I'm not surprised
>> that your commit was regarding LISTEN/NOTIFY, as the error is
>> always triggered with a LISTEN statement.  (I've now hit this
>> many times in many tests of multiple SQL statements, and the
>> last statement before the error is always a LISTEN.)
> 
> Oh my, that's interesting!  I had wondered a bit about the LISTEN
> changes, but it's hard to see how those could have any connection
> to serializable mode.  This will be an entertaining debugging
> exercise ...

predicate.c was changed a few times after REL_12_STABLE was
branched from master but before Thomas's change that you
initially thought might be to blame.  I checked whether
rolling back the changes in predicate.c while keeping your
LISTEN/NOTIFY changes might fix the bug, but alas the bug
is still present.

I'll go familiarize myself with your LISTEN/NOTIFY changes
now....

-- 
Mark Dilger



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Assertion failing in master, predicate.c
Следующее
От: David Steele
Дата:
Сообщение: Re: backup manifests