Re: [BUGFIX] amcanbackward is not checked before building backward index paths - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: [BUGFIX] amcanbackward is not checked before building backward index paths
Date
Msg-id 87r2ma43hl.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: [BUGFIX] amcanbackward is not checked before building backwardindex paths  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
>>>>> "Alvaro" == Alvaro Herrera <alvherre@2ndquadrant.com> writes:

 >> "Can the scan direction be changed in mid-scan (to support FETCH
 >> FORWARD and FETCH BACKWARD on a cursor)?"

How about,

"Can the scan direction be changed in mid-scan (to support FETCH
BACKWARD on a cursor without needing materialization)?"

 Alvaro> To me that sounds like the flag is a prerequisite of using the
 Alvaro> cursor in either direction. But maybe "to support both FETCH
 Alvaro> FORWARD and FETCH BACKWARD on the same cursor" is sufficient.
 Alvaro> Or maybe "to support changing scan direction on a cursor".

 Alvaro> To make matters worse, IIUC it's actually fine to read the
 Alvaro> cursor in one direction to completion, then in the other
 Alvaro> direction to completion, without this flag, right?

If you explicitly declare your cursor as SCROLL, which you should do if
you want to fetch backward in it, then it's always OK to switch
directions - the planner will have inserted a Materialize node if one is
needed. If you didn't declare it with SCROLL, and it's not implicitly
SCROLL as per the rules below, you can't fetch backward in it at all
regardless of whether you reached the end. (see error message in
PortalRunSelect for where this happens)

(I found a bit of a wart in that code: MOVE/FETCH ABSOLUTE will
arbitrarily fail or not fail on a no-scroll cursor according to the
absolute position requested - if it's closer to 1 than the current
position it'll rewind to the start, which always works, then scan
forwards; but if it's closer to the current position, it'll try moving
backwards even in a no-scroll cursor.)

What amcanbackward actually affects, as I read the code, is this:

1. ExecSupportsBackwardScan applied to an IndexScan or IndexOnlyScan is
   true if and only if amcanbackward is true.

2. If you specify neither SCROLL nor NO SCROLL when creating a cursor,
   then the cursor is implicitly SCROLL if and only if the topmost plan
   node returns true from ExecSupportsBackwardScan.

3. If you specify SCROLL when creating a cursor, then the planner
   inserts a Materialize node on the top of the plan if
   ExecSupportsBackwardScan is not true of the previous top plan node.

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PROPOSAL] Shared Ispell dictionaries
Next
From: Tom Lane
Date:
Subject: Re: [BUGFIX] amcanbackward is not checked before building backward index paths