"Kevin Grittner" wrote:
> If my back-of-the-envelope math is right, a carefully constructed
> pessimal load could need up to (max_connections / 2)^2 -- so 100
> connections could conceivably require 2500 structures, although
> such a scenario would be hard to create. Current "picked from
> thin
On Tue, Jan 18, 2011 at 3:18 PM, Kevin Grittner
wrote:
> That's all of them.
Our existing code has plenty of TODOs in it already, so I see no
problem with continuing to comment places where future enhancements
are possible, as long as they don't reflect deficiencies that are
crippling in the pres
Heikki Linnakangas wrote:
> There's a few remaining TODO comments in the code, which obviously
> need to be resolved one way or another
Not all of these are "must haves" for 9.1. Here's how they break
down:
The two in predicate_internals.h mark places which would need to be
touched if we fu
"Kevin Grittner" writes:
>> Dan Ports wrote:
> The biggest, in my mind, is whether
> MySerializableXact needs to be declared volatile.
> The problem is that I don't have a very clear sense of what it really
> does, which is not helped much by having done a few years of Java
> programming,
> Dan Ports wrote:
> On Mon, Jan 17, 2011 at 07:20:20PM -0600, Kevin Grittner wrote:
>> OK. I may need to bounce some questions off the list to resolve
>> some of them. The biggest, in my mind, is whether
>> MySerializableXact needs to be declared volatile. I don't have my
>> head around the issue
On Mon, Jan 17, 2011 at 07:20:20PM -0600, Kevin Grittner wrote:
> OK. I may need to bounce some questions off the list to resolve some
> of them. The biggest, in my mind, is whether MySerializableXact
> needs to be declared volatile. I don't have my head around the
> issues on that as well as I
> Heikki Linnakangas wrote:
> Setting the high bit in OldSetXidAdd() seems a bit weird. How about
> just using UINT64_MAX instead of 0 to mean no conflicts? Or 1, and
> start the sequence counter from 2.
Sure. I think I like reserving 1 and starting at 2 better. Will do.
> ReleasePredicate
On Mon, Jan 17, 2011 at 06:52:09PM -0600, Kevin Grittner wrote:
> I think we still need the vxid. It shows in the pg_locks view, and
> we might possibly need it to find the right process to cancel once we
> have some way to do that. But there's no point with having the tag
> level anymore.
Oh, r
> Dan Ports wrote:
> Yes, that comment was supposed to be attached to
> possibleUnsafeConflicts.
> Actually, I think that "other" hash no longer exists
> The comment above SERIALIZABLEXACT also needs to be updated since
> it refers to said hash table. And if I'm not mistaken (Kevin?), we
> c
On Mon, Jan 17, 2011 at 09:58:44PM +0200, Heikki Linnakangas wrote:
> What does that comment about list of concurrent r/w transactions refer
> to? I don't see any list there. Does it refer to
> possibleUnsafeConflicts, which is above that comment?
Yes, that comment was supposed to be attached to
On 15.01.2011 01:54, Kevin Grittner wrote:
/*
* for r/o transactions: list of concurrent r/w transactions that we
could
* potentially have conflicts with, and vice versa for r/w transactions
*/
TransactionId topXid; /* top level xid for the tr
Anssi Kääriäinen wrote:
> I tried to break the version 11 of the patch (some of the work was
> against earlier versions). In total I have used a full work day
> just trying to break things, but haven't been able to find anything
> after version 8. I can verify that the partial index issue is
> fi
On Mon, Jan 17, 2011 at 09:58:35AM +0200, Anssi Kääriäinen wrote:
> One thing I have been thinking about is how does predicate locking
> indexes work when using functional indexes and functions marked as
> immutable but which really aren't. I don't know how predicate
> locking indexes works, so it
While I haven't tried this patch, I tried to break the version 11 of the
patch (some of the work was against earlier versions). In total I have
used a full work day just trying to break things, but haven't been able
to find anything after version 8. I can verify that the partial index
issue is
14 matches
Mail list logo
