Any ExecStoreTuple end runs?
in [PgSql]
|
From: Tom Lane on 12 Jan 2010 18:39 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > Hopefully this won't digress into a top-to-bottom discussion of all > aspects of implementing serializable transactions again, but I have > what I hope is a quick question. > The "easy" part of implementing SIREAD level predicate locking > should be to get a lock on each visible tuple which is read in the > execution of the plan. Is it safe to assume that ExecStoreTuple is > used for any such access? It's obviously too low level to be the > right place to check whether we're in serializable mode and take out > locks, but if I look at the callers (like IndexNext or TidNext) > which use a valid buffer in a call to ExecStoreTuple, should I be > catching all the tuples read from the heap? It doesn't really matter, because any patch putting such functionality into ExecStoreTuple would be rejected. It's an utterly inappropriate place. If there's any single place where it would be sane to do that, it'd be ExecScan(). However, that's used for both scans of physical relations and things like VALUES and function RTEs, so I'm not sure that's a very good choice either --- having it know where to find the relation being scanned is really a violation of modularity. I think you'd probably be best off to put the hook in SeqNext, IndexNext, etc. Sometimes multiple call sites are the cleanest solution. Another reason to do that is that you'll need to migrate the functionality down towards indexes later, so trying to have one-size-fits-all code that's ignorant of the type of scan being done seems like a dead end anyway. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 12 Jan 2010 18:48 Tom Lane wrote: "Kevin Grittner" writes: >> It's obviously too low level to be the right place to check >> whether we're in serializable mode and take out locks, but if I >> look at the callers (like IndexNext or TidNext) which use a valid >> buffer in a call to ExecStoreTuple, should I be catching all the >> tuples read from the heap? > It doesn't really matter, because any patch putting such functionality > into ExecStoreTuple would be rejected. It's an utterly inappropriate > place. Which is what I said. > I think you'd probably be best off to put the hook in SeqNext, > IndexNext, etc. Sometimes multiple call sites are the cleanest > solution. Which is what I said. I'm glad we agree. From your response, I assume that there aren't any end runs to cover. Thanks, -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Pages: 1 Prev: [HACKERS] Any ExecStoreTuple end runs? Next: [HACKERS] xml2 still essential for us |