Re: [PoC] configurable out of disk space elog level

From: Maxim Orlov <orlovmg(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PoC] configurable out of disk space elog level
Date: 2022-11-17 11:40:02
Message-ID: CACG=ezaq_nTA3cmo8frhqOdq1P+gP6vk0RYCP4wz-L3=s7hpMw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 16 Nov 2022 at 20:41, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
> You can't do catalog access below the bufmgr.c layer. It could lead to all
> kinds of nastiness, including potentially recursing back to md.c. Even
> leaving
>
Yep, this is my biggest concern. It turns out, that the way to make such a
feature is to use just GUC for all tablespaces or
forward elevel "from above".

> that aside, we can't do catalog accesses in all kinds of environments that
> this currently is active in - most importantly it's affecting the startup
> process. We don't do catalog accesses in the startup process, and even if
> we
> were to do so, we couldn't unconditionally because the catalog might not
> even
> be consistent at this point (nor is it guaranteed that the wal_level even
> allows to access catalogs during recovery).
>
Yep, that is why I do use in get_tablespace_elevel:
+ /*
+ * Use GUC level only in normal mode.
+ */
+ if (!IsNormalProcessingMode())
+ return ERROR;

Anyway, I appreciate the opinion, thank you!

--
Best regards,
Maxim Orlov.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2022-11-17 12:04:46 Re: [PoC] Reducing planning time when tables have many partitions
Previous Message Tomas Vondra 2022-11-17 11:39:49 Re: logical decoding and replication of sequences, take 2