On Sat, May 6, 2017 at 7:27 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > > I've also noticed that both the atomics patch and unpatched master do > something that looks a bit weird with synchronous seq-scans. If the > parallel seq-scan piggybacked on another scan, then subsequent > parallel scans will start at the same non-zero block location, even > when no other concurrent scans exist. >
That is what we expect. The same is true for non-parallel scans as well, refer below code for non-parallel scans. heapgettup_pagemode() { .. finished = (page == scan->rs_startblock) || (scan->rs_numblocks != InvalidBlockNumber ? --scan->rs_numblocks == 0 : false); /* * Report our new scan position for synchronization purposes. We * don't do that when moving backwards, however. That would just * mess up any other forward-moving scanners. * * Note: we do this before checking for end of scan so that the * final state of the position hint is back at the start of the * rel. That's not strictly necessary, but otherwise when you run * the same query multiple times the starting position would shift * a little bit backwards on every invocation, which is confusing. * We don't guarantee any specific ordering in general, though. */ if (scan->rs_syncscan) ss_report_location(scan->rs_rd, page); .. } -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers