Re: Logical replication - TRAP: FailedAssertion in pgstat.c

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Erik Rijkers <er(at)xs4all(dot)nl>, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org
Subject: Re: Logical replication - TRAP: FailedAssertion in pgstat.c
Date: 2017-05-02 18:43:28
Message-ID: CA+TgmoYXdVPaUycSd-mC-4fZNFkGsUKb8DyYb1J6SV7C-ffgWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 20, 2017 at 2:58 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-05-02 18:51:35 Re: Typos in comments in partition.c
Previous Message Robert Haas 2017-05-02 18:40:38 Re: Concurrent ALTER SEQUENCE RESTART Regression