On Wed, Jul 27, 2011 at 7:16 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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
alvhe...@commandprompt.com 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
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 'read
Alvaro Herrera alvhe...@commandprompt.com 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
Excerpts from Kevin Grittner's message of mar jul 19 13:49:53 -0400 2011:
Alvaro Herrera alvhe...@commandprompt.com 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
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
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 prevent this;
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
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 committed'.
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 makes
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 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
does the
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
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
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
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
On Mon, Feb 14, 2011 at 6:49 PM, Alvaro Herrera
alvhe...@commandprompt.com 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 n...@leadboat.com wrote:
The patch had a trivial conflict in planner.c, plus plenty of offsets.
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. I know
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 time.
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 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
On Fri, Feb 11, 2011 at 09:13, Noah Misch n...@leadboat.com 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
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 n...@leadboat.com 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
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):
/* MultiXacts
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, to
On Thu, Jan 13, 2011 at 23:58, Alvaro Herrera
alvhe...@commandprompt.com 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
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
On Sat, Jan 22, 2011 at 4:25 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
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,
On Fri, Jan 14, 2011 at 1:00 PM, David E. Wheeler da...@kineticode.com 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
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 solve
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 da...@kineticode.com
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
33 matches
Mail list logo
