Leif Jensen <leif@crysberg.dk> writes:
> Here is a gdb dump of the backtrace at the server process crash. I have also included the code that generates
thesecalls. As mentioned below this specific connection has been used many times before the crash. Also, we are aware
ofthe thread caveat that only using a connection from one thread at a time. Therefore the "strange" connection name
thatincludes both the process id and the thread id. This is for the code to make sure that a connection is only used in
thethread it is meant to.
Hm. The crash looks like it must be because ActiveSnapshot is null
(not set). Since we're doing a FETCH, the active snapshot ought to
be the one saved for the cursor query by DECLARE CURSOR. It looks
like the problem is that pquery.c only bothers to install that as the
active snapshot while calling ExecutorRun, but in this stack trace
we're in ExecutorRewind.
I wonder if it's a bad idea for ExecReScanLimit to be executing
user-defined expressions? But it's been like that for awhile,
and I think we might have a hard time preserving the bounded-sort
optimization if we didn't do that.
Anyway the simple fix would be to ensure we install the query
snapshot as active before calling ExecutorRewind.
One interesting question is why this issue hasn't been seen before;
it seems like it'd not be that hard to hit.
regards, tom lane