Excerpts from Robert Haas's message of mié ago 03 12:14:15 -0400 2011:
> On Wed, Jul 27, 2011 at 7:16 PM, Alvaro Herrera
> wrote:
> > One thing I have not addressed is Noah's idea about creating a new lock
> > mode, KEY UPDATE, that would let us solve the initial problem that this
> > patch set to
On Wed, Jul 27, 2011 at 7:16 PM, Alvaro Herrera
wrote:
> One thing I have not addressed is Noah's idea about creating a new lock
> mode, KEY UPDATE, that would let us solve the initial problem that this
> patch set to resolve in the first place. I am not clear on exactly how
> that is to be imple
Excerpts from Noah Misch's message of sáb jul 16 13:11:49 -0400 2011:
> In any event, I have attached a patch that fixes the problems I have described
> here. To ignore autovacuum, it only recognizes a wait when one of the
> backends under test holds a conflicting lock. (It occurs to me that per
Excerpts from Kevin Grittner's message of mar jul 19 13:49:53 -0400 2011:
> Alvaro Herrera wrote:
> > Excerpts from Kevin Grittner's message:
> >> Noah Misch wrote:
> >>
> >>> With this patch in its final form, I have completed 180+ suite
> >>> runs without a failure.
> >>
> >> The attached
Alvaro Herrera wrote:
> Excerpts from Kevin Grittner's message:
>> Noah Misch wrote:
>>
>>> With this patch in its final form, I have completed 180+ suite
>>> runs without a failure.
>>
>> The attached patch allows the tests to pass when
>> default_transaction_isolation is stricter than 're
Excerpts from Kevin Grittner's message of sáb jul 16 14:03:31 -0400 2011:
> Noah Misch wrote:
>
> > With this patch in its final form, I have completed 180+ suite runs
> > without a failure.
>
> The attached patch allows the tests to pass when
> default_transaction_isolation is stricter than
"Kevin Grittner" wrote:
> Noah Misch wrote:
>
>> With this patch in its final form, I have completed 180+ suite
>> runs without a failure.
>
> The attached patch allows the tests to pass when
> default_transaction_isolation is stricter than 'read committed'.
Without these two patches the
On Sat, Jul 16, 2011 at 01:03:31PM -0500, Kevin Grittner wrote:
> Noah Misch wrote:
>
> > With this patch in its final form, I have completed 180+ suite runs
> > without a failure.
>
> The attached patch allows the tests to pass when
> default_transaction_isolation is stricter than 'read com
Noah Misch wrote:
> With this patch in its final form, I have completed 180+ suite runs
> without a failure.
The attached patch allows the tests to pass when
default_transaction_isolation is stricter than 'read committed'.
This is a slight change from the previously posted version of the
fi
On Fri, Jul 15, 2011 at 07:01:26PM -0400, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of mié jul 13 01:34:10 -0400 2011:
>
> > coypu failed during the run of the test due to a different session being
> > chosen
> > as the deadlock victim. We can now vary deadlock_timeout to preven
Excerpts from Noah Misch's message of mié jul 13 01:34:10 -0400 2011:
> coypu failed during the run of the test due to a different session being
> chosen
> as the deadlock victim. We can now vary deadlock_timeout to prevent this; see
> attached fklocks-tests-deadlock_timeout.patch. This also ma
On Tue, Jul 12, 2011 at 05:59:01PM -0400, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of vie mar 11 12:51:14 -0300 2011:
> > On Fri, Feb 11, 2011 at 02:13:22AM -0500, Noah Misch wrote:
> > > Automated tests would go a long way toward building confidence that this
> > > patch
> > > d
Excerpts from Noah Misch's message of vie mar 11 12:51:14 -0300 2011:
> On Fri, Feb 11, 2011 at 02:13:22AM -0500, Noah Misch wrote:
> > Automated tests would go a long way toward building confidence that this
> > patch
> > does the right thing. Thanks to the SSI patch, we now have an in-tree test
On 2011-06-20 22:11, Noah Misch wrote:
On Sun, Jun 19, 2011 at 06:30:41PM +0200, Jesper Krogh wrote:
I hope this hasn't been forgotten. But I cant see it has been committed
or moved
into the commitfest process?
If you're asking about that main patch for $SUBJECT rather than those
isolationteste
On Sun, Jun 19, 2011 at 06:30:41PM +0200, Jesper Krogh wrote:
> I hope this hasn't been forgotten. But I cant see it has been committed
> or moved
> into the commitfest process?
If you're asking about that main patch for $SUBJECT rather than those
isolationtester changes specifically, I can't sp
I hope this hasn't been forgotten. But I cant see it has been committed
or moved
into the commitfest process?
Jesper
On 2011-03-11 16:51, Noah Misch wrote:
On Fri, Feb 11, 2011 at 02:13:22AM -0500, Noah Misch wrote:
Automated tests would go a long way toward building confidence that this pat
On Fri, Feb 11, 2011 at 02:13:22AM -0500, Noah Misch wrote:
> Automated tests would go a long way toward building confidence that this patch
> does the right thing. Thanks to the SSI patch, we now have an in-tree test
> framework for testing interleaved transactions. The only thing it needs to be
> How is such a determination made, exactly?
It's Feb 15th, and portions of the patch need a rework according to the
author. I'm with Robert on this one.
--
-- Josh Berkus
PostgreSQL Experts Inc.
Excerpts from Robert Haas's message of mar feb 15 18:15:38 -0300 2011:
> I am thinking that the statute of limitations has expired on this
> patch, and that we should mark it Returned with Feedback and continue
> working on it for 9.2. I know it's a valuable feature, but I think
> we're out of ti
On Feb 15, 2011, at 1:15 PM, Robert Haas wrote:
>> Yeah, that bug is fixed with the attached, though I am rethinking this
>> bit.
>
> I am thinking that the statute of limitations has expired on this
> patch, and that we should mark it Returned with Feedback and continue
> working on it for 9.2.
On Mon, Feb 14, 2011 at 6:49 PM, Alvaro Herrera
wrote:
> Excerpts from Marti Raudsepp's message of lun feb 14 19:39:25 -0300 2011:
>> On Fri, Feb 11, 2011 at 09:13, Noah Misch wrote:
>> > The patch had a trivial conflict in planner.c, plus plenty of offsets.
>> > I've
>> > attached the rebased
Excerpts from Marti Raudsepp's message of lun feb 14 19:39:25 -0300 2011:
> On Fri, Feb 11, 2011 at 09:13, Noah Misch wrote:
> > The patch had a trivial conflict in planner.c, plus plenty of offsets. I've
> > attached the rebased patch that I used for review. For anyone following
> > along,
> >
On Fri, Feb 11, 2011 at 09:13, Noah Misch wrote:
> The patch had a trivial conflict in planner.c, plus plenty of offsets. I've
> attached the rebased patch that I used for review. For anyone following
> along,
> all the interesting hunks touch heapam.c; the rest is largely mechanical. A
> "dif
Excerpts from Noah Misch's message of vie feb 11 04:13:22 -0300 2011:
> I observe visibility breakage with this test case:
>
> [ ... ]
>
> The problem seems to be that funny t_cid (2249). Tracing through heap_update,
> the new code is not setting t_cid during this test case.
So I can fix this p
On Fri, Feb 11, 2011 at 02:15:20PM -0300, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of vie feb 11 04:13:22 -0300 2011:
> > On Thu, Jan 13, 2011 at 06:58:09PM -0300, Alvaro Herrera wrote:
> > > 3. The original tuple needs to be marked with the Cmax of the locking
> > >command, t
Excerpts from Noah Misch's message of vie feb 11 04:13:22 -0300 2011:
Hello,
First, thanks for the very thorough review.
> On Thu, Jan 13, 2011 at 06:58:09PM -0300, Alvaro Herrera wrote:
> Incidentally, HeapTupleSatisfiesMVCC has some bits of code like this (not
> new):
>
> /* MultiXa
On Thu, Jan 13, 2011 at 23:58, Alvaro Herrera
wrote:
> It goes like this: instead of acquiring a shared lock on the involved
> tuple, we only acquire a "key lock", that is, something that prevents
> the tuple from going away entirely but not from updating fields that are
> not covered by any uniqu
On Sat, Jan 22, 2011 at 4:25 PM, Dimitri Fontaine
wrote:
> Hi,
>
> This is a first level of review for the patch. I finally didn't get as
> much time as I hoped I would, so couldn't get familiar with the locking
> internals and machinery… as a result, I can't much comment on the code.
>
> The pat
Hi,
This is a first level of review for the patch. I finally didn't get as
much time as I hoped I would, so couldn't get familiar with the locking
internals and machinery… as a result, I can't much comment on the code.
The patch applies cleanly (patch moves one hunk all by itself) and
compiles w
Excerpts from Robert Haas's message of vie ene 14 15:08:27 -0300 2011:
> On Fri, Jan 14, 2011 at 1:00 PM, David E. Wheeler
> wrote:
> > On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
> >
> >> Something else that might be of interest: the patch as presented here
> >> does NOT solve the deadloc
Excerpts from David E. Wheeler's message of vie ene 14 15:00:48 -0300 2011:
> On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
>
> > Something else that might be of interest: the patch as presented here
> > does NOT solve the deadlock problem originally presented by Joel
> > Jacobson. It does s
On Fri, Jan 14, 2011 at 1:00 PM, David E. Wheeler wrote:
> On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
>
>> Something else that might be of interest: the patch as presented here
>> does NOT solve the deadlock problem originally presented by Joel
>> Jacobson. It does solve the second, simpl
On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
> Something else that might be of interest: the patch as presented here
> does NOT solve the deadlock problem originally presented by Joel
> Jacobson. It does solve the second, simpler example I presented in my
> blog article referenced above, ho
33 matches
Mail list logo
