From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: should we document an example to set multiple libraries in shared_preload_libraries? |
Date: | 2021-12-01 13:55:40 |
Message-ID: | CALj2ACVVoFctnh0vnzaF94gHfSYnOqM=1K1wu64veU+7+p-s=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 1, 2021 at 6:45 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> > +1 to document it, but it seems like the worse problem is allowing the admin to
> > write a configuration which causes the server to fail to start, without having
> > issued a warning.
>
> > I think you could fix that with a GUC check hook to emit a warning.
> > I'm not sure what objections people might have to this. Maybe it's confusing
> > to execute preliminary verification of the library by calling stat() but not do
> > stronger verification for other reasons the library might fail to load. Like
> > it doesn't have the right magic number, or it's built for the wrong server
> > version. Should factor out the logic from internal_load_library and check
> > those too ?
>
> Considering the vanishingly small number of actual complaints we've
> seen about this, that sounds ridiculously over-engineered.
> A documentation example should be sufficient.
Thanks. Here's the v1 patch adding examples in the documentation.
Regards,
Bharath Rupireddy.
Attachment | Content-Type | Size |
---|---|---|
v1-0001-document-examples-of-setting-up-multiple-values-f.patch | application/octet-stream | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2021-12-01 14:09:04 | Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData? |
Previous Message | Amit Kapila | 2021-12-01 13:36:17 | Re: Non-superuser subscription owners |