Robert Haas <robertmhaas@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
