On Thu, Jan 27, 2022 at 11:16 AM Andres Freund <andres@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.
