On Wed, Aug 9, 2017 at 1:27 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2017-08-08 21:55:50 +0200, Michael Paquier wrote:
>> On Tue, Aug 8, 2017 at 9:51 PM, Andres Freund <andres@anarazel.de> wrote:
>> > Perhaps, for v11, we should actually make sure there's no memory context
>> > etc set during _PG_init() to catch such problems earlier? It's a bit
>> > nasty to only see them if the shared library is preloaded and/or
>> > parallelism is in use.
>>
>> Yeah, some prevention like that would be a good idea for module
>> developers.
>
>> We could also check for a higher-level thing like being sure that
>> there is no transaction context?
>
> Not quite sure what you mean by that? And if you just mean to ensure
> that _PG_init() is called outside of a transaction - how? We load shared
> libraries on demand when they're used - and that'll frequently be in a
> transaction?
>
Yes. I was also thinking along those lines and don't you think we
should better do RestoreLibraryState in a transaction in the parallel
worker. Currently, we restore GUCState in a transaction and I think
LibraryState can also be restored in a transaction (See
ParallelWorkerMain). I have checked locally and it seems to be
working.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
