On 29.06.2011 00:33, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 28.06.2011 20:47, Kevin Grittner wrote:
Hmm, the calls in question are the ones in heapgettup() and
heapgettup_pagemode(), which are subroutines of heap_getnext().
heap_getnext() is only used in sequential scans, so it
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 29.06.2011 00:33, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 28.06.2011 20:47, Kevin Grittner wrote:
Hmm, the calls in question are the ones in heapgettup() and
heapgettup_pagemode(), which are subroutines of
On 27.06.2011 21:23, Kevin Grittner wrote:
There are two outstanding patches for SSI which involve questions
about modularity. In particular, they involve calls to predicate
locking and conflict detection from executor source files rather
than AM source files (where most such calls exist).
(1)
Heikki Linnakangas wrote:
On 27.06.2011 21:23, Kevin Grittner wrote:
The bigger question is if those calls are needed at all
(
http://archives.postgresql.org/message-id/4e072ea9.3030...@enterprisedb.com
).
Ah, I didn't properly grasp your concerns the first time I read that.
The heap
On 28.06.2011 20:47, Kevin Grittner wrote:
(3) Heap tuples are locked so that updates or deletes by an
overlapping transaction of the tuple which has been read can be
detected as a rw-conflict. Keep in mind that access for such a
delete or update may not go through the same index on which the
On Tue, Jun 28, 2011 at 1:47 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
(5) When a heap scan is executed, there is no index gap to lock to
cover the predicate involved, so we need to acquire a heap relation
lock -- any insert to the relation by an overlapping transaction is a
2011/6/28, Robert Haas robertmh...@gmail.com:
You know, it just occurred to me while reading this email that you're
using the term predicate lock in a way that is totally different
from what I learned in school. What I was taught is that the word
predicate in predicate lock is like the word
Heikki Linnakangas wrote:
On 28.06.2011 20:47, Kevin Grittner wrote:
Hmm, the calls in question are the ones in heapgettup() and
heapgettup_pagemode(), which are subroutines of heap_getnext().
heap_getnext() is only used in sequential scans, so it seems safe
to remove those calls.
I
There are two outstanding patches for SSI which involve questions
about modularity. In particular, they involve calls to predicate
locking and conflict detection from executor source files rather
than AM source files (where most such calls exist).
(1) Dan submitted this patch:
