|From:||Sergei Kornilov <sk(at)zsrv(dot)org>|
|To:||Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>|
|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>> 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.
So, I was right. We can got "canceling statement due to lock timeout at character 13" only in PARSE state. In parse state we have completely no parameters, we receive parameters only later in BIND message. I can not log data from future.
And initially i did change only EXECUTE. Attached patch with similar change in BIND message, if this design is acceptable.
Please test with logging command tag %i in log_line_prefix. Extended protocol has three different messages, each can be canceled by timeout. But here is completely no parameters in PARSE and i did not change BIND in first patch.
|Next Message||Amit Kapila||2018-07-23 11:36:11||Re: [bug fix] Produce a crash dump before main() on Windows|
|Previous Message||Nikhil Sontakke||2018-07-23 11:01:50||Re: [HACKERS] logical decoding of two-phase transactions|