Natalie Wenz <nataliewenz@xxxxxxxxxxx> writes: > So, I tried turning statement logging on and that didn't give me any more detail. I think that is because the query I want to inspect is generating an error (which I failed to mention in my original question). > ERROR: invalid input syntax for type double precision: "A" > STATEMENT: insert into x (a,b,c,d,e,f) VALUES ($1,$2,$3,$4,$5,$6) > columns c, d, e are all double precision, so I'm not sure which one has the bad data. If I knew what values $1 and $2 were, I could pinpoint the record that is generating the error. Ah. You're out of luck on that, I'm afraid, because what the parameter-value logging code does is to print from the converted internal forms of the parameters. If you get an error while converting the values to internal form, which is evidently what happened here, no log for you. Also, that conversion happens on-the-fly as each Bind message field is read. Thus, for example, if the bad input is for parameter $2 then we simply can't print the remaining parameter values, because we have not seen them yet. (This could be fixed, perhaps, but it would involve a lot of restructuring and probably slow things down. Also it wouldn't work for parameters arriving in binary form; which is probably what led us to make the choice to do parameter logging this way.) What I think we could do without too much trouble or overhead is to set up errcontext data so that a failure like that could come with a CONTEXT line like ERROR: invalid input syntax for type double precision: "A" STATEMENT: insert into x (a,b,c,d,e,f) VALUES ($1,$2,$3,$4,$5,$6) CONTEXT: reading parameter $2 for statement "foo" I'm curious whether that would be enough information to solve your problem. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
