On Tue, Apr 16, 2024 at 3:16 AM Quan Zongliang <quanzongli...@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. -- Robert Haas EDB: http://www.enterprisedb.com
