I have PostgreSQL CSV-log its errors according to this structure: https://www.postgresql.org/docs/12/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG

Sadly, from what I can tell, it neither includes in that example, or supports at all, dumping the actual script's file path as a field. This means that while I do know the application_name and other fields, I don't know which actual script caused the error, meaning my neat little HTML table which I create from this table is "blind" as to what exactly caused the error. For example:

could not receive data from client: An existing connection was forcibly closed by the remote host.

I can tell roughly which script caused that from the application_name, but I cannot build a link which would open the relevant script immediately, or make statistics about which scripts cause the most errors/log entries, to know what to prioritize fixing first.

I first thought that I could just add my own column to the table, but then I realized that this won't help, since my script which does the COPYing of the csvlog data into my table has no idea from where the entries origin, since they are not logged by PG.

I can't see any logical way around this unless PG after all does support a "file path" CSV log field. But since it's not included in the example, and not mentioned on that page (that I can see), the chances seem slim. It seems like a crucial field to me, though...

  • Oh, you are probably talking about an SQL script, not a bash script. But that case is similar: How should the database server know the name of the file from which the database client is reading statements? – Laurenz Albe Oct 16 '20 at 15:45
  • Can you give an example of a script that you are referring to? – mustaccio Oct 16 '20 at 16:50

The server only knows what the client tells it. If you want the server to "know" the pathname of the script, then have the client stuff that pathname into application_name.

Not the answer you're looking for? Browse other questions tagged or ask your own question.