Tom Lane wrote:
> "Kevin Grittner" writes:
>> *** a/src/backend/storage/lmgr/predicate.c
>> --- b/src/backend/storage/lmgr/predicate.c
>> ***
>> *** 274,279
>> --- 274,280
>> #define SkipSerialization(relation) \
>> ((!IsolationIsSerializable()) \
>> || ((MySeria
"Kevin Grittner" writes:
> Heikki Linnakangas wrote:
>> You can have one snapshot pushed to the active snapshot stack, and
>> do a DDL operation like reindex using a different snapshot. You'll
>> have to check the snapshot in the HeapScanDesc.
> Will look at that. Do you think it makes more se
Heikki Linnakangas wrote:
>> The attached patch has not yet been tested, but I'll test it
>> today along with the latest committed code.
>
> You can't use GetActiveSnapshot() for this.
Yeah, it didn't take much testing to find that out. I had a naive
assumption that the GetActiveSnapshot woul
On 08.06.2011 18:09, Kevin Grittner wrote:
Robert Haas wrote:
I'm wondering if this shouldn't be linked to whether the scan is
using an MVCC snapshot, rather than inserting exceptions for
specific operations.
Yeah, that was raised before somewhere and I spaced it. Grabbing
predicate locks f
"Kevin Grittner" writes:
> *** a/src/backend/storage/lmgr/predicate.c
> --- b/src/backend/storage/lmgr/predicate.c
> ***
> *** 274,279
> --- 274,280
> #define SkipSerialization(relation) \
> ((!IsolationIsSerializable()) \
> || ((MySerializableXact == InvalidSer
Robert Haas wrote:
> I'm wondering if this shouldn't be linked to whether the scan is
> using an MVCC snapshot, rather than inserting exceptions for
> specific operations.
Yeah, that was raised before somewhere and I spaced it. Grabbing
predicate locks for non-MVCC snapshots is nonsense, and
On Wed, Jun 8, 2011 at 4:59 AM, Dan Ports wrote:
> On Tue, Jun 07, 2011 at 10:14:30PM -0400, Tom Lane wrote:
>> Do you mean page zero, as in the metapage (for most index types), or do
>> you mean the root page? If the former, how is that not an outright bug,
>> since it corresponds to no data? I
On Tue, Jun 07, 2011 at 10:14:30PM -0400, Tom Lane wrote:
> Do you mean page zero, as in the metapage (for most index types), or do
> you mean the root page? If the former, how is that not an outright bug,
> since it corresponds to no data? If the latter, how is that not a
> serious performance p
On 08.06.2011 06:37, Kevin Grittner wrote:
You're right; that one was a false alarm. While REINDEX was reading
the heap to build the index it got an SIREAD lock on a *heap* page.
We never take locks on heap pages directly, so it must've been a
promotion from heap tuple locks.
While that co
Excerpts from Kevin Grittner's message of mar jun 07 20:45:43 -0400 2011:
> During testing of the SSI DDL changes I noticed that a REINDEX INDEX
> created a predicate lock on page 0 of the index.
Err, in a btree, page 0 is the metapage, not the root. The root page
moves around, but it's never pag
Dan Ports wrote:
> On Tue, Jun 07, 2011 at 07:45:43PM -0500, Kevin Grittner wrote:
>> During testing of the SSI DDL changes I noticed that a REINDEX
>> INDEX created a predicate lock on page 0 of the index.
>
> Really? That surprises me, and I couldn't reproduce it just now.
You're right; tha
On Tue, Jun 07, 2011 at 07:45:43PM -0500, Kevin Grittner wrote:
> During testing of the SSI DDL changes I noticed that a REINDEX INDEX
> created a predicate lock on page 0 of the index.
Really? That surprises me, and I couldn't reproduce it just now.
Dan
--
Dan R. K. Ports MIT CSAI
"Kevin Grittner" writes:
> During testing of the SSI DDL changes I noticed that a REINDEX INDEX
> created a predicate lock on page 0 of the index. This is pretty
> harmless, but mildly annoying. There are a few other places where
> it would be good to suppress predicate locks; these are listed o
During testing of the SSI DDL changes I noticed that a REINDEX INDEX
created a predicate lock on page 0 of the index. This is pretty
harmless, but mildly annoying. There are a few other places where
it would be good to suppress predicate locks; these are listed on
the R&D section of the Wiki. I
14 matches
Mail list logo
