Re: Postgres Crashing

On 2/4/20 6:20 AM, Doug Roberts wrote:
>> So how did containers_reset_recirc() come to clash with
>> containers_add_update()?
> 
> They are clashing because another portion of our system is running and 
> updating containers. The reset recirc function was run at the same time 
> to see how our system and the database would handle it.

So does your system have the things Tom mentioned below?:

"The known bugs in that area
require either before-row-update triggers on the table, or
child tables (either partitioning or traditional inheritance).
So I wonder what the schema of table "containers" looks like."

> 
> The recirc string is formatted like 2000=3,1000=6,5000=0. So the reset 
> recirc function with take a UID (1000 for example) and use that to 
> remove 1000=x from all of the recirc counts for all of the containers 
> that have 1000=x.
> 
> We are currently using PG 12.0.
> 
> Thanks,
> 
> Doug
> 
> On Mon, Feb 3, 2020 at 6:21 PM Tom Lane <tgl@sss.pgh.pa.us 
> <mailto:tgl@sss.pgh.pa.us>> wrote:
> 
>     Adrian Klaver <adrian.klaver@aklaver.com
>     <mailto:adrian.klaver@aklaver.com>> writes:
>      > Please reply to list also.
> 
>      > On 2/3/20 2:18 PM, Doug Roberts wrote:
>      >> Here is what the reset recirc function is doing.
>      >> ...
>      >>     UPDATE containers
>      >> ...
> 
>      > So how did containers_reset_recirc() come to clash with
>      > containers_add_update()?
> 
>     If this is PG 12.0 or 12.1, a likely theory is that this is an
>     EvalPlanQual bug (which'd be triggered during concurrent updates
>     of the same row in the table, so that squares with the observation
>     that locking the table prevents it).  The known bugs in that area
>     require either before-row-update triggers on the table, or
>     child tables (either partitioning or traditional inheritance).
>     So I wonder what the schema of table "containers" looks like.
> 
>     Or you could have hit some new bug ... but there's not enough
>     info here to diagnose.
> 
>                              regards, tom lane
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com