Robert Haas <robertmh...@gmail.com> wrote: >> 3. Should long transactions which are rolled back be logged as well? > > Yes.
+1 >> 4. We log the statement when exceeding log_min_duration_statement, but >> for transactions, that does not make a lot of sense, or should the last >> statement be logged? I don't think that would be particularly useful. > > This is a potentially serious problem with this whole idea, and the > idea in #2. You can log that it happened, but without some idea of > what it did, it's probably not going to be too useful. The database currently lacks two things which I have seen used for this purpose in database access middleware: an "application area" (sort of like application name, but more fine-grained and expected to change within the lifetime of a connection) and a transaction class name. For a connection related to an "In Court" application, there might be an application area of "Mass Traffic Dispo" which has 10 or 20 transaction classes. Examples of transaction classes could be to enter a Default Judgment of Guilty (for all cases scheduled for that session where the defendant didn't appear), or to Grant Time to Pay to those found guilty who have not paid the citation in full. (It could often make sense for a given transaction class to be usable from more than one application area, and for the context to be valuable.) If we added GUCs for application area and transaction class, those could be included in the log message for a long-running transaction. That would make the messages useful -- at least for occurrences when either or both were set. The question is whether people would be willing to set these GUCs to make the logging useful.... -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers