On Wed, Apr 3, 2019 at 4:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > On Tue, Apr 2, 2019 at 10:59 PM ANASTACIO Tiago
> > <tiago_anastacio@yahoo.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.
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
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
--
Thomas Munro
https://enterprisedb.com
