Re: fix bgworkers in EXEC_BACKEND

From: "anarazel(at)anarazel(dot)de" <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fix bgworkers in EXEC_BACKEND
Date: 2012-12-28 00:28:49
Message-ID: 2e558203-cdd1-4bec-9cec-b50b9893e186@email.android.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> schrieb:

>Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>> I am still worried about the following scenario in the EXEC_BACKEND
>case:
>
>> 1) postmaster starts
>> 2) reads config
>> 3) executes _PG_init for shared_preload_libraries
>> 4) library 'abc' gets config value 'abc.num_workers = 2' and
>registers as many workers
>> 5) some time goes by, workers, backends start
>> 6) abc.num_workers gets changed to 3, SIGHUP
>
>This is broken whether it's EXEC_BACKEND or not: you don't get to
>change
>anything that determines the number of workers post-startup.
>num_workers should have been declared PGC_POSTMASTER.

BTW, I think it happens not to be broken in the non EXEC_BACKEND case because the registration point for bgworkers is _PG_init which will only be called once without EXEC_BACKEND, so config changes to SIGHUP'able variables won't change a thing dangerous as the bgworker stuff is all set up.

Andres

---
Please excuse the brevity and formatting - I am writing this on my mobile phone.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2012-12-28 02:14:58 Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Previous Message Andres Freund 2012-12-27 23:48:50 Re: fix bgworkers in EXEC_BACKEND