Re: [15] Custom WAL resource managers, single user mode, and recovery - Mailing list pgsql-bugs

From Andres Freund
Subject Re: [15] Custom WAL resource managers, single user mode, and recovery
Date
Msg-id 20220715033215.7dubjyp4tbl3zkot@awork3.anarazel.de
Whole thread Raw
In response to Re: [15] Custom WAL resource managers, single user mode, and recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [15] Custom WAL resource managers, single user mode, and recovery
List pgsql-bugs
Hi,

On 2022-07-14 20:48:57 -0400, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > If a user has custom table access methods, those are likely to be
> > required during single user mode anyway (to VACUUM, for instance), so
> > we need to be able to load modules during single user mode. I can't
> > think of a reason specifically why we can't process
> > shared_preload_libraries. Thoughts?
> 
> Hmm.  There may have been some idea that a library might fail in
> single-user mode, and/or have been the cause of you needing to
> use single-user in the first place.  But if so, you can always
> edit it out of shared_preload_libraries.  I agree that not
> having the option to load it isn't great.

+1


> I think that the patch might be missing some stuff.  In postmaster.c,
> there are several steps after process_shared_preload_libraries()
> that look to be there to support loadable libraries, such as
> process_shmem_requests().  Wouldn't it be reasonable to expect
> that a loadable library would malfunction without those?

+1


> (I wonder if we shouldn't refactor this so that the postmaster
> and standalone mode share more of the initialization logic.
> Keeping these bits in sync seems unlikely to happen otherwise.)

Yes, that might be worthwhile. OTOH, I wonder if we should spend that time to
remove single user mode instead - the architectural complexity really doesn't
seem worth it anymore, and IMO my prototype from a few months back showed that
it's feasible.

Greetings,

Andres Freund



pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands
Next
From: Andres Freund
Date:
Subject: Re: Auto-vacuum timing out and preventing connections