On Thu, Jan 27, 2022 at 11:16 AM Andres Freund <and...@anarazel.de> wrote: > > On 2022-01-25 20:27:07 +0900, Masahiko Sawada wrote: > > > 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. >
I don't think pg_subscription_rel is the right place to store error info as the error can happen say while processing some message type like BEGIN where we can't map it to pg_subscription_rel entry. There could be other cases as well where we won't be able to map it to pg_subscription_rel like some error related to some other table while processing trigger function. In general, there doesn't appear to be much advantage in storing all the error info in system catalogs as we don't want it to be persistent (crash-safe). Also, this information is not about any system object that future operations can use, so won't map from that angle as well. But, I see the point related to the size overhead of each message (296 bytes) and that is because of the error message present in each entry. I think it would be better to store error_code instead of the message. -- With Regards, Amit Kapila.