From: | Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com> |
---|---|
To: | Sergei Kornilov <sk(at)zsrv(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Subject: | Re: Log query parameters for terminated execute |
Date: | 2018-07-23 10:19:24 |
Message-ID: | CALtqXTcAdWCb1OgWSUp48h36jG1o2fTQBmFTF+Thtab9yD50Bw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 23, 2018 at 3:05 PM, Sergei Kornilov <sk(at)zsrv(dot)org> wrote:
> Hello
> Thank you for review!
> Well, i can miss some cases. I'm not sure about overall design of this
> patch. Is acceptable add errdetail_params to statement_timeout ereport in
> such way?
>
> After shutdown signal we must be in aborted state, so we mustn't call
> user-defined I/O functions. (quotation from comment to errdetail_params in
> src/backend/tcop/postgres.c ). It seems i can not fix it with current
> design.
>
No its not about calling the function after abort/shutdown. Just start the
server and try to run the program, most of the time you will not get
params.
>
> > ERROR: canceling statement due to lock timeout at character 13
> Hm, "at character"? How can we get this message? I found only "canceling
> statement due to lock timeout" (without "at character") ereport in
> src/backend/tcop/postgres.c
> Maybe try .. catch in parse state, not in execute?
>
Its really easy to reproduce, just lock the table form another session and
run a "c" program to insert row in the same table.
>
> regards, Sergei
>
--
Ibrar Ahmed
From | Date | Subject | |
---|---|---|---|
Next Message | Ibrar Ahmed | 2018-07-23 10:34:38 | Re: Log query parameters for terminated execute |
Previous Message | Thomas Munro | 2018-07-23 10:06:58 | Re: Possible performance regression in version 10.1 with pgbench read-write tests. |