Heikki Linnakangas 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 heap_getnext().
>>> heap_getnex
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 s
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
2011/6/28, Robert Haas :
> 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 "tuple" in "
On Tue, Jun 28, 2011 at 1:47 PM, Kevin Grittner
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
> rw-conflict. While these *lo
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
c
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 r
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)
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:
http://archives
