On 02/10/2011 05:09 AM, Heikki Linnakangas wrote:
On 09.02.2011 17:58, Kevin Grittner wrote:
Dan Ports wrote:
I think for SerializableXidHash we should probably just initially
allocate it at its maximum size. Then it'll match the PredXact
list which is allocated in full upfront, and there's
On 09.02.2011 17:58, Kevin Grittner wrote:
Dan Ports wrote:
I think for SerializableXidHash we should probably just initially
allocate it at its maximum size. Then it'll match the PredXact
list which is allocated in full upfront, and there's no risk of
being able to allocate a transaction but
On Wed, Feb 9, 2011 at 2:51 PM, Markus Wanner wrote:
> On 02/09/2011 06:25 PM, Robert Haas wrote:
>> On Wed, Feb 9, 2011 at 10:38 AM, Markus Wanner wrote:
>>> Thread based, dynamically allocatable and resizeable shared memory, as
>>> most other projects and developers use, for example.
>
> I didn
On 02/09/2011 06:25 PM, Robert Haas wrote:
> On Wed, Feb 9, 2011 at 10:38 AM, Markus Wanner wrote:
>> Thread based, dynamically allocatable and resizeable shared memory, as
>> most other projects and developers use, for example.
I didn't mean to say we should switch to that model. It's just *the
On Wed, Feb 9, 2011 at 2:16 PM, A.M. wrote:
> On Feb 9, 2011, at 12:25 PM, Robert Haas wrote:
>> On Wed, Feb 9, 2011 at 10:38 AM, Markus Wanner wrote:
>>> On 02/09/2011 04:16 PM, David Fetter wrote:
On Tue, Feb 08, 2011 at 09:09:48PM -0500, Robert Haas wrote:
> Frankly, I think this is a
On Feb 9, 2011, at 12:25 PM, Robert Haas wrote:
> On Wed, Feb 9, 2011 at 10:38 AM, Markus Wanner wrote:
>> On 02/09/2011 04:16 PM, David Fetter wrote:
>>> On Tue, Feb 08, 2011 at 09:09:48PM -0500, Robert Haas wrote:
Frankly, I think this is an example of how our current shared memory
m
On Wed, Feb 9, 2011 at 10:38 AM, Markus Wanner wrote:
> On 02/09/2011 04:16 PM, David Fetter wrote:
>> On Tue, Feb 08, 2011 at 09:09:48PM -0500, Robert Haas wrote:
>>> Frankly, I think this is an example of how our current shared memory
>>> model is a piece of garbage.
>>
>> What other model(s) mi
Dan Ports wrote:
> I think for SerializableXidHash we should probably just initially
> allocate it at its maximum size. Then it'll match the PredXact
> list which is allocated in full upfront, and there's no risk of
> being able to allocate a transaction but not register its xid. In
> fact, I be
On 02/09/2011 04:16 PM, David Fetter wrote:
> On Tue, Feb 08, 2011 at 09:09:48PM -0500, Robert Haas wrote:
>> Frankly, I think this is an example of how our current shared memory
>> model is a piece of garbage.
>
> What other model(s) might work better?
Thread based, dynamically allocatable and r
Heikki Linnakangas wrote:
>> (2) The predicate lock and lock target initialization code was
>> initially copied and modified from the code for heavyweight
>> locks. The heavyweight lock code adds 10% to the calculated
>> maximum size. So I wound up doing that for
>> PredicateLockTargetHash an
On Tue, Feb 08, 2011 at 09:09:48PM -0500, Robert Haas wrote:
> If we don't allocate all the memory up front, does that allow memory
> to be dynamically shared between different hash tables in shared
> memory? I'm thinking not, but...
>
> Frankly, I think this is an example of how our current shar
On 09.02.2011 00:04, Kevin Grittner wrote:
(1) When HTABs are created, there is the max_size, which is what
the PredicateLockShmemSize function must use in its calculations,
and the init_size, which is what will initially be allocated (and
so, is probably what you see in the usage at the end of
On Tue, Feb 08, 2011 at 09:09:48PM -0500, Robert Haas wrote:
> No way to fail is a tall order.
Well, no way to fail due to running out of shared memory in
RegisterPredicateLock/RegisterPredicateLockingXid, but that doesn't
have quite the same ring to it...
> If we don't allocate all the memory up
On Tue, Feb 8, 2011 at 7:23 PM, Dan Ports wrote:
> On Tue, Feb 08, 2011 at 04:04:39PM -0600, Kevin Grittner wrote:
>> (2) The predicate lock and lock target initialization code was
>> initially copied and modified from the code for heavyweight locks.
>> The heavyweight lock code adds 10% to the c
On Tue, Feb 08, 2011 at 04:04:39PM -0600, Kevin Grittner wrote:
> (2) The predicate lock and lock target initialization code was
> initially copied and modified from the code for heavyweight locks.
> The heavyweight lock code adds 10% to the calculated maximum size.
> So I wound up doing that fo
Heikki Linnakangas wrote:
> LOG: shmemsize 3153112
> LOG: actual 2339864
>
> Which is a pretty big overestimate, percentage-wise. Taking
> RWConflictPool into account in PredicateLockShmemSize() fixes the
> underestimate, but makes the overestimate correspondingly larger.
> I've never compare
One other nit re. the predicate lock table size GUCs: the out-of-memory
case in RegisterPredicateLockingXid (predicate.c:1592 in my tree) gives
the hint to increase max_predicate_locks_per_transaction. I don't think
that's correct, since that GUC isn't used to size SerializableXidHash.
In fact, th
Heikki Linnakangas wrote:
> Taking RWConflictPool into account in PredicateLockShmemSize() fixes
the
> underestimate, but makes the overestimate correspondingly larger.
I've
> never compared the actual and estimated shmem sizes of other parts of
> the backend, so I'm not sure how large discre
On 08.02.2011 18:14, Kevin Grittner wrote:
I wrote:
The multiplier of 10 PredXactList structures per connection is
kind of arbitrary. It affects the point at which information is
pushed to the lossy summary, so any number from 2 up will work
correctly; it's a matter of performance and false po
On Tue, Feb 08, 2011 at 10:14:44AM -0600, Kevin Grittner wrote:
> I do have some concern that if this defaults to too low a number,
> those who try SSI without bumping it and restarting the postmaster
> will not like the performance under load very much. SSI performance
> would not be affected by
On 08.02.2011 17:50, Kevin Grittner wrote:
Attached is something which will work. Whether people prefer this
or a definition of UINT64_MAX in some header file (if it's missing)
doesn't matter much to me.
At any rate, if someone commits this one-liner, three critters
should go back to green.
T
I wrote:
> The multiplier of 10 PredXactList structures per connection is
> kind of arbitrary. It affects the point at which information is
> pushed to the lossy summary, so any number from 2 up will work
> correctly; it's a matter of performance and false positive rate.
> We might want to put
Dan Ports wrote:
> On Tue, Feb 08, 2011 at 11:25:34AM +0200, Heikki Linnakangas
wrote:
>> On 08.02.2011 10:43, Kevin Grittner wrote:
>>> I see that at least three BuildFarm critters don't have
>>> UINT64_MAX defined.
>>
>> I guess we'll have to just #define it ourselves. Or could we just
>> pick
On Tue, Feb 08, 2011 at 11:25:34AM +0200, Heikki Linnakangas wrote:
> On 08.02.2011 10:43, Kevin Grittner wrote:
> > I see that at least three BuildFarm critters don't have UINT64_MAX
> > defined.
>
> I guess we'll have to just #define it ourselves. Or could we just pick
> another magic value, do
> Heikki Linnakangas wrote:
> On 08.02.2011 10:43, Kevin Grittner wrote:
>
>> I see that at least three BuildFarm critters don't have UINT64_MAX
>> defined.
>
> I guess we'll have to just #define it ourselves. Or could we just
> pick another magic value, do we actually rely on
> InvalidSerCommi
Kevin Grittner wrote:
> Heikki Linnakangas wrote:
>
> > Ok, committed.
>
> I see that at least three BuildFarm critters don't have UINT64_MAX
> defined. Not sure why coypu is running out of connections.
Yes, I am seeing that failures here too on my BSD machine.
--
Bruce Momjian
On 08.02.2011 10:43, Kevin Grittner wrote:
Heikki Linnakangas wrote:
Ok, committed.
I see that at least three BuildFarm critters don't have UINT64_MAX
defined.
I guess we'll have to just #define it ourselves. Or could we just pick
another magic value, do we actually rely on InvalidSerComm
Heikki Linnakangas wrote:
> Ok, committed.
I see that at least three BuildFarm critters don't have UINT64_MAX
defined. Not sure why coypu is running out of connections.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
Heikki Linnakangas wrote:
> Ok, committed.
Thanks for that, and for all the suggestions along the way!
Thanks also to Joe Conway for the review and partial commit in the
first CF for this release; to Jeff Davis for the reviews, pointing
out areas which needed work; and to Anssi Kääriäinen fo
On Mon, Feb 7, 2011 at 5:23 PM, Magnus Hagander wrote:
> On Mon, Feb 7, 2011 at 23:14, Heikki Linnakangas
> wrote:
>> On 06.02.2011 20:30, Kevin Grittner wrote:
>>>
>>> "Kevin Grittner" wrote:
>>>
I'm working on it now, and hope to have it all settled down today.
>>>
>>> Done and pushed to
On Mon, Feb 7, 2011 at 23:14, Heikki Linnakangas
wrote:
> On 06.02.2011 20:30, Kevin Grittner wrote:
>>
>> "Kevin Grittner" wrote:
>>
>>> I'm working on it now, and hope to have it all settled down today.
>>
>> Done and pushed to the git repo. Branch serializable on:
>>
>> git://git.postgresql.o
On 06.02.2011 20:30, Kevin Grittner wrote:
"Kevin Grittner" wrote:
I'm working on it now, and hope to have it all settled down today.
Done and pushed to the git repo. Branch serializable on:
git://git.postgresql.org/git/users/kgrittn/postgres.git
Heikki: I'm back to not having any outstan
Kevin Grittner wrote:
> "Kevin Grittner" wrote:
>> Jeff Davis wrote:
>>
>>> What does PredicateLockTuple do that needs a share lock? Does a
>>> pin suffice?
>>
>> If one process is reading a tuple and another is writing it
>> (e.g., UPDATE or DELETE) the concern is that we need to be able
>> t
On 05.02.2011 21:43, Kevin Grittner wrote:
"Kevin Grittner" wrote:
So now that I'm sure we actually do need code there, I'll add it.
In working on this I noticed the apparent need to move two calls to
PredicateLockTuple a little bit to keep them inside the buffer lock.
Without at least a sha
"Kevin Grittner" wrote:
> Jeff Davis wrote:
>
>> What does PredicateLockTuple do that needs a share lock? Does a
>> pin suffice?
>
> If one process is reading a tuple and another is writing it (e.g.,
> UPDATE or DELETE) the concern is that we need to be able to
> guarantee that either the predi
Jeff Davis wrote:
> On Sat, 2011-02-05 at 14:43 -0600, Kevin Grittner wrote:
>> In working on this I noticed the apparent need to move two calls
>> to PredicateLockTuple a little bit to keep them inside the buffer
>> lock. Without at least a share lock on the buffer, it seems that
>> here is a
On Sat, 2011-02-05 at 14:43 -0600, Kevin Grittner wrote:
> "Kevin Grittner" wrote:
>
> > So now that I'm sure we actually do need code there, I'll add it.
>
> In working on this I noticed the apparent need to move two calls to
> PredicateLockTuple a little bit to keep them inside the buffer lo
"Kevin Grittner" wrote:
> I'm working on it now, and hope to have it all settled down today.
Done and pushed to the git repo. Branch serializable on:
git://git.postgresql.org/git/users/kgrittn/postgres.git
Heikki: I'm back to not having any outstanding work on the patch.
Does anyone wan
I wrote:
> First cut [of having predicate locks linked to later row versions
> for conflict detection purposes]
> It passes all the usual regression tests, the new isolation tests,
> and the example posted earlier in the thread of a test case which
> was allowing an anomaly. (That is to say, th
"Kevin Grittner" wrote:
> So now that I'm sure we actually do need code there, I'll add it.
Hmmm... First cut at this here:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=3ccedeb451ee74ee78ef70735782f3550b621eeb
It passes all the usual regression tests, the n
"Kevin Grittner" wrote:
> So now that I'm sure we actually do need code there, I'll add it.
In working on this I noticed the apparent need to move two calls to
PredicateLockTuple a little bit to keep them inside the buffer lock.
Without at least a share lock on the buffer, it seems that here
Heikki Linnakangas wrote:
> On 02.02.2011 19:36, Kevin Grittner wrote:
>
>> Then there's one still lurking outside the new predicate* files,
>> in heapam.c. It's about 475 lines into the heap_update function
>> (25 lines from the bottom). In reviewing where we needed to
>> acquire predicate lock
Heikki Linnakangas wrote:
> On 04.02.2011 14:30, Kevin Grittner wrote:
>> OK. So it looks like right now it will move to btvacuumpage(),
>> right before the call to RecordFreeIndexPage(), and we will need
>> to add it to one spot each in the GiST and GIN AMs, when we get
>> to those. Would you
On 04.02.2011 14:30, Kevin Grittner wrote:
Heikki Linnakangas wrote:
The assertion in RecordFreeIndexPage() is a reasonable sanity
check, but I'm inclined to move it to the caller instead: I don't
think the FSM should need to access predicate lock manager, even
for an assertion.
OK. So it lo
Heikki Linnakangas wrote:
> On 02.02.2011 19:36, Kevin Grittner wrote:
>> I really appreciate you putting this testing framework together.
>> This is clearly the right way to do it, although we also clearly
>> don't want this test in the check target at the root directory,
>> because of the run ti
On 02.02.2011 19:36, Kevin Grittner wrote:
I really appreciate you putting this testing framework together.
This is clearly the right way to do it, although we also clearly
don't want this test in the check target at the root directory,
because of the run time.
It would be nice to get some buil
Heikki Linnakangas wrote:
On 02.02.2011 19:36, Kevin Grittner wrote:
>> If that part is right, it shouldn't take me very long to finish
>> the specs and capture the expected results.
> Looks good.
First cut on the rest of it pushed. I'll want to go over it again to
confirm, but I think all
Heikki Linnakangas wrote:
> A comment would be in order to explain why we only print the
> primary message.
Done:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=ddeea22db06ed763b39f716b86db248008a3aa92
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hac
On 02.02.2011 19:36, Kevin Grittner wrote:
Heikki Linnakangas wrote:
Suppressing detail seems easiest. AFAICS all the variable parts are
in errdetail.
I pushed that with some work on the tests. If you could review the
changes to isolationtester.c to confirm that they look sane, I'd
apprecia
Heikki Linnakangas wrote:
> Suppressing detail seems easiest. AFAICS all the variable parts are
> in errdetail.
I pushed that with some work on the tests. If you could review the
changes to isolationtester.c to confirm that they look sane, I'd
appreciate it.
http://git.postgresql.org/gitweb
On 02.02.2011 17:52, Kevin Grittner wrote:
I found two problems with this, and I'm not sure how to handle
either. If we can figure out an approach, I'm happy to work on it.
(1) We don't have much in the way of detail yet. I put a different
detail message on each, so that there is more evidenc
Heikki Linnakangas wrote:
> I converted the next test, receipt-report, grab that from my git
> repository first. It produces over two hundred permutations, so
> it's going to be a bit tedious to check the output for that, but I
> think it's still acceptable so that we don't need more complicated
On 02.02.2011 16:27, Kevin Grittner wrote:
Heikki Linnakangas wrote:
It produces over two hundred permutations, so it's going to be a
bit tedious to check the output for that, but I think it's still
acceptable so that we don't need more complicated rules for what is
accepted. IOW, we can just p
Heikki Linnakangas wrote:
> I converted the next test, receipt-report, grab that from my git
> repository first.
Will do.
> It produces over two hundred permutations, so it's going to be a
> bit tedious to check the output for that, but I think it's still
> acceptable so that we don't need m
On 02.02.2011 16:11, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 02.02.2011 12:20, Heikki Linnakangas wrote:
The tests don't seem very complicated, and they don't seem to
depend much on the dtester features. How hard would it be to
rewrite the test engine in C or perl?
I'm thinking o
Heikki Linnakangas wrote:
> On 02.02.2011 12:20, Heikki Linnakangas wrote:
>> The tests don't seem very complicated, and they don't seem to
>> depend much on the dtester features. How hard would it be to
>> rewrite the test engine in C or perl?
>>
>> I'm thinking of defining each test in a simpl
Heikki,
On 02/02/2011 02:04 PM, Heikki Linnakangas wrote:
> TypeError: __init__() got an unexpected keyword argument 'showTimingInfo'
> make: *** [dcheck] Virhe 1
>
> At that point I had no idea what's wrong.
Hm.. looks like Kevin already uses the latest dtester code from git.
You can either do
On 02.02.2011 14:48, Markus Wanner wrote:
Heikki,
On 02/02/2011 11:20 AM, Heikki Linnakangas wrote:
I couldn't get it to run on my basic Debian system, clearly I'm
doing something wrong, but it will be even harder for people on more
exotic platforms.
On Debian you only need 'python-twisted' a
On 02.02.2011 12:20, Heikki Linnakangas wrote:
On 26.01.2011 13:36, Simon Riggs wrote:
I looked at the patch to begin a review and immediately saw "dtest".
There's no docs to explain what it is, but a few comments fill me in a
little more. Can we document that please? And/or explain why its an
e
Heikki,
On 02/02/2011 11:20 AM, Heikki Linnakangas wrote:
> I couldn't get it to run on my basic Debian system, clearly I'm
> doing something wrong, but it will be even harder for people on more
> exotic platforms.
On Debian you only need 'python-twisted' and the dtester sources [1],
IIRC. What
On 26.01.2011 13:36, Simon Riggs wrote:
I looked at the patch to begin a review and immediately saw "dtest".
There's no docs to explain what it is, but a few comments fill me in a
little more. Can we document that please? And/or explain why its an
essential part of this commit? Could we keep it o
Jeff Davis wrote:
> On Tue, 2011-02-01 at 11:01 -0600, Kevin Grittner wrote:
>> My compiler doesn't.
>
> Strange. Maybe it requires -O2?
That's not it; I see -O2 in my compiles.
At any rate, I think the default clause is the best place to quash
the warning because that leaves us with a warnin
On Tue, 2011-02-01 at 11:01 -0600, Kevin Grittner wrote:
> My compiler doesn't.
Strange. Maybe it requires -O2?
> Would it make sense to elog here, rather than
> Assert? I'm not clear on the rules for that.
elog looks fine there to me, assuming we have the default case. I'm not
100% clear on th
Jeff Davis wrote:
> One thing that confused me a little about the code is the default
> case at the end. The enum is exhaustive, so the default doesn't
> really make sense. The compiler warning you are silencing is the
> uninitialized variable xid (right?)
Right.
> Since you have the "Assert
On Mon, 2011-01-31 at 17:55 -0600, Kevin Grittner wrote:
> http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=6360b0d4ca88c09cf590a75409cd29831afff58b
>
> With confidence that it works, I looked it over some more and now
> like this a lot. It is definitely more readable
Jeff Davis wrote:
> On Mon, 2011-01-31 at 15:30 -0600, Kevin Grittner wrote:
>> I'll try to set this up and see if I can get it to pass the check
>> and dcheck make targets. Can we assume that the performance
>> impact would be too small to matter when we know for sure that
> hint bits have alrea
On Mon, 2011-01-31 at 15:30 -0600, Kevin Grittner wrote:
> I'll try to set this up and see if I can get it to pass the check
> and dcheck make targets. Can we assume that the performance impact
> would be too small to matter when we know for sure that hint bits
> have already been set?
I think th
Jeff Davis wrote:
> On Mon, 2011-01-31 at 14:38 -0600, Kevin Grittner wrote:
>> If I want to try the switch statement from your recent
>> post, what should I use as the OldestXmin value on the call to
>> HTSV?
>
> I believe RecentGlobalXmin should work.
>
> And I don't think the original switc
Jeff Davis wrote:
> Ok, great. When I read that before I thought that WAL might need
> to be sent for implicit RO transactions. I will read it more
> carefully again.
In looking back over recent posts to see what I might have missed or
misinterpreted, I now see your point. Either of these alt
On Mon, 2011-01-31 at 14:38 -0600, Kevin Grittner wrote:
> It is at least as likely that I'm missing something. If I'm
> following you, we're talking about these 24 lines of code, where
> "valid" is the what was just returned from
> HeapTupleSatisfiesVisibility:
Yes.
> (1) Do you see a case whe
I wrote:
> We follow this by a check for the top-level xid, and return if
> that's early enough to have overlapped our transaction.
s/early enough to have overlapped/early enough not to have
overlapped/
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
Jeff Davis wrote:
> On Mon, 2011-01-31 at 13:55 -0600, Kevin Grittner wrote:
>> What it cares about is whether some other particular top level
>> transaction wrote a tuple which we *would* read except that it is
>> not visible to us because that other top level transaction is
>> concurrent with
On Mon, 2011-01-31 at 13:55 -0600, Kevin Grittner wrote:
> Jeff Davis wrote:
>
> > I don't think this function really cares about the visibility with
> > respect to the current snapshot, right?
>
> What it cares about is whether some other particular top level
> transaction wrote a tuple which
Jeff Davis wrote:
> Really, I think this should be using HTSV to separate concerns
> better and improve readability. My first reaction was to try to
> find out what the function was doing that's special. If it is
> doing something special, and HTSV is not what you're really
> looking for, a comm
Jeff Davis wrote:
> I don't think this function really cares about the visibility with
> respect to the current snapshot, right?
What it cares about is whether some other particular top level
transaction wrote a tuple which we *would* read except that it is
not visible to us because that other
On Mon, 2011-01-31 at 13:32 -0600, Kevin Grittner wrote:
> Ah, now I see what you're talking about. Take a look at where that
> "valid" flag come from -- the CheckForSerializableConflictOut are
> all place right after calls to HeapTupleSatisfiesVisibility. The
> "valid" value is what HeapTupleSat
Jeff Davis wrote:
> On Mon, 2011-01-31 at 07:26 -0600, Kevin Grittner wrote:
>>> And why are you reading the infomask directly? Do the existing
>>> visibility functions not suffice?
>>
>> It's possible we re-invented some code somewhere, but I'm not
>> clear on what code from this patch might
On Mon, 2011-01-31 at 07:26 -0600, Kevin Grittner wrote:
> > And why are you reading the infomask directly? Do the existing
> > visibility functions not suffice?
>
> It's possible we re-invented some code somewhere, but I'm not clear
> on what code from this patch might use what existing function
Jeff Davis wrote:
> 1. In CheckForSerializableConflictIn(), I think the comment above
> may be out of date. It says:
> 2. Also in the comment above CheckForSerializableConflictIn(), I
> see:
> 3. The comment above CheckForSerializableConflictOut() seems to
> trail off, as though you may have
On Sun, Jan 30, 2011 at 04:01:56PM -0600, Kevin Grittner wrote:
> I'm wondering how this differs from what is discussed in Section 2.7
> ("Serialization Graph Testing") of Cahill's doctoral thesis. That
> discusses a technique for trying to avoid false positives by testing
> the full graph for cyc
1. In CheckForSerializableConflictIn(), I think the comment above may be
out of date. It says:
"A tuple insert is in conflict only if there is a predicate lock against
the entire relation."
That doesn't appear to be true if, for example, there's a predicate lock
on the index page that the tuple
> Dan Ports wrote:
> On Thu, Jan 27, 2011 at 09:18:23AM -0800, Jeff Davis wrote:
>
>> Is there a reason we can't check for a real cycle, which would let
>> T1 succeed?
>
> I talked today with someone who experimented with doing exactly
> that in MySQL as part of a research project (Perfectly Seria
On Thu, Jan 27, 2011 at 09:18:23AM -0800, Jeff Davis wrote:
> On Tue, 2011-01-25 at 05:57 -0500, Dan Ports wrote:
> > This summary is right on. I would add one additional detail or
> > clarification to the last point, which is that rather than checking for
> > a cycle, we're checking for a transact
On Tue, 2011-01-25 at 15:22 -0600, Kevin Grittner wrote:
> Jeff Davis wrote:
>
> > I think just annotating RWConflict.in/outLink and
> > PredTranList.available/activeList with the types of things they
> > hold would be a help.
> >
> > Also, you say something about RWConflict and "when the struc
"Kevin Grittner" wrote:
> Now, with serializable transactions, as you saw, T1 will be rolled
> back.
I should probably have mentioned, that if all the transactions were
SERIALIZABLE and the report of transactions from the batch was run
as SERIALIZABLE READ ONLY DEFERRABLE, the start of the rep
Jeff Davis wrote:
> To clarify, this means that it will get some false positives,
> right?
Yes. But the example you're about to get into isn't one of them.
> For instance:
>
> T1:
> get snapshot
>
> T2:
> get snapshot
> insert R1
> commit
>
> T1:
> read R1
> write R2
>
> T3:
On Tue, 2011-01-25 at 05:57 -0500, Dan Ports wrote:
> This summary is right on. I would add one additional detail or
> clarification to the last point, which is that rather than checking for
> a cycle, we're checking for a transaction with both "in" and "out"
> conflicts, which every cycle must con
I wrote:
> While the overall code coverage for PostgreSQL source code is:
>
> Overall coverage rate:
> lines..: 64.8% (130296 of 201140 lines)
> functions..: 72.0% (7997 of 11109 functions)
By the way, I discovered that the above is lower if you just run the
check target. The dcheck
On Wed, Jan 26, 2011 at 02:36:25PM -0600, Kevin Grittner wrote:
> Same benefit in terms of exercising more lines of code, but
> *without* exposing the uninitialized structure to other threads.
Won't this cause a deadlock because locks are being acquired out of
order?
Dan
--
Dan R. K. Ports
I wrote:
> You're right. How about this?:
That's even worse. I'm putting back to where you had it and taking
a break before I do anything else that dumb.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
Dan Ports wrote:
> Isn't this placement the same as the version we had before that
> didn't work?
You're right. How about this?:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=86b839291e2588e59875fb87d05432f8049575f6
Same benefit in terms of exercising more
On Wed, Jan 26, 2011 at 01:42:23PM -0600, Kevin Grittner wrote:
> Dan, do you still have access to that machine you were using for the
> DBT-2 runs? Could we get a coverage run with and without
> TEST_OLDSERXID defined?
Sure, I'll give it a shot (once I figure out how to enable coverage...)
Dan
On Wed, Jan 26, 2011 at 10:01:28AM -0600, Kevin Grittner wrote:
> In looking at it just now, I noticed that after trying it in a
> couple different places what was left in the repository was not the
> optimal version for code coverage. I've put this back to the
> version which did a better job, fo
"Kevin Grittner" wrote:
> Alvaro Herrera wrote:
>
>> BTW did you try "make coverage" and friends? See
>> http://www.postgresql.org/docs/9.0/static/regress-coverage.html
>> and
>> http://developer.postgresql.org/~petere/coverage/
>
> I had missed that; thanks for pointing it out!
>
> I'm d
Alvaro Herrera wrote:
> BTW did you try "make coverage" and friends? See
> http://www.postgresql.org/docs/9.0/static/regress-coverage.html
> and
> http://developer.postgresql.org/~petere/coverage/
I had missed that; thanks for pointing it out!
I'm doing a coverage build now, to see what cov
Excerpts from Kevin Grittner's message of mié ene 26 14:07:18 -0300 2011:
> Simon Riggs wrote:
> > Pounding for hours on 16 CPU box sounds good. What diagnostics or
> > instrumentation are included with the patch? How will we know
> > whether pounding for hours is actually touching all relevant p
On Wed, 2011-01-26 at 11:07 -0600, Kevin Grittner wrote:
> > When this runs in production, how will we know whether SSI is
> > stuck
>
> Stuck? I'm not sure what you mean by that. Other than LW locking
> (which I believe is always appropriately brief, with rules for order
> of acquisition whic
Kevin,
thanks for your heads-up.
On 01/26/2011 06:07 PM, Kevin Grittner wrote:
> Simon Riggs wrote:
>
>> I looked at the patch to begin a review and immediately saw
>> "dtest". There's no docs to explain what it is, but a few comments
>> fill me in a little more. Can we document that please? A
Simon Riggs wrote:
> I looked at the patch to begin a review and immediately saw
> "dtest". There's no docs to explain what it is, but a few comments
> fill me in a little more. Can we document that please? And/or
> explain why its an essential part of this commit? Could we keep it
> out of core
Simon Riggs wrote:
> On Wed, 2011-01-26 at 11:36 +, Simon Riggs wrote:
>
>> Pounding for hours on 16 CPU box sounds good. What diagnostics or
>> instrumentation are included with the patch? How will we know
>> whether pounding for hours is actually touching all relevant
>> parts of code? I've
1 - 100 of 114 matches
Mail list logo
