Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-18 at 13:26 -0500, Kevin Grittner wrote:
3. Limited shared memory space to hold information about
committed transactions that are still interesting.
It's a challenging problem, however, and the current solution is
less than ideal.
Jeff Davis pg...@j-davis.com wrote:
Also, it appears to be non-deterministic, to a degree at least,
so you may not observe the problem in the exact way that I do.
The SELECTs only look at the root and the predicate doesn't match.
So each SELECT sets an SIReadLock on block 0 and exits the
Jeff Davis pg...@j-davis.com wrote:
That looks like a reasonable state to me, but I'm not sure exactly
what the design calls for. I am guessing that the real problem is
in PreCommit_CheckForSerializationFailure(), where there are 6
conditions that must be met for an error to be thrown. T2
On Thu, 2010-10-21 at 10:29 -0500, Kevin Grittner wrote:
Basically, when we already have a pivot, but no transaction has yet
committed, we wait to see if TN commits first. If so, we have a
problem; if not, we don't. There's probably some room for improving
performance by cancelling T0 or T1
Jeff Davis pg...@j-davis.com wrote:
in this case we do clearly have a problem, because the result is
not equal to the serial execution of the transactions in either
order.
Yeah, you're right. I misread that example -- newbie with the
PERIOD type.
So the question is: at what point is the
Jeff Davis pg...@j-davis.com wrote:
When using locks in an unconventional way, it would be helpful to
describe the invalid schedules that you're preventing. Perhaps an
example if you think it would be reasonably simple? Also some
indication of how another process is intended to modify the
Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 19, 2010 at 6:28 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
One thing that would work, but I really don't think I like it, is
that a request for a snapshot for such a transaction would not
only block until it could get a clean
On Sun, 2010-10-17 at 22:53 -0700, Jeff Davis wrote:
2. I think there's a GiST bug (illustrating with PERIOD type):
create table foo(p period);
create index foo_idx on foo using gist (p);
insert into foo select period(
'2009-01-01'::timestamptz + g * '1 microsecond'::interval,
On Mon, 2010-10-18 at 22:12 -0500, Kevin Grittner wrote:
Hmmm... When Joe was looking at the patch he exposed an intermittent
problem with btree indexes which turned out to be related to improper
handling of the predicate locks during index page clean-up caused by a
vacuum. Easy to fix once
Jeff Davis pg...@j-davis.com wrote:
I briefly looked into this when I woke up this morning, and I
think I'm close. I can reproduce it every time, so I should be
able to fix this as soon as I can find some free time (tomorrow
night, probably).
OK, I'll focus on other areas.
I might also
On Tue, Oct 19, 2010 at 6:28 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
One thing that would work, but I really don't think I like it, is
that a request for a snapshot for such a transaction would not only
block until it could get a clean snapshot (no overlapping
serializable
First off, thanks for the review! I know that it's a lot of work,
and I do appreciate it.
Jeff Davis pg...@j-davis.com wrote:
* Trivial stuff:
I get a compiler warning:
indexfsm.c: In function *RecordFreeIndexPage*:
indexfsm.c:55: warning: implicit declaration of function
On Mon, 2010-10-18 at 13:26 -0500, Kevin Grittner wrote:
2. I think there's a GiST bug (illustrating with PERIOD type):
My assumptions for GiST were that:
(1) A search for a matching value could bail out at any level in the
tree; there is no requirement for the search to proceed to the
Jeff Davis wrote:
On Mon, 2010-10-18 at 13:26 -0500, Kevin Grittner wrote:
I assume here that you mean that you _did_ see the failure
(serialization error) and therefore did not see the problem?
Yeah.
Also, are you sure it was using the GiST index for the searches and
didn't just get
This is based on the Kevin's git repo at:
git://git.postgresql.org/git/users/kgrittn/postgres.git
SHA1: 729541fa5ea94d66e6f4b22fb65bfef92214cd6b
* Trivial stuff:
I get a compiler warning:
indexfsm.c: In function ‘RecordFreeIndexPage’:
indexfsm.c:55: warning: implicit declaration of
15 matches
Mail list logo
