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