Date: Wed, 26 Jan 2022 21:46:06 -0800
From: Andres Freund <andres@anarazel.de>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: pgsql-hackers@postgresql.org, Amit Kapila <amit.kapila16@gmail.com>
Subject: Re: Design of pg_stat_subscription_workers vs pgstats
Message-ID: <20220127054606.7schba5oizo7jijf@alap3.anarazel.de>
References: <20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de>
 <CAD21AoCM0RZuLk+dOvTOGWJwxtgzSmTOKkvmGGWC6gytWSERFg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAD21AoCM0RZuLk+dOvTOGWJwxtgzSmTOKkvmGGWC6gytWSERFg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20220127054606.7schba5oizo7jijf%40alap3.anarazel.de>
Precedence: bulk

Hi,

I didn't quite get to responding in depth, but I wanted to at least respond to
one point today.

On 2022-01-25 20:27:07 +0900, Masahiko Sawada wrote:
> > The pgstat entries are quite wide (292 bytes), because of the error message
> > stored. That's nearly twice the size of PgStat_StatTabEntry. And as far as I
> > can tell, once there was an error, we'll just keep the stats entry around
> > until the subscription is dropped.
> 
> We can drop the particular statistics by
> pg_stat_reset_subscription_worker() function.

Only if either the user wants to drop all stats, or somehow knows the oids of
already dropped tables...


> > Why isn't this just storing data in pg_subscription_rel?
> 
> These need to be updated on error which means for a failed xact and we
> don't want to update the system catalog in that state.

Rightly so! In fact, I'm concerned with sending a pgstats message in that
state as well. But: You don't need to. Just abort the current transaction,
start a new one, and update the state.


> There will be some challenges in a case where updating pg_subscription_rel
> also failed too (what to report to the user, etc.). And moreover, we don't
> want to consume space for temporary information in the system catalog.

You're consuming resources in a *WAY* worse way right now. The stats file gets
constantly written out, and quite often read back by backends. In contrast to
parts of pg_subscription_rel or such that data can't be removed from
shared_buffers under pressure.

Greetings,

Andres Freund