On Mon, Dec 20, 2010 at 7:19 PM, Florian Pflug wrote:
>> Space in the tuple header is
>> precious, and I am not at all convinced that we should be willing to
>> surrender any for this.
>
> Thats a pretty tight space to maneuver in, though. So tight, in fact,
> that I may as well give up, barring s
On Dec21, 2010, at 00:08 , Robert Haas wrote:
> My previously expressed concern about (C) wasn't based on ugliness,
> but rather on my believe that there is likely a whole lot of code
> which relies on the CTID being a self-link when no UPDATE has
> occurred. We'd have to be confident that all suc
On Mon, Dec 20, 2010 at 5:32 PM, Florian Pflug wrote:
> On Dec20, 2010, at 18:54 , Robert Haas wrote:
>> On Mon, Dec 20, 2010 at 12:49 PM, Florian Pflug wrote:
>>> For me, this is another very good reason to explore this further. Plus, it
>>> improves the ratio of grotty-ness vs. number-of-proble
On Dec20, 2010, at 18:54 , Robert Haas wrote:
> On Mon, Dec 20, 2010 at 12:49 PM, Florian Pflug wrote:
>> For me, this is another very good reason to explore this further. Plus, it
>> improves the ratio of grotty-ness vs. number-of-problems-soved ;-)
>
> By all means, look into it further. I fea
On Mon, Dec 20, 2010 at 12:49 PM, Florian Pflug wrote:
> For me, this is another very good reason to explore this further. Plus, it
> improves the ratio of grotty-ness vs. number-of-problems-soved ;-)
By all means, look into it further. I fear the boat is filling up
with water, but if you manage
On Dec20, 2010, at 17:54 , Robert Haas wrote:
> On Mon, Dec 20, 2010 at 9:11 AM, Florian Pflug wrote:
>> On Dec20, 2010, at 13:13 , Heikki Linnakangas wrote:
>>> One way to look at this is that the problem arises because SELECT FOR
>>> UPDATE doesn't create a new tuple like UPDATE does. The probl
On Mon, Dec 20, 2010 at 12:39 PM, Kevin Grittner
wrote:
> I see Florian's patch meeting a real need though,
I agree, but that whole approach seems to be foundering on the rocks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hacker
Robert Haas wrote:
> Kevin Grittner's work is a whole different approach to this
> problem, and while that's obviously not fully debugged and
> committed yet either, it's often easier to design a new tool to
> solve a particular problem than to make an existing tool that was
> really meant for s
On Mon, Dec 20, 2010 at 9:11 AM, Florian Pflug wrote:
> On Dec20, 2010, at 13:13 , Heikki Linnakangas wrote:
>> One way to look at this is that the problem arises because SELECT FOR UPDATE
>> doesn't create a new tuple like UPDATE does. The problematic case was:
>>
>>> T1 locks, T1 commits, T2 up
On Dec20, 2010, at 13:13 , Heikki Linnakangas wrote:
> One way to look at this is that the problem arises because SELECT FOR UPDATE
> doesn't create a new tuple like UPDATE does. The problematic case was:
>
>> T1 locks, T1 commits, T2 updates, T2 aborts, all after T0
>> took its snapshot but befo
On 20.12.2010 13:52, Florian Pflug wrote:
On Dec20, 2010, at 07:16 , Heikki Linnakangas wrote:
On 19.12.2010 20:57, Florian Pflug wrote:
If we reuse the legacy field xvac to store xlast, we don't get into
trouble with binary upgrades either. We' need to find a way to deal
with tuples where HEAP
On Dec20, 2010, at 07:16 , Heikki Linnakangas wrote:
> On 19.12.2010 20:57, Florian Pflug wrote:
>> If we reuse the legacy field xvac to store xlast, we don't get into
>> trouble with binary upgrades either. We' need to find a way to deal
>> with tuples where HEAP_MOVED_IN or HEAP_MOVED_OUT is set,
On 19.12.2010 20:57, Florian Pflug wrote:
If we reuse the legacy field xvac to store xlast, we don't get into
trouble with binary upgrades either. We' need to find a way to deal
with tuples where HEAP_MOVED_IN or HEAP_MOVED_OUT is set, but that
seems manageable..
xvac shares the field with comm
On Dec19, 2010, at 18:06 , Heikki Linnakangas wrote:
> I think this patch is in pretty good shape now.
Apart from the serious deficiency Robert found :-(
I'll still comment on your suggestions though, since
they'd also apply to the solution I suggested on the
other thread.
> The one thing I'm not
On Dec19, 2010, at 17:01 , Robert Haas wrote:
> On Sun, Dec 19, 2010 at 9:12 AM, Florian Pflug wrote:
>>> On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug wrote:
Note that it's sufficient to check if B can see the effects of the
*latest* locker of T. If it can see those, it must also see
On 17.12.2010 18:44, Florian Pflug wrote:
On Dec17, 2010, at 16:49 , Heikki Linnakangas wrote:
On 15.12.2010 16:20, Florian Pflug wrote:
On Dec14, 2010, at 15:01 , Robert Haas wrote:
On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug wrote:
- serializable lock consistency - I am fairly certain
On Sun, Dec 19, 2010 at 9:12 AM, Florian Pflug wrote:
>> On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug wrote:
>>> Note that it's sufficient to check if B can see the effects of the
>>> *latest* locker of T. If it can see those, it must also see the
>>> effects of any previous locker. But because
> On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug wrote:
>> Note that it's sufficient to check if B can see the effects of the
>> *latest* locker of T. If it can see those, it must also see the
>> effects of any previous locker. But because of this, B cannot
>> distinguish different lock strengths
On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug wrote:
> Yes. Otherwise, B cannot verify that the database is consistent.
>
> Note that it's sufficient to check if B can see the effects of the
> *latest* locker of T. If it can see those, it must also see the
> effects of any previous locker. But be
> My understanding of the problem is as follows. Acquiring a lock on a
> tuple prevents the tuple from being concurrently updated. You might
> take such a lock on a tuple T, make some other modification to the
> database M, and commit, in the hope that your lock will prevent a
> concurrent transa
On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug wrote:
> On Dec14, 2010, at 15:01 , Robert Haas wrote:
>> On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug wrote:
- serializable lock consistency - I am fairly certain this needs
rebasing. I don't have time to deal with it right away. That
On Dec17, 2010, at 16:49 , Heikki Linnakangas wrote:
> On 15.12.2010 16:20, Florian Pflug wrote:
>> On Dec14, 2010, at 15:01 , Robert Haas wrote:
>>> On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug wrote:
> - serializable lock consistency - I am fairly certain this needs
> rebasing. I don'
On 15.12.2010 16:20, Florian Pflug wrote:
On Dec14, 2010, at 15:01 , Robert Haas wrote:
On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug wrote:
- serializable lock consistency - I am fairly certain this needs
rebasing. I don't have time to deal with it right away. That sucks,
because I think t
23 matches
Mail list logo
