From: | Daniel Gustafsson <dgustafsson(at)pivotal(dot)io> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, ANASTACIO Tiago <tiago_anastacio(at)yahoo(dot)fr>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15726: parallel queries failed ERROR: invalid name syntax CONTEXT: parallel worker |
Date: | 2019-04-11 08:59:41 |
Message-ID: | C6B09DDC-FDDA-466D-AFBD-F8C966CD97C1@pivotal.io |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> On 2 Apr 2019, at 21:54, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Wed, Apr 3, 2019 at 4:19 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
>>> On Tue, Apr 2, 2019 at 10:59 PM ANASTACIO Tiago
>>> <tiago_anastacio(at)yahoo(dot)fr> wrote:
>>>> A pity background worker are no more verbose (DEBUG5) than:
>>>> 2019-04-02 09:42:38.993 GMT [17654] ERROR: invalid name syntax
>>
>>> I agree, it would be nice to improve that. It seems to be a general
>>> problem with any GUC that requires a transaction to check: parallel
>>> workers will force that, but you might not understand the error
>>> because it comes with no context. That gives me an idea: perhaps we
>>> should set the elog() context while restoring GUCs, so that it is
>>> displayed in the error output somehow.
>>
>> Yeah, something like
>>
>> CONTEXT: while setting parameter guc_variable_name to "some value"
>>
>> would likely make this a whole lot more comprehensible. And I think
>> it could probably be done in a fairly centralized way using an error
>> callback.
>
> Would you want to do it for GUC setting in general (for example using
> the SET command), or just in this GUC-restore-for-parallel-query case?
> Here's a 10 minute attempt at the latter.
I think only doing it for the latter makes sense, when invoking the SET command
it’s more reasonable to associate the ERROR with the performed action.
> postgres=# set force_parallel_mode = 'on';
> SET
> postgres=# select 42;
> psql: ERROR: invalid name syntax
> CONTEXT: while setting parameter "default_text_search_config" to ""
> parallel worker
This makes it a lot better, but I wonder if it needs even more clarification to
be easily understandable by users not familiar with how parallel workers are
initiated. I’m thinking we should add “during worker setup” or something
similar to make it even clearer, albeit more verbose.
> It gets a bit repetitive in some other cases where it was already
> reporting the name and value, though:
> postgres=# select 42;
> psql: ERROR: invalid value for parameter "default_text_search_config": "foo"
> CONTEXT: while setting parameter "default_text_search_config" to "foo"
> parallel worker
It is indeed repetetive, but I’m not sure it’s worth addressing that.
Consistency in error messaging seems more important in this case.
cheers ./daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Tobias Gierke | 2019-04-11 09:05:06 | Re: BUG #15747: Help says 'application_name' property supports 64 characters in a standard built but it's only 63 |
Previous Message | Sergei Kornilov | 2019-04-11 08:58:44 | Re: BUG #15747: Help says 'application_name' property supports 64 characters in a standard built but it's only 63 |