Horton

Re: [PATCHES] Proposed patch: synchronized_scanning GUCvariable

Zeugswetter Andreas OSB sIT <andreas.zeugswetter@s-itsolutions.at>

View thread View on postgr.es
From: "Zeugswetter Andreas ADI SD" <Andreas.Zeugswetter@s-itsolutions.at>
To: "Guillaume Smet" <guillaume.smet@gmail.com>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Euler Taveira de Oliveira" <euler@timbira.com>, "Simon Riggs" <simon@2ndquadrant.com>, "Heikki Linnakangas" <heikki@enterprisedb.com>, "Neil Conway" <neilc@samurai.com>, "Gregory Stark" <stark@enterprisedb.com>, "Jonah H. Harris" <jonah.harris@gmail.com>, <pgsql-hackers@postgresql.org>
Date: 2008-01-30T09:56:47Z
Lists: pgsql-hackers 
> > The plural seems better to me; there's no such thing as a solitary
> > synchronized scan, no?  The whole point of the feature is to affect
> > the behavior of multiple scans.
> 
> +1. The plural is important IMHO.

ok, good.

> As I stated earlier, I don't really like this argument (we already
> broke badly designed applications a few times in the past) but we
> really need a way to guarantee that the execution of a query is stable
> and doesn't depend on external factors. And the original problem was
> to guarantee that pg_dump builds a dump as identical as possible to
> the existing data by ignoring external factors. It's now the case with
> your patch.
> The fact that it allows us not to break existing applications relying
> too much on physical ordering is a nice side effect though :).

One more question. It would be possible that a session that turned off
the synchronized_seqscans still be a pack leader for other later
sessions.
Do/should we consider that ?

The procedure would be:
start from page 0
iff no other pack is present fill the current scan position for others

Andreas