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
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 |