Fixed in 8.0, 7.4 and 7.3 branches.

Tom Lane wrote:
> Teodor Sigaev <teodor@sigaev.ru> writes:
>
>>http://www.sigaev.ru/gist/concur.pl
>>http://www.sigaev.ru/gist/concur.sh
>
>
> BTW, these scripts seem to indicate that there's a GIST or
> contrib/intarray problem in the 8.0 branch. I was trying to use 'em
> to test REL8_0_STABLE branch tip to verify my t_ctid chain backpatch,
> and I pretty consistently see "Problem with update":
>
> Start: parallel mode with 4 flows
> Problem with update {77,77}:0 count:1 at concur.pl line 91.
> Issuing rollback() for database handle being DESTROY'd without explicit disconnect().
> Problem with update {43,24}:3 count:1 at concur.pl line 91.
> Issuing rollback() for database handle being DESTROY'd without explicit disconnect().
> Problem with update {43,43}:2 count:1 at concur.pl line 91.
> Issuing rollback() for database handle being DESTROY'd without explicit disconnect().
> 1 flow finish. Stats: ni:75000 nu:1661 nd:216 nv:13(nf:3) nt:780
> All flow finish; status: 255; elapsed time: 265.48 sec
>
> Is this something that can be fixed for 8.0.4?
>
> regards, tom lane

--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Am Dienstag, 30. August 2005 11:25 schrieb Teodor Sigaev:
> Fixed in 8.0, 7.4 and 7.3 branches.
>
> Tom Lane wrote:
> > Teodor Sigaev <teodor@sigaev.ru> writes:
> >>http://www.sigaev.ru/gist/concur.pl
> >>http://www.sigaev.ru/gist/concur.sh
> >
> > BTW, these scripts seem to indicate that there's a GIST or
> > contrib/intarray problem in the 8.0 branch. I was trying to use 'em
> > to test REL8_0_STABLE branch tip to verify my t_ctid chain backpatch,
> > and I pretty consistently see "Problem with update":
> >
> > Start: parallel mode with 4 flows
> > Problem with update {77,77}:0 count:1 at concur.pl line 91.
> > Issuing rollback() for database handle being DESTROY'd without explicit
> > disconnect(). Problem with update {43,24}:3 count:1 at concur.pl line 91.
> > Issuing rollback() for database handle being DESTROY'd without explicit
> > disconnect(). Problem with update {43,43}:2 count:1 at concur.pl line 91.
> > Issuing rollback() for database handle being DESTROY'd without explicit
> > disconnect(). 1 flow finish. Stats: ni:75000 nu:1661 nd:216 nv:13(nf:3)
> > nt:780 All flow finish; status: 255; elapsed time: 265.48 sec
> >
> > Is this something that can be fixed for 8.0.4?
> >
> > regards, tom lane

Since 7.4 we have troubles with ltree (seldom corruption of buffer cache, not
on-disk), might this bug be somehow related to the ltree problem?
7.2 was rock-stable with ltree.

Best regards,
Mario Weilguni

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

> Since 7.4 we have troubles with ltree (seldom corruption of buffer cache, not
> on-disk), might this bug be somehow related to the ltree problem?
> 7.2 was rock-stable with ltree.

Not sure. Fixed bug was (@ - contains operation):

update wow set a = a || '{101}'::int[] where a @ '{1,2,3}';
select a from wow where a @ '{1,2,3}' and not a @ '{101}';

After update query select must not find any rows, but it did. The problem was in
GiST code and so any GiST idexes was affected.

Can you say more about your trouble?


--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Am Dienstag, 30. August 2005 12:19 schrieb Teodor Sigaev:
> > Since 7.4 we have troubles with ltree (seldom corruption of buffer cache,
> > not on-disk), might this bug be somehow related to the ltree problem? 7.2
> > was rock-stable with ltree.
>
> Not sure. Fixed bug was (@ - contains operation):
>
> update wow set a = a || '{101}'::int[] where a @ '{1,2,3}';
> select a from wow where a @ '{1,2,3}' and not a @ '{101}';
>
> After update query select must not find any rows, but it did. The problem
> was in GiST code and so any GiST idexes was affected.
>
> Can you say more about your trouble?

We have queries that use ltree for sorting too, the sort looks like this:
order by subpath(ltreefield, 0, nlevel(ltreefield) - 1)

But concurrency leads to a bug, that results in an sql-error:
ERROR: invalid positions

Now we use locking to prevent concurrenct access on the most-used concurrent
part of the program, and the problem is extremly rare now, I had only 4
occurences in one year, but still happens (there are other access paths that
do not use locking, but they are rareley accessed).

It seems the ltree length parameter is set to 0 in the tuples, the content
itself is still there: Example:
Say the tuple was before treefield='1.2.3.4.5'
After the occurence of the error, I get: treefield='' (empty, but not null)

Using a tool Tom Lane told me to use, I checked it, and on-disk I had still
"1.2.3.4.5", but the length parameter of the ltree column was 0 (sorry, I was
wrong in my first mail, on-disk was broken too.)

Might this be somehow related to the intarray bugs?

Best regards,
Mario Weilguni


p.s.: I tried hard to create a self-contained test for tracking this down, but
failed.


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

> We have queries that use ltree for sorting too, the sort looks like this:
> order by subpath(ltreefield, 0, nlevel(ltreefield) - 1)
>
> But concurrency leads to a bug, that results in an sql-error:
> ERROR: invalid positions

contrib_regression=# select nlevel(t), subpath(t, 0, nlevel(t)-1) from
text2ltree('1.2.3.4.5') as t;
nlevel | subpath
--------+---------
5 | 1.2.3.4
(1 row)

contrib_regression=# select nlevel(t), subpath(t, 0, nlevel(t)-1) from
text2ltree('1') as t;
nlevel | subpath
--------+---------
1 |
(1 row)

contrib_regression=# select nlevel(t), subpath(t, 0, nlevel(t)-1) from
text2ltree('') as t;
ERROR: invalid positions
contrib_regression=#

It's incorrect arguments for subpath().

>
> It seems the ltree length parameter is set to 0 in the tuples, the content
> itself is still there: Example:
> Say the tuple was before treefield='1.2.3.4.5'
> After the occurence of the error, I get: treefield='' (empty, but not null)
>
> Using a tool Tom Lane told me to use, I checked it, and on-disk I had still
> "1.2.3.4.5", but the length parameter of the ltree column was 0 (sorry, I was
> wrong in my first mail, on-disk was broken too.)

Interesting... But with some test suite or more information I'm helpless.
How often do updates/inserts of table and/or ltree column occurs? Vacuum?


>
> Might this be somehow related to the intarray bugs?

No, except case when you update your table something like to:
update tbl set ltreefield=... where ltreefield ...;

--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Teodor Sigaev <teodor@sigaev.ru> writes:
>> Is this something that can be fixed for 8.0.4?

> Fixed in 8.0, 7.4 and 7.3 branches.

Excellent news. Thanks.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org