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
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
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 Tue, Jan 11, 2011 at 12:34:44PM -0600, Kevin Grittner wrote:
> Agreed; but I am starting to get concerned about whether this
> particular area can be completed by the start of the CF. I might
> run a few days over on 2PC support. Unless ... Dan? Could you look
> into this while I chase down t
On Sat, Jan 08, 2011 at 10:20:22PM -0600, Kevin Grittner wrote:
> One thing that would help a lot besides code review is performance
> testing. I did some months ago and I know Dan booked time on MIT
> benchmarking systems and got good numbers, but with the refactoring
> it would be good to redo t
On Tue, Dec 07, 2010 at 10:14:24AM -0600, Kevin Grittner wrote:
> > Essentially, instead of adding dependencies as you go along and
> > abort once you hit a conflict, SERIALIZABLE READ ONLY DEFERRED
> > transactions would assume the worst case from the start and thus
> > be able to bypass the more
On Oct 4, 2010, at 11:06, Greg Stark wrote:
> I guess by "lock-free in the uncontended case" they mean the buffer
> cache manager is lock-free unless you're actually contending on the
> same buffer?
That refers to being able to acquire non-conflicting row/table locks without
needing an exclusiv
On Mon, Oct 04, 2010 at 01:13:36PM -0400, Robert Haas wrote:
> I believe the "one of only 16 global mutexes" comment is referring to
> NUM_LOCK_PARTITIONS (there's also NUM_BUFFER_PARTITIONS, but that
> wouldn't be relevant for row and table-level locks).
Yes -- my understanding is that they hit t
I wasn't involved in this work but I do know a bit about it. Sadly, the
work on Postgres performance was cut down to under a page, complete
with the amazing offhand mention of "rewriting PostgreSQL's lock
manager". Here are a few more details...
The benchmarks in this paper are all about stressing
On Tue, May 25, 2010 at 08:35:44PM +0200, Florian Pflug wrote:
> Hm, so in fact SSI sometimes allows the database to be inconsistent, but only
> as long as nobody tries to observe it?
Yes. Note that even while it's in an inconsistent state, you can still
perform any query that doesn't observe the
On Tue, May 25, 2010 at 02:00:42PM +0200, Nicolas Barbier wrote:
> I don't understand the problem. According to me, in the context of
> SSI, a read-only slave can just map SERIALIZABLE to the technical
> implementation of REPEATABLE READ (i.e., the currently-existing
> "SERIALIZABLE"). The union of
On Mon, May 24, 2010 at 10:24:07AM -0500, Kevin Grittner wrote:
> Jan Wieck wrote:
>
> > In some systems (data warehousing, replication), the order of
> > commits is important, since that is the order in which changes
> > have become visible.
>
> This issue intersects with the serializable work
On Sun, May 23, 2010 at 04:21:58PM -0400, Jan Wieck wrote:
> In some systems (data warehousing, replication), the order of commits is
> important, since that is the order in which changes have become visible.
> This information could theoretically be extracted from the WAL, but
> scanning the entir
101 - 113 of 113 matches
Mail list logo
