Re: Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block

On 2024/5/16 00:58, Robert Haas wrote:
> On Tue, Apr 16, 2024 at 3:16 AM Quan Zongliang <quanzongliang@yeah.net> wrote:
>> According to the discussion with Jian He. Use the guc hook to check if
>> the xid needs to be output. If needed, the statement log can be delayed
>> to be output.
> 
> I appreciate the work that both of you have put into this, but I think
> we should reject this patch and remove the TODO item. We currently
> have some facilities (like log_statement) that log the statement
> before parsing it or executing it, and others (like
> log_min_duration_statement) that log it afterward. That is probably
> not documented as clearly as it should be, but it's long-established
> behavior.
> 
> What this patch does is change the behavior of log_statement so that
> log_statement sometimes logs the statement before it's executed, and
> sometimes after the statement. I think that's going to be confusing
> and unhelpful. In particular, right now you can assume that if you set
> log_statement=all and there's a statement running, it's already been
> logged. With this change, that would sometimes be true and sometimes
> false.
> 
> For example, suppose that at 9am sharp, I run an UPDATE command that
> takes ten seconds to complete. Right now, the log_statement message
> will appear at 9am. With this change, it will run at 9am if I do it
> inside a transaction block that has an XID already, and at 9:00:10am
> if I do it in a transaction block that does not yet have an XID, or if
> I do it outside of a transaction. I don't think the benefit of getting
> the XID in the log message is nearly enough to justify such a strange
> behavior.
> 
I thought about writing statement log when xid assigned. But it's seemed 
too complicated.
I'm inclined to keep it for a while. Until we find a good way or give 
up. It's a reasonable request, after all.