Re: Operation log for major operations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Operation log for major operations
Date: 2023-03-02 19:36:43
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> On Thu, Mar 02, 2023 at 08:57:43PM +0300, Dmitry Koval wrote:
>> These changes did not interest the community. It was expected (topic is very
>> specifiс: vendor's technical support). So no sense to distract developers

> Actually, I think there is interest, but it has to be phrased in a
> limited sense to go into the control file.

> In November, I referenced 2 threads, but I think you misunderstood one
> of them. If you skim the first couple mails, you'll find a discussion
> about recording crash information in the control file.


> It's come up several times now, and there seems to be ample support for
> adding some limited information.

> But a "log" which might exceed a few dozen bytes (now or later), that's
> inconsistent with the pre-existing purpose served by pg_control.

I'm pretty dubious about recording *anything* in the control file.
Every time we write to that, we risk the entire database on completing
the write successfully. I don't want to do that more often than once
per checkpoint. If you want to put crash info in some less-critical
place, maybe we could talk.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message reid.thompson 2023-03-02 19:41:26 Re: Add the ability to limit the amount of memory that can be allocated to backends.
Previous Message Tom Lane 2023-03-02 19:33:35 Re: Evaluate arguments of correlated SubPlans in the referencing ExprState