Could it be related to the OFFSET part of the statement ? I have another query on the same table without OFFSET,
whichseems to work fine.
Leif
----- Original Message -----
> 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 these calls. As
> > mentioned below this specific connection has been used many times
> > before the crash. Also, we are aware of the thread caveat that
> > only using a connection from one thread at a time. Therefore the
> > "strange" connection name that includes both the process id and
> > the thread id. This is for the code to make sure that a
> > connection is only used in the thread 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