On Wed, Apr 20, 2011 at 5:16 PM, Kevin Grittner
wrote:
> Heikki Linnakangas wrote:
>
>> The immediate fix is trivial:
>>
>> [patch changing one line of code]
>
> I have confirmed that without this patch the new regression tests I
> have proposed will fail, and with the patch they succeed. I have
Heikki Linnakangas wrote:
> The immediate fix is trivial:
>
> [patch changing one line of code]
I have confirmed that without this patch the new regression tests I
have proposed will fail, and with the patch they succeed. I have
also confirmed that the isolation test suite continues to succe
Tom Lane wrote:
> "Kevin Grittner" writes:
>> If I'm reading this correctly, it would appear that nobody has
>> updated anything to a TOASTed value in a build against HEAD in
>> testing *anything* in the last two and a half months. And the
>> regression tests don't include a single UPDATE to a T
Tom Lane wrote:
> Hmm, is there much regression coverage for TOAST inserts or
> deletes either?
I'll check.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"Kevin Grittner" writes:
> If I'm reading this correctly, it would appear that nobody has
> updated anything to a TOASTed value in a build against HEAD in
> testing *anything* in the last two and a half months. And the
> regression tests don't include a single UPDATE to a TOASTed value
> anywhere
Tom Lane wrote:
> Egad. If that's it, my confidence in the amount of testing SSI
> has gotten has just dropped dramatically.
If I'm reading this correctly, it would appear that nobody has
updated anything to a TOASTed value in a build against HEAD in
testing *anything* in the last two and a h
Heikki Linnakangas wrote:
> But the question Tom raised about doing this even for
> non-serializable transactions is more serious..
This particular call from heapam.c went in much later than most of
the code, since we had trouble proving that anything needed to be
done there in the first place
Heikki Linnakangas wrote:
> On 20.04.2011 17:26, Tom Lane wrote:
>> Why is predicate.c getting called at all when
>> transaction_isolation is not SERIALIZABLE? (Although the same
>> crash happens when it is ...)
>
> Because another serializable transaction that reads/updates the
> tuple later
Heikki Linnakangas writes:
> The immediate fix is trivial:
> --- a/src/backend/access/heap/heapam.c
> +++ b/src/backend/access/heap/heapam.c
> @@ -2859,7 +2859,7 @@ l2:
> * Any existing SIREAD locks on the old tuple must be linked to
> the new
> * tuple for conflict detection
On 20.04.2011 18:08, Kevin Grittner wrote:
"Marko Tiikkaja" wrote:
TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) !=
((void *)0))&& ((&(newTuple->t_self))->ip_posid != 0", File:
"predicate.c", Line: 2282)
Am investigating, and have alerted Dan, in case he hasn't noticed
Heikki Linnakangas writes:
> There's *three* transactions here. The first one is serializable, and
> reads the tuple. The second one is not serializable, and updates it. The
> third one is serializable and updates it again.
> The second transaction needs to copy the predicate lock held by the
"Marko Tiikkaja" wrote:
> TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) !=
> ((void *)0)) && ((&(newTuple->t_self))->ip_posid != 0", File:
> "predicate.c", Line: 2282)
Am investigating, and have alerted Dan, in case he hasn't noticed
this thread.
-Kevin
--
Sent via pg
On 20.04.2011 17:51, Tom Lane wrote:
... which means that the first transaction is completed and
can no longer be holding any locks.
Predicate locks are held after transaction commit. They can only be
cleaned once the xid is older than the oldest xmin among all active
serializable transaction
On 20.04.2011 17:51, Tom Lane wrote:
Heikki Linnakangas writes:
On 20.04.2011 17:26, Tom Lane wrote:
Why is predicate.c getting called at all when transaction_isolation is
not SERIALIZABLE? (Although the same crash happens when it is ...)
Because another serializable transaction that reads
Heikki Linnakangas writes:
> On 20.04.2011 17:26, Tom Lane wrote:
>> Why is predicate.c getting called at all when transaction_isolation is
>> not SERIALIZABLE? (Although the same crash happens when it is ...)
> Because another serializable transaction that reads/updates the tuple
> later needs
On 20.04.2011 17:26, Tom Lane wrote:
"Marko Tiikkaja" writes:
=# create table foo(a int[]);
CREATE TABLE
=# insert into foo select array(select i from generate_series(1,1) i);
INSERT 0 1
=# update foo set a = a||1;
TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) !=
"Marko Tiikkaja" writes:
> =# create table foo(a int[]);
> CREATE TABLE
> =# insert into foo select array(select i from generate_series(1,1) i);
> INSERT 0 1
> =# update foo set a = a||1;
> TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) != ((void
> *)0)) && ((&(newTuple->t_
17 matches
Mail list logo
