Dan Boeriu wrote:
The second will not finish in 24h but the CPU stays at 100% and iostat
shows no IO other than the checkpoints.
> IF I cancel the second UPDATE (pg_cancel_backend) and restart it (new
> pgsql invocation) ASAP it goes through in 20 secs.
OK, that's interesting when combined wit
On Jul 28, 2009, at 9:47 AM, Tom Lane wrote:
"Ole Tange" writes:
(modulo NULLs which seem to always cause problems in NOT INs).
Because it can be rewritten, NOT IN should never be much slower
than the
rewritten solution, as PostgreSQL should simply rewrite NOT IN to the
above.
Let's se
On Jul 28, 2009, at 1:16 PM, "Dan Boeriu" wrote:
I am doing a reply-all - hope that's fine.
The pg_locks shows only locks held by that Postgresql process - I am
the only one on the box.
pg_stat_activity shows 2 things:
1) the update
2) vacuum on the updated table
Now, I tried to isolate th
Ole Tange wrote:
On Tue, Jul 28, 2009 at 3:47 PM, Tom Lane wrote:
"Ole Tange" writes:
(modulo NULLs which seem to always cause problems in NOT INs).
Because it can be rewritten, NOT IN should never be much slower than the
rewritten solution, as PostgreSQL should simply rewrite
The following bug has been logged online:
Bug reference: 4951
Logged by: Jim Michaels
Email address: jmich...@yahoo.com
PostgreSQL version: 8.4.0
Operating system: Win XP Pro Sp3
Description:installation dir wrong for libpq compilation
Details:
it is impossible to c
On Tue, Jul 28, 2009 at 3:47 PM, Tom Lane wrote:
> "Ole Tange" writes:
>> (modulo NULLs which seem to always cause problems in NOT INs).
>
>> Because it can be rewritten, NOT IN should never be much slower than the
>> rewritten solution, as PostgreSQL should simply rewrite NOT IN to the
>> above.
2009/7/28 Robert Haas :
> On Tue, Jul 28, 2009 at 1:19 PM, Jaime
> Casanova wrote:
>> On Tue, Jul 28, 2009 at 12:12 PM, Robert Haas wrote:
>
> patch attached
>
super, thanks
Pavel
>>>
>>> So is this Ready for Committer?
>>>
>>
>> i think so... but being me who added the l
I am doing a reply-all - hope that's fine.
The pg_locks shows only locks held by that Postgresql process - I am the only
one on the box.
pg_stat_activity shows 2 things:
1) the update
2) vacuum on the updated table
Now, I tried to isolate the problem even more and turned the auto vacuum OFF.
The
On Tue, Jul 28, 2009 at 1:19 PM, Jaime
Casanova wrote:
> On Tue, Jul 28, 2009 at 12:12 PM, Robert Haas wrote:
patch attached
>>> super, thanks
>>>
>>> Pavel
>>
>> So is this Ready for Committer?
>>
>
> i think so... but being me who added the last bit of code i didn't
> felt confiden
On Tue, Jul 28, 2009 at 12:12 PM, Robert Haas wrote:
>>>
>>> patch attached
>>>
>> super, thanks
>>
>> Pavel
>
> So is this Ready for Committer?
>
i think so... but being me who added the last bit of code i didn't
felt confident to mark it as such...
--
Atentamente,
Jaime Casanova
Soporte y capa
On Tue, Jul 21, 2009 at 2:13 AM, Pavel Stehule wrote:
> 2009/7/21 Jaime Casanova :
>> On Mon, Jul 20, 2009 at 11:34 AM, Jaime
>> Casanova wrote:
>>> On Mon, Jul 20, 2009 at 10:09 AM, Alvaro
Getting rid of the check on natts was "ungood" ... it needs to compare
the number of undropped
well, i knew how to fix it (probably the reindexing, that you mentioned;))
but i think this happens often in our database, so what informations would
you like to know?
i'm awaiting orders :)
fous
> Nope.
>
> If you just want to fix it, reindexing that index should do the trick.
>
> If you want
Hello,
this isn't bug, please, mail to pg_general mailing list.
It's not commendable technique call some external services from
trigger. It's much better to store data to some special table and then
periodically read this table and call external services from some
daemon application. But if you
"fous" writes:
> i'm getting this error while vacuuming the database.
> proxylog=# VACUUM ;
> ERROR: failed to re-find parent key in index "user_day" for deletion
> target
> page 1441795
> does anoyne know, where the problem is?
Nope.
If you just want to fix it, reindexing that index should d
"Ole Tange" writes:
> (modulo NULLs which seem to always cause problems in NOT INs).
> Because it can be rewritten, NOT IN should never be much slower than the
> rewritten solution, as PostgreSQL should simply rewrite NOT IN to the
> above.
Let's see, you understand that the rewrite violates the
The following bug has been logged online:
Bug reference: 4950
Logged by: Ramakanth
Email address: ramaka...@iblesoft.com
PostgreSQL version: Advanced 8.3 R2
Operating system: Windows xp
Description:Problem in Job scheduling in Advanced postgre sql
Details:
We could
hi I have installed pgsql in linux, can i run a linux script file (.sh) with in a trigger. if it is possible , pls send me the brief notes.also send me , in windows can i run the batch(.bat) file. Thanks & Regards NandaKumar.R OBSI Technologies Pvt Ltd.
The following bug has been logged online:
Bug reference: 4949
Logged by: Ole Tange
Email address: postgresql@tange.dk
PostgreSQL version: 8.3.7
Operating system: Debian GNU/Linux
Description:NOT IN is prohibitive slower than the rewrite for medium
to large sets
De
Description:ts_rewrite() causes segfault when query with more than
one node becomes empty
Fixed, thank you
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-bugs ma
On Tue, Jul 28, 2009 at 08:54, Jim Michaels wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4947
> Logged by: Jim Michaels
> Email address: jmich...@yahoo.com
> PostgreSQL version: 8.4.0
> Operating system: Win XP Pro Sp3
> Description: libpq PQnt
The following bug has been logged online:
Bug reference: 4948
Logged by: fous
Email address: honza...@gmail.com
PostgreSQL version: 8.4.0
Operating system: Linux (CentOS release 5.3)
Description:getting error while vacuuming the database
Details:
hi
i'm getting thi
21 matches
Mail list logo
