Robert Haas writes:
> On Mon, Nov 26, 2012 at 10:55 AM, Tom Lane wrote:
>> We have to do something about this one way or another before we can ship
>> 9.2.2. Is the consensus to revert this patch:
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d573e239f03506920938bf0be56c86
On Mon, Nov 26, 2012 at 10:55 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 October 2012 20:43, Tom Lane wrote:
>>> Robert Haas writes:
So we have to take the snapshot before you begin execution, but it
seems that to avoid surprising behavior we also have to take it after
ac
Simon Riggs writes:
> On 11 October 2012 20:43, Tom Lane wrote:
>> Robert Haas writes:
>>> So we have to take the snapshot before you begin execution, but it
>>> seems that to avoid surprising behavior we also have to take it after
>>> acquiring locks. And it looks like locking is intertwined w
On Thu, Oct 11, 2012 at 7:53 PM, Tom Lane wrote:
> Maybe what we really need is to find a way to make taking a snapshot a
> lot cheaper, such that the whole need for this patch goes away. We're
> not going to get far with the idea of making SnapshotNow MVCC-safe
> unless it becomes a lot cheaper
On 11 October 2012 20:43, Tom Lane wrote:
> Robert Haas writes:
>> So we have to take the snapshot before you begin execution, but it
>> seems that to avoid surprising behavior we also have to take it after
>> acquiring locks. And it looks like locking is intertwined with a
>> bunch of other par
Robert Haas writes:
> So we have to take the snapshot before you begin execution, but it
> seems that to avoid surprising behavior we also have to take it after
> acquiring locks. And it looks like locking is intertwined with a
> bunch of other parse analysis tasks that might require a snapshot t
On 11 October 2012 20:25, Robert Haas wrote:
> On Thu, Oct 11, 2012 at 2:48 PM, Simon Riggs wrote:
>> Hmm, so now the patch author thinks his patch is not just broken with
>> respect to lock waits, but in all cases? Surely the above race
>> condition is obvious, now and before. Why is it suddenly
On Thu, Oct 11, 2012 at 2:48 PM, Simon Riggs wrote:
> Hmm, so now the patch author thinks his patch is not just broken with
> respect to lock waits, but in all cases? Surely the above race
> condition is obvious, now and before. Why is it suddenly unacceptable?
> (If you believe that, why on earth
On 11 October 2012 19:41, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 October 2012 18:22, Tom Lane wrote:
>>> If it worked, I might be amenable to that, but it doesn't. You can't
>>> trigger taking a new snapshot off whether we waited for a lock; that
>>> still has race conditions, just ones
On 11 October 2012 19:36, Robert Haas wrote:
> On Thu, Oct 11, 2012 at 2:23 PM, Simon Riggs wrote:
>> So where's the race?
>>
>> AFAICS it either waits or it doesn't - the code isn't vague on that
>> point. If we wait we set the flag.
>>
>> The point is that lock waits are pretty rare since most
Simon Riggs writes:
> On 11 October 2012 18:22, Tom Lane wrote:
>> If it worked, I might be amenable to that, but it doesn't. You can't
>> trigger taking a new snapshot off whether we waited for a lock; that
>> still has race conditions, just ones that are not so trivial to
>> demonstrate manual
On Thu, Oct 11, 2012 at 2:23 PM, Simon Riggs wrote:
> So where's the race?
>
> AFAICS it either waits or it doesn't - the code isn't vague on that
> point. If we wait we set the flag.
>
> The point is that lock waits are pretty rare since most locks are
> compatible, so triggering a second snap if
On 11 October 2012 18:22, Tom Lane wrote:
>> I suggested a way to automatically trigger a second snapshot. I think
>> that would be acceptable to backpatch.
>
> If it worked, I might be amenable to that, but it doesn't. You can't
> trigger taking a new snapshot off whether we waited for a lock;
Simon Riggs writes:
> On 11 October 2012 17:53, Tom Lane wrote:
>> Maybe what we really need is to find a way to make taking a snapshot a
>> lot cheaper, such that the whole need for this patch goes away. We're
>> not going to get far with the idea of making SnapshotNow MVCC-safe
>> unless it be
On 11 October 2012 17:53, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 October 2012 01:43, Tom Lane wrote:
>>> I think we have to revert and go back to the drawing board on this.
>
>> Given that change was also sold on the basis of higher performance, I
>> suggest we retest performance to chec
Simon Riggs writes:
> On 11 October 2012 01:43, Tom Lane wrote:
>> I think we have to revert and go back to the drawing board on this.
> Given that change was also sold on the basis of higher performance, I
> suggest we retest performance to check there is a gain. If there is
> still a gain, I s
On 11 October 2012 01:43, Tom Lane wrote:
> I think we have to revert and go back to the drawing board on this.
Given that change was also sold on the basis of higher performance, I
suggest we retest performance to check there is a gain. If there is
still a gain, I suggest we add this as a SIGHU
On Wed, Oct 10, 2012 at 10:01:30PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Oct 10, 2012 at 09:29:16PM -0400, Tom Lane wrote:
> >> In what way would somebody be relying on the 9.2 behavior?
>
> > I don't know. I am just asking if an application could be relying on
> > the 9.2 b
Bruce Momjian writes:
> On Wed, Oct 10, 2012 at 09:29:16PM -0400, Tom Lane wrote:
>> In what way would somebody be relying on the 9.2 behavior?
> I don't know. I am just asking if an application could be relying on
> the 9.2 behavior.
I don't think so. Robert suggested in the original discussi
On Wed, Oct 10, 2012 at 09:29:16PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Oct 10, 2012 at 08:43:34PM -0400, Tom Lane wrote:
> >> I think we have to revert and go back to the drawing board on this.
>
> > Is reverting going to adversely affect users who are already using the
> >
Bruce Momjian writes:
> On Wed, Oct 10, 2012 at 08:43:34PM -0400, Tom Lane wrote:
>> I think we have to revert and go back to the drawing board on this.
> Is reverting going to adversely affect users who are already using the
> 9.2 behavior?
In what way would somebody be relying on the 9.2 behav
On Wed, Oct 10, 2012 at 08:43:34PM -0400, Tom Lane wrote:
> > It seems to me that the
> > root of the issue here is that people is not that people expect two
> > snapshots -- indeed, a number of people strongly supported getting rid
> > of that behavior at the time -- but rather that they expect th
Robert Haas writes:
> On Wed, Oct 10, 2012 at 7:10 PM, Tom Lane wrote:
>> Yeah, I think that last is the key point: this patch was sold on the
>> grounds that it wouldn't cause any interesting user-visible behavioral
>> change, but your example blows that claim into tiny little pieces.
>>
>> I'm
On Wed, Oct 10, 2012 at 7:10 PM, Tom Lane wrote:
> Yeah, I think that last is the key point: this patch was sold on the
> grounds that it wouldn't cause any interesting user-visible behavioral
> change, but your example blows that claim into tiny little pieces.
>
> I'm inclined to think we need to
Tomas Vondra writes:
> On 10.10.2012 22:43, Thom Brown wrote:
>> On 10 October 2012 21:21, Tomas Vondra wrote:
>>> A: BEGIN;
>>> A: LOCK x IN ACCESS EXCLUSIVE MODE;
>>> A: INSERT INTO x VALUES (100);
>>> B: SELECT * FROM x;
>>> A: COMMIT;
>>>
>>> Now on 9.1, B receives the value "100" while on 9
On 10.10.2012 23:57, Andres Freund wrote:
> On Wednesday, October 10, 2012 11:45:41 PM Tomas Vondra wrote:
>> Oh yeah, right. Any lock would work - advisory or not.
> Well, it needs to be a lock youre conflicting on, not any lock ;)
Oh, yeah, right. I was thinking about acquiring the same advisory
On Wednesday, October 10, 2012 11:45:41 PM Tomas Vondra wrote:
> On 10.10.2012 23:31, Andres Freund wrote:
> > On Wednesday, October 10, 2012 11:23:10 PM Tomas Vondra wrote:
> >> On 10.10.2012 23:05, Andres Freund wrote:
> >>> On Wednesday, October 10, 2012 10:43:57 PM Thom Brown wrote:
> On 1
On 10.10.2012 23:31, Andres Freund wrote:
> On Wednesday, October 10, 2012 11:23:10 PM Tomas Vondra wrote:
>> On 10.10.2012 23:05, Andres Freund wrote:
>>> On Wednesday, October 10, 2012 10:43:57 PM Thom Brown wrote:
On 10 October 2012 21:21, Tomas Vondra wrote:
> Hi,
>
> I've jus
On Wednesday, October 10, 2012 11:23:10 PM Tomas Vondra wrote:
> On 10.10.2012 23:05, Andres Freund wrote:
> > On Wednesday, October 10, 2012 10:43:57 PM Thom Brown wrote:
> >> On 10 October 2012 21:21, Tomas Vondra wrote:
> >>> Hi,
> >>>
> >>> I've just noticed a change of LOCK command behavior
On 10.10.2012 23:05, Andres Freund wrote:
> On Wednesday, October 10, 2012 10:43:57 PM Thom Brown wrote:
>> On 10 October 2012 21:21, Tomas Vondra wrote:
>>> Hi,
>>>
>>> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
>>> and I'm not sure whether this is expected or not.
>
On Wednesday, October 10, 2012 10:43:57 PM Thom Brown wrote:
> On 10 October 2012 21:21, Tomas Vondra wrote:
> > Hi,
> >
> > I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
> > and I'm not sure whether this is expected or not.
> >
> > Let's use a very simple table
> >
>
On 10.10.2012 22:43, Thom Brown wrote:
> On 10 October 2012 21:21, Tomas Vondra wrote:
>> Example:
>>
>> A: BEGIN;
>> A: LOCK x IN ACCESS EXCLUSIVE MODE;
>> A: INSERT INTO x VALUES (100);
>> B: SELECT * FROM x;
>> A: COMMIT;
>>
>> Now on 9.1, B receives the value "100" while on 9.2 it gets no rows
On 10.10.2012 22:42, Andres Freund wrote:
> On Wednesday, October 10, 2012 10:21:51 PM Tomas Vondra wrote:
>> Hi,
>>
>> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
>> and I'm not sure whether this is expected or not.
>>
>> Let's use a very simple table
>>
>> CREATE TA
On 10 October 2012 21:21, Tomas Vondra wrote:
> Hi,
>
> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
> and I'm not sure whether this is expected or not.
>
> Let's use a very simple table
>
> CREATE TABLE x (id INT);
>
> Say there are two sessions - A and B, where A pe
On Wednesday, October 10, 2012 10:21:51 PM Tomas Vondra wrote:
> Hi,
>
> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
> and I'm not sure whether this is expected or not.
>
> Let's use a very simple table
>
> CREATE TABLE x (id INT);
>
> Say there are two sessions -
On 10.10.2012 22:37, k...@rice.edu wrote:
> On Wed, Oct 10, 2012 at 10:21:51PM +0200, Tomas Vondra wrote:
>> Example:
>>
>> A: BEGIN;
>> A: LOCK x IN ACCESS EXCLUSIVE MODE;
>> A: INSERT INTO x VALUES (100);
>> B: SELECT * FROM x;
>> A: COMMIT;
>>
>> Now on 9.1, B receives the value "100" while on 9
On Wed, Oct 10, 2012 at 10:21:51PM +0200, Tomas Vondra wrote:
> Hi,
>
> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
> and I'm not sure whether this is expected or not.
>
> Let's use a very simple table
>
> CREATE TABLE x (id INT);
>
> Say there are two sessions -
Hi,
I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
and I'm not sure whether this is expected or not.
Let's use a very simple table
CREATE TABLE x (id INT);
Say there are two sessions - A and B, where A performs some operations
on "x" and needs to protect them with an
38 matches
Mail list logo
