Fixed in 8.0, 7.4 and 7.3 branches.
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
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
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):
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
Teodor Sigaev [EMAIL PROTECTED] 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
http://archives.postgresql.org/pgsql-patches/2005-08/msg00304.php
Could you perhaps test this patch as well, while you already have a
setup for testing parallel vacuums under big loads ?
I didn't find any problem with your patch during testing with 1e8 statements...
--
Teodor Sigaev
On R, 2005-08-26 at 16:47 +0400, Teodor Sigaev wrote:
http://archives.postgresql.org/pgsql-patches/2005-08/msg00304.php
Could you perhaps test this patch as well, while you already have a
setup for testing parallel vacuums under big loads ?
I didn't find any problem with your patch
Finded problem in GiST isn't too simple to resolve. I'm working on it. The
problem is about update query...
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] 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
http://archives.postgresql.org/pgsql-patches/2005-08/msg00304.php
Could you perhaps test this patch as well, while you already have a
setup for testing parallel vacuums under big loads ?
Ok, I'll do it.
Or perhaps you can share the setup/scripts/data so that I could run your
test myself as
Teodor Sigaev [EMAIL PROTECTED] 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
Further I'm going to increase concurrency up to 12 parallel threads.
All is ok, test is passed with approximatly 40 millions statements
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
On K, 2005-08-24 at 15:52 +0400, Teodor Sigaev wrote:
Further I'm going to increase concurrency up to 12 parallel threads.
All is ok, test is passed with approximatly 40 millions statements
I have sent a patch to patches list enabling concurrent vacuums to
actually reclaim space while
On Sat, 20 Aug 2005, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
I've written some quick scripts. One just vacuums constantly (999 vacuums
to 1 vacuum full) while three other scripts three randomly insert
into, update and delete from 3 tables. There's a mix of small and large
I have committed changes that I believe fix this problem:
http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php
But it needs more testing. Would you update to CVS tip and see if you
still see the failure?
It seems, patch works correctly. My tests is passed with approximatly 1e8
In other words ... if you can test this ... HELP!!!
I'll run tests.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of
Awhile back, Teodor Sigaev [EMAIL PROTECTED] wrote:
And there is one more problem: it caused approximatly one time per 2-4
million
statements, I got traps:
TRAP: FailedAssertion(!((*curpage)-offsets_used == num_tuples), File:
vacuum.c, Line: 2766)
LOG: server process (PID 15847) was
On Sat, 20 Aug 2005, Tom Lane wrote:
I have committed changes that I believe fix this problem:
http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php
But it needs more testing. Would you update to CVS tip and see if you
still see the failure?
I've written some quick scripts.
Gavin Sherry [EMAIL PROTECTED] writes:
I've written some quick scripts. One just vacuums constantly (999 vacuums
to 1 vacuum full) while three other scripts three randomly insert
into, update and delete from 3 tables. There's a mix of small and large
transactions. The tables have a single int
Christopher Kings-Lynne wrote:
I think the whole GiST limitations page can be removed now...
http://developer.postgresql.org/docs/postgres/limitations.html
Done.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+
And there is one more problem: it caused approximatly one time per 2-4 million
statements, I got traps:
TRAP: FailedAssertion(!((*curpage)-offsets_used == num_tuples), File:
vacuum.c, Line: 2766)
LOG: server process (PID 15847) was terminated by signal 6
Odd. Will look at it later (after
Teodor Sigaev [EMAIL PROTECTED] writes
concur.pl - generator of SQL statements
retrieving it is forbidden ...
Regards,
Qingqing
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Sorry, fixed.
Qingqing Zhou wrote:
Teodor Sigaev [EMAIL PROTECTED] writes
concur.pl - generator of SQL statements
retrieving it is forbidden ...
Regards,
Qingqing
---(end of broadcast)---
TIP 7: don't forget to increase your free space
Have we list named something like 'test focusing for 8.1'? If it exists then
GiST concurrency and recovery testing should be added to it. Especially,
recovery after crash. Of course, now Oleg and me going to begin a large test
program.
While I'm running test with concurrent
Teodor Sigaev [EMAIL PROTECTED] writes:
While I'm running test with concurrent
select/insert/update/delete/vacuum/vacuum full I found, that sometimes
postgres crashes in index_beginscan_internal on FunctionCall3, because
structure 'procedure' becomes zeroed. As I understand, LockRelation
can
I think the whole GiST limitations page can be removed now...
http://developer.postgresql.org/docs/postgres/limitations.html
Chris
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an
26 matches
Mail list logo
