Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c - Mailing list pgsql-hackers

From Erik Rijkers
Subject Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c
Date
Msg-id b2c7513379be13c0ac5d95648d78db48@xs4all.nl
Whole thread Raw
In response to Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c  (Noah Misch <noah@leadboat.com>)
Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
On 2017-05-03 08:17, Petr Jelinek wrote:
> On 02/05/17 20:43, Robert Haas wrote:
>> On Thu, Apr 20, 2017 at 2:58 PM, Peter Eisentraut

>>> code path that calls CommitTransactionCommand() should have one, no?
>> 
>> Is there anything left to be committed here?
>> 
> 
> Afaics the fix was not committed. Peter wanted more comprehensive fix
> which didn't happen. I think something like attached should do the job.

I'm running my pgbench-over-logical-replication test in chunk of 15 
minutes, wth different pgbench -c (num clients) and -s (scale) values.

With this patch (and nothing else)  on top of master (8f8b9be51fd7 to be 
precise):

> fix-statistics-reporting-in-logical-replication-work.patch

logical replication is still often failing (as expected, I suppose; it 
seems because of "inital snapshot too large") but indeed I do not see 
the 'TRAP: FailedAssertion in pgstat.c' anymore.

(If there is any other configuration of patches worth testing please let 
me know)

thanks

Erik Rijkers




pgsql-hackers by date:

Previous
From: Stas Kelvich
Date:
Subject: Re: [HACKERS] Logical replication ApplyContext bloat
Next
From: Heikki Linnakangas
Date:
Subject: [HACKERS] password_encryption, default and 'plain' support