Re: jsonb failed assertions

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: jsonb failed assertions
Дата
Msg-id 537C93D2.4000704@vmware.com
обсуждение исходный текст
Ответ на Re: jsonb failed assertions  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: jsonb failed assertions  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On 05/20/2014 09:22 PM, Peter Geoghegan wrote:
> On Tue, May 20, 2014 at 4:17 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> table dump is downloadable from http://pgsql.cz/data/data.dump.gz
>
> This looks like an over-zealous assertion, without any user-visible
> consequences. Mea culpa.
>
> Attached patch corrects the problem.  I also noticed in passing that
> there is another obsolete comment -- formIterIsContainer() is former
> jsonbIteratorNext() infrastructure, which the updated comment now
> refers to directly.

Hmm. The patch looks correct as far as it goes. But that function is 
still a bit funny. When it compares two identical arrays (or objects), 
and reaches the WJB_END_ARRAY token, it will still fall into the code 
that checks what the va and vb types are, and compares the last scalar 
values in that array again. That's wrong, and will fail if the compiler 
decides to clobber the local "va" or "vb" variables between iterations 
of the do-while loop, because JsonbIteratorNext() does not set the value 
when returning WJB_END_ARRAY.

BTW, I don't understand this comment:

>         /*
>          * To a limited extent we'll redundantly iterate over an array/object
>          * while re-performing the same test without any reasonable
>          * expectation of the same container types having differing lengths
>          * (as when we process a WJB_BEGIN_OBJECT, and later the corresponding
>          * WJB_END_OBJECT), but no matter.
>          */

Can you elaborate?

- Heikki



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: replication protocol documentation inconsistencies
Следующее
От: Robert Haas
Дата:
Сообщение: Re: BUGFIX: Dynamic bgworkers with BGW_NEVER_RESTART worker restarted on FatalError