Re: Synchronized scans

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Synchronized scans
Date: 2007-06-08 18:41:55
Message-ID: 5242.1181328115@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Fri, 2007-06-08 at 12:22 -0400, Tom Lane wrote:
>> Now that I'm awake, it is reachable code, per this comment:
>>
>> * Note: when we fall off the end of the scan in either direction, we
>> * reset rs_inited. This means that a further request with the same
>> * scan direction will restart the scan, which is a bit odd, but a

> I'm confused about this part of the comment.

If you tell the SeqScan plan node to fetch forward over and over, it
eventually will return NULL indicating end-of-data. If you then demand
*another* forward fetch, it'll start the whole scan over from scratch,
because of the fact that it sees rs_inited clear. You might've expected
another NULL but that's not what you'll get.

In general, however, the behavior of a plan node in this scenario is
not defined and not relied on by anything --- some of the join node
types will crash outright if you try to fetch past EOF, IIRC. The case
that *is* required is to be able to scan backwards after returning NULL.

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Jeff Davis 2007-06-08 18:57:09 Re: Synchronized scans
Previous Message Bruce Momjian 2007-06-08 18:36:54 Re: Controlling Load Distributed Checkpoints