On Mon, May 13, 2013 at 04:39:01PM +0200, Andres Freund wrote: > On 2013-05-13 10:28:59 -0400, Noah Misch wrote: > > Each worker needs to make SnapshotNow visibility decisions coherent with the > > master. For sorting, this allows us to look up comparison functions, even > > when the current transaction created or modified those functions. > > I don't really see how you can achieve that given how SnapshotNow > works. There's nothing protecting you against one backend seeing changes > made by another transaction while another doesn't see them. SnapshotNow > doesn't even guarantee consistency within a single backend during a > single scan... > If you are meaning the above to just apply to changes made by the local > "master" backend, sure I can see that.
Yes; it only makes the workers consistent with the master to the extent that the master is consistent with itself. However, your comment makes me see that this may not be enough. For an object not protected by locks, if parallel execution probes the syscache N times where the current code probes it only once, we'll introduce new anomalies. I don't think this affects sorting in particular, because we already make little effort to behave sanely when a comparison function is redefined mid-sort. It seems likely that this will need a better answer sooner or later as we move into the parallelism space. Thanks, nm -- Noah Misch 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
