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

From Robert Haas
Subject Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c
Date
Msg-id CA+TgmoYXdVPaUycSd-mC-4fZNFkGsUKb8DyYb1J6SV7C-ffgWA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
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?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Bug in prepared statement cache invalidation?
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Typos in comments in partition.c