Heikki Linnakangas wrote:
> On 07.10.2013 23:45, Heikki Linnakangas wrote:
>> To fix the bug that Hannu pointed out, we also need to apply these fixes:
>>
>> http://www.postgresql.org/message-id/52440266.5040...@vmware.com
>
> Per a chat with Bruce, I'm going to apply that patch now to get it int
Heikki Linnakangas wrote:
> A comment somewhere would be nice to explain why we're no longer worried
> about confusing an old tuple version with a new tuple in the same slot.
> Not sure where.
For now I counted on the commit message. Perhaps we also want to
add something to the README file?
--
On 08.10.2013 03:25, Peter Eisentraut wrote:
On Mon, 2013-10-07 at 23:49 +0300, Heikki Linnakangas wrote:
To fix the bug that Hannu pointed out, we also need to apply these fixes:
http://www.postgresql.org/message-id/52440266.5040...@vmware.com
Per a chat with Bruce, I'm going to apply that p
On Mon, 2013-10-07 at 23:49 +0300, Heikki Linnakangas wrote:
> On 07.10.2013 23:45, Heikki Linnakangas wrote:
> > On 07.10.2013 22:35, Kevin Grittner wrote:
> >> Kevin Grittner wrote:
> >>
> >>> There might be a problem if someone applies this fix while any
> >>> prepared transactions are pending.
On 07.10.2013 23:45, Heikki Linnakangas wrote:
On 07.10.2013 22:35, Kevin Grittner wrote:
Kevin Grittner wrote:
There might be a problem if someone applies this fix while any
prepared transactions are pending. Still investigating the impact
and possible fixes.
I found a one-line fix for this
On 07.10.2013 22:35, Kevin Grittner wrote:
Kevin Grittner wrote:
There might be a problem if someone applies this fix while any
prepared transactions are pending. Still investigating the impact
and possible fixes.
I found a one-line fix for this. It tested without problem.
Good catch.
T
On Mon, Oct 07, 2013 at 12:26:37PM +0300, Heikki Linnakangas wrote:
> When updating a tuple, CheckTargetForConflictsIn() only marks a
> conflict if the transaction holding the predicate lock overlapped
> with the updating transaction.
Ah, this is the bit I was forgetting. (I really ought to have
r
Kevin Grittner wrote:
> There might be a problem if someone applies this fix while any
> prepared transactions are pending. Still investigating the impact
> and possible fixes.
I found a one-line fix for this. It tested without problem.
Pushed.
--
Kevin Grittner
EDB: http://www.enterprisedb.
Kevin Grittner wrote:
> Andres Freund wrote:
>> On 2013-10-07 06:44:19 -0700, Kevin Grittner wrote:
>>
>>> Patch attached. Any objections to applying that Real Soon Now?
>>> (When, exactly is the deadline to make today's minor release
>>> cut-off?)
>>
>> Maybe it's overly careful, but I personal
Andres Freund wrote:
> On 2013-10-07 06:44:19 -0700, Kevin Grittner wrote:
>
>> Patch attached. Any objections to applying that Real Soon Now?
>> (When, exactly is the deadline to make today's minor release
>> cut-off?)
>
> Maybe it's overly careful, but I personally slightly vote for applying
>
Heikki Linnakangas wrote:
> Well, it's fairly harsh if the feature isn't working as
> advertised.
Right -- there are people counting on serializable transaction to
avoid data corruption (creation of data which violates the business
rules which they believe are being enforced). A tuple freeze at
On 2013-10-07 17:07:16 +0300, Heikki Linnakangas wrote:
> On 07.10.2013 16:58, Andres Freund wrote:
> >On 2013-10-07 06:44:19 -0700, Kevin Grittner wrote:
> >>Patch attached. Any objections to applying that Real Soon Now?
> >>(When, exactly is the deadline to make today's minor release
> >>cut-off
On 07.10.2013 16:44, Kevin Grittner wrote:
Heikki Linnakangas wrote:
So I don't think you can ever get a false conflict because of
slot reuse.
I spent some time looking at this, and I now agree.
And if there's a hole in that thinking I can't see right now, the
worst that will happen is som
On 07.10.2013 16:58, Andres Freund wrote:
On 2013-10-07 06:44:19 -0700, Kevin Grittner wrote:
Patch attached. Any objections to applying that Real Soon Now?
(When, exactly is the deadline to make today's minor release
cut-off?)
Maybe it's overly careful, but I personally slightly vote for app
On 2013-10-07 06:44:19 -0700, Kevin Grittner wrote:
> Patch attached. Any objections to applying that Real Soon Now?
> (When, exactly is the deadline to make today's minor release
> cut-off?)
Maybe it's overly careful, but I personally slightly vote for applying
it after the backbranch releases.
Kevin Grittner wrote:
> Patch attached. Any objections to applying that Real Soon Now?
Oh, without the new line in predicate.h.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Heikki Linnakangas wrote:
> So I don't think you can ever get a false conflict because of
> slot reuse.
I spent some time looking at this, and I now agree.
> And if there's a hole in that thinking I can't see right now, the
> worst that will happen is some unnecessary conflicts, ie. it's
> stil
On 06.10.2013 20:34, Kevin Grittner wrote:
Note this comment, which I think was written by Heikki back when
there was a lot more benchmarking and profiling of SSI going on:
* Because a particular target might become obsolete, due to update to a new
* version, before the reading transaction
Kevin Grittner wrote:
> Kevin Grittner wrote:
>
>> I'm strongly leaning toward the idea that a slightly tweaked
>> version of the proposed patch is appropriate for the back-branches,
>> because the fix Heikki is now suggesting seems too invasive to
>> back-patch. I think it would make sense to a
Andres Freund wrote:
>>> On 2013-10-03 21:14:17 -0700, Dan Ports wrote:
> Heikki Linnakangas wrote:
>> IMHO it would be better to remove xmin from the lock key,
>> and vacuum away the old predicate locks when the
>> corresponding tuple is vacuumed.
>> The xmin field is only re
On 04.10.2013 14:02, Andres Freund wrote:
But locks on those still can have meaning, right? From my very limited
understanding of predicate.c/SSI I don't see why we cannot have
meaningful conflicts on tuples that are already vacuumable. You'd need
some curiously interleaved transactions, sure, bu
On 2013-10-04 13:51:00 +0300, Heikki Linnakangas wrote:
> On 04.10.2013 13:23, Andres Freund wrote:
> >On 2013-10-03 21:14:17 -0700, Dan Ports wrote:
> >>On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
> >>>Heikki Linnakangas wrote:
> IMHO it would be better to remove xmin from
On 04.10.2013 13:23, Andres Freund wrote:
On 2013-10-03 21:14:17 -0700, Dan Ports wrote:
On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
Heikki Linnakangas wrote:
IMHO it would be better to remove xmin from the lock key, and vacuum
away the old predicate locks when the corresp
On 2013-10-03 21:14:17 -0700, Dan Ports wrote:
> On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
> > Heikki Linnakangas wrote:
> > > IMHO it would be better to remove xmin from the lock key, and vacuum
> > > away the old predicate locks when the corresponding tuple is vacuumed.
> >
On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
> Heikki Linnakangas wrote:
> > IMHO it would be better to remove xmin from the lock key, and vacuum
> > away the old predicate locks when the corresponding tuple is vacuumed.
> > The xmin field is only required to handle the case tha
Heikki Linnakangas wrote:
> IMHO it would be better to remove xmin from the lock key, and vacuum
> away the old predicate locks when the corresponding tuple is vacuumed.
> The xmin field is only required to handle the case that a tuple is
> vacuumed, and a new unrelated tuple is inserted to the s
On 03.10.2013 01:05, Kevin Grittner wrote:
Andres Freund wrote:
On 2013-10-01 07:41:46 -0700, Kevin Grittner wrote:
Andres Freund wrote:
A better solution probably is to promote tuple-level locks if
they exist to a relation level one upon freezing I guess?
It would be sufficient to promot
On 2013-10-01 07:41:46 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > A better solution probably is to promote tuple-level locks if
> > they exist to a relation level one upon freezing I guess?
>
> It would be sufficient to promote the tuple lock to a page lock.
> It would be pretty e
Andres Freund wrote:
> A better solution probably is to promote tuple-level locks if
> they exist to a relation level one upon freezing I guess?
It would be sufficient to promote the tuple lock to a page lock.
It would be pretty easy to add a function to predicate.c which
would accept a Relation
On 23.09.2013 01:07, Hannu Krosing wrote:
On 09/20/2013 12:55 PM, Heikki Linnakangas wrote:
Hi,
Prompted by Andres Freund's comments on my Freezing without Write I/O
patch, I realized that there's there's an existing bug in the way
predicate locking handles freezing (or rather, it doesn't handl
On 21.09.2013 23:46, Andres Freund wrote:
Heikki Linnakangas schrieb:
Kevin Grittner wrote:
Andres Freund wrote:
On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
When a tuple is predicate-locked, the key of the lock is
ctid+xmin.
However, when a tuple is frozen, its xmin is chan
On 22.09.2013 00:12, Hannu Krosing wrote:
On 09/21/2013 10:46 PM, Andres Freund wrote:
Heikki Linnakangas schrieb:
Kevin Grittner wrote:
Andres Freund wrote:
On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
When a tuple is predicate-locked, the key of the lock is
ctid+xmin.
Howe
On 09/20/2013 12:55 PM, Heikki Linnakangas wrote:
> Hi,
>
> Prompted by Andres Freund's comments on my Freezing without Write I/O
> patch, I realized that there's there's an existing bug in the way
> predicate locking handles freezing (or rather, it doesn't handle it).
>
> When a tuple is predicate
On 09/21/2013 10:46 PM, Andres Freund wrote:
>
> Heikki Linnakangas schrieb:
>> Kevin Grittner wrote:
>>> Andres Freund wrote:
> On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
>> When a tuple is predicate-locked, the key of the lock is
>> ctid+xmin.
>> However, when a tuple
Heikki Linnakangas schrieb:
>Kevin Grittner wrote:
>>Andres Freund wrote:
On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
> When a tuple is predicate-locked, the key of the lock is
>ctid+xmin.
> However, when a tuple is frozen, its xmin is changed to FrozenXid.
>>That
Kevin Grittner wrote:
>Andres Freund wrote:
>>> On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
When a tuple is predicate-locked, the key of the lock is ctid+xmin.
However, when a tuple is frozen, its xmin is changed to FrozenXid.
>That
effectively
invalidates any pred
Andres Freund wrote:
>> On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
>>> When a tuple is predicate-locked, the key of the lock is ctid+xmin.
>>> However, when a tuple is frozen, its xmin is changed to FrozenXid. That
>>> effectively
>>> invalidates any predicate lock on the tuple, as ch
On 2013-09-20 13:53:04 +0200, Andres Freund wrote:
> Hi,
>
>
> On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
> > When a tuple is predicate-locked, the key of the lock is ctid+xmin. However,
> > when a tuple is frozen, its xmin is changed to FrozenXid. That effectively
> > invalidates an
Hi,
On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
> When a tuple is predicate-locked, the key of the lock is ctid+xmin. However,
> when a tuple is frozen, its xmin is changed to FrozenXid. That effectively
> invalidates any predicate lock on the tuple, as checking for a lock on the
> sa
Hi,
Prompted by Andres Freund's comments on my Freezing without Write I/O
patch, I realized that there's there's an existing bug in the way
predicate locking handles freezing (or rather, it doesn't handle it).
When a tuple is predicate-locked, the key of the lock is ctid+xmin.
However, when
40 matches
Mail list logo
