Re: [PoC] configurable out of disk space elog level - Mailing list pgsql-hackers

Hi,

On 2022-11-16 15:59:09 +0300, Maxim Orlov wrote:
> Patch is posted as PoC is attached.

> --- a/src/backend/storage/smgr/md.c
> +++ b/src/backend/storage/smgr/md.c
> @@ -40,6 +40,7 @@
>  #include "storage/sync.h"
>  #include "utils/hsearch.h"
>  #include "utils/memutils.h"
> +#include "utils/spccache.h"
>  
>  /*
>   *    The magnetic disk storage manager keeps track of open file
> @@ -479,14 +480,16 @@ mdextend(SMgrRelation reln, ForkNumber forknum, BlockNumber blocknum,
>  
>      if ((nbytes = FileWrite(v->mdfd_vfd, buffer, BLCKSZ, seekpos, WAIT_EVENT_DATA_FILE_EXTEND)) != BLCKSZ)
>      {
> +        int elevel = get_tablespace_elevel(reln->smgr_rlocator.locator.spcOid);
> +

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
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).

I'm not convinced by the usecase in the first place, but purely technically I
think it's not viable to make this a tablespace option.

Greetings,

Andres Freund