On Fri, Nov 15, 2013 at 3:21 PM, Robert Haas <robertmh...@gmail.com> wrote: > > I think what would help the most is if you could arrange to obtain a > stack backtrace at the point when the error is thrown. Maybe put a > long sleep call in just before the error happens, and when it gets > stuck there, attach gdb and run bt full. >
That could potentially be doable. Perhaps I could use something like google-coredumper or something similar to have a core dump generated if the error comes up? Part of the problem is that the error is so sporadic that it's going to be tough to say when the next one will occur. For instance, we haven't changed our load on the server, yet the error hasn't occurred since Nov 13, 15:01. I'd also like to avoid blocking on the server with sleep or anything like that unless absolutely necessary, as there are other services we have in development that are using other databases on this cluster. (I can as a matter of last resort, of course, but if google-coredumper can do the job I'd like to give that a shot first.) Any hints on where I could insert something like this? Should I try putting it into the section of elog.c dealing with ENOENT errors, or try to find a spot closer to where the file itself is being opened? I haven't looked at Postgres internals for a while now so I'm not quite sure of the best location for this sort of thing. Cheers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers