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
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
te
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):
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
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
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 '
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 G
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
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
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
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 w
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
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/
--
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 S
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
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 broadcast)---
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
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
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 158
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
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
"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
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 (aft
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 inde
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
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 select/insert/upda
If the method needs a truly global LSN, then it is broken --- the only
way you could have such a value and have it stay good long enough to do
anything with it is to block all other backends from inserting any new
WAL records. Which is the very antithesis of concurrency.
Global LSN needs to reco
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Now I basically finished recovery for GiST (of course, it's need a hard
> testing)
> and go to concurrency. As it described in Kornaker, Mohan and Hellerstein's
> paper
> (http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/sigmod97-gist.pd
Now I basically finished recovery for GiST (of course, it's need a hard testing)
and go to concurrency. As it described in Kornaker, Mohan and Hellerstein's
paper
(http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/sigmod97-gist.pdf)
it's need a way to get global LSN, in our case -
Hi there,
I want to inform that we began to work on concurrency and recovery
support in GiST on our's own account and hope to be ready before 8.1
code freeze. There was some noise about possible sponsoring of our work,
but we didn't get any offering yet, so we're looking for sponsorhip !
We re
30 matches
Mail list logo
