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

From Petr Jelinek
Subject Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c
Date
Msg-id 22cc402c-88eb-fa35-217f-0060db2c72f0@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c  (Erik Rijkers <er@xs4all.nl>)
List pgsql-hackers
On 02/05/17 20:43, Robert Haas wrote:
> On Thu, Apr 20, 2017 at 2:58 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> On 4/16/17 16:11, Petr Jelinek wrote:
>>> Yeah it is, it needs to be fenced to happen only after commit, which is
>>> not guaranteed at the point of code, we probably need to put the
>>> pgstat_report_stat() inside the if above after the
>>> CommitTransactionCommand() (that will make it report stats for changes
>>> apply did to pg_subscription_rel after next transaction though)
>>
>> I think to avoid the latter, we should add more pgstat_report_stat()
>> calls, such as in process_syncing_tables_for_apply().  Basically every
>> 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.

-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Inefficient shutdown of pg_basebackup
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Time based lag tracking for logical replication