Could it be related to the OFFSET part of the statement ? I have another query on the same table without OFFSET, which seems to work fine. Leif ----- Original Message ----- > Leif Jensen <leif@xxxxxxxxxxx> 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
