| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | 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-02 15:19:41 |
| Message-ID: | 29888.1554218381@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-04-02 15:29:25 | Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed |
| Previous Message | David G. Johnston | 2019-04-02 15:12:35 | Re: BUG #15728: an index that created with keyword ONLY, when add new partition ,should not be auto created |