From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Sudden FTS-related error from parallel worker in 9.6 |
Date: | 2016-10-08 06:38:14 |
Message-ID: | CAA4eK1JquS4_zSiEAPJGNBJ2P-d5iVPM_NFFQHmAQmgngMKBrA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, Oct 8, 2016 at 11:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>> ... So, I think here one
>> argument is that we can use error level other than ERROR during worker
>> startup, but not sure if that is improvement over current behaviour.
>> Certainly, if we are not able to restore any guc, it is better not to
>> proceed for execution in worker as I think that can lead to erroneous
>> results.
>
> The real problem here, I think, is that this report indicates that it's
> possible for a worker to try to execute a query with GUC settings
> different from its parent. Which means it could deliver results different
> than the parent would get. That's unacceptable.
>
> In Nikolay's report, we get an error because postgresql.conf contains
> an invalid value, but what if it had contained a valid value that was
> different from the parent session's? That's entirely legit, in case
> the file has been edited but the DBA hasn't yet issued SIGHUP.
>
> The mechanism needs to be fixed so that the worker absorbs EXACTLY the
> settings that prevail in the parent, no matter what is currently in
> postgresql.conf.
>
Hmm, currently the leader process serialize the guc values that
prevail before the launch of workers and then workers restore those
values (refer SerializeGUCState and RestoreGUCState). I am not sure
what makes you think that we are doing something else.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simplex | 2016-10-10 09:38:08 | memory leak in libpq , definitely lost: 200 bytes in 1 blocks, indirectly lost: 2,048 bytes in 1 blocks ... |
Previous Message | Tom Lane | 2016-10-08 05:43:57 | Re: Sudden FTS-related error from parallel worker in 9.6 |