> Seems like you'd also need to think about priority inversion, if the
> "low-priority" backend is holding any locks.
>
I'm not sure that priority inversion would be right in this scenario,
because in that case the IO storm would still be able to exist, in the cases
where the slow jobs collide wit
IZED
transaction picks up, I would be more than glad to help implement it or to
help in any other way I can.
Best regards,
Eduardo.
On Fri, Jan 15, 2010 at 7:32 PM, Greg Smith wrote:
> Eduardo Piombino wrote:
>
>> Going to the disk properties (in windows), I just realized it d
2010 at 5:49 PM, Eduardo Piombino wrote:
> Regarding the hardware the system is running on:
>
> It's an HP Proliant DL-180 G5 server.
>
> Here are the specs... our actual configuration only has one CPU, and 16G of
> RAM.
> The model of the 2 disks I will post later toda
original, since I recall hearing something
about that our disks were SAS (Serial Attached SCSI), and I don't know if it
is possible to connect those disks to embedded Smart Array E200 controller.
Would it be possible?
On Wed, Jan 13, 2010 at 4:13 PM, Eduardo Piombino wrote:
> Greg, I will p
Greg, I will post more detailed data as soon as I'm able to gather it.
I was trying out if the cancellation of the ALTER cmd worked ok, I might
give the ALTER another try, and see how much CPU, RAM and IO usage gets
involved. I will be doing this monitoring with the process explorer from
sysintern
> OK, I'm not entirely sure this table is not still locking something
> else. If you make a copy by doing something like:
>
> select * into test_table from a;
>
> and then alter test_table do you still get the same problems? If so,
> then it is an IO issue, most likely. If not, then there is som
ira de Oliveira <
eu...@timbira.com> wrote:
> Eduardo Piombino escreveu:
> > Maybe it does not get logged at all until the ALTER is completed?
> >
> This feature [1] was implemented a few months ago and it will be available
> only in the next PostgreSQL version (8.5).
&g
left untouched until this copy of
the table gets updated ... Just guessing here.
On Wed, Jan 13, 2010 at 4:39 AM, Greg Smith wrote:
> Eduardo Piombino wrote:
>
>> Postgres version: 8.2.4, with all defaults, except DateStyle and TimeZone.
>>
>
> Ugh...there are several f
as always, every advice for small it may seem, will be very
much appreciated.
Nonetheless, thanks a lot for all the light you already brought me on this
matter.
I really appreciate it.
Eduardo.
On Wed, Jan 13, 2010 at 3:02 AM, Craig Ringer
wrote:
> On 13/01/2010 1:47 PM, Eduardo Piombino w
if my ALTER TABLE takes 4 days instead of 4 hours.*
>
> * Something like:*
> * pg_set_max_cpu _or_io_usage(2/100);*
>
On Wed, Jan 13, 2010 at 2:14 AM, Craig James wrote:
> Eduardo Piombino wrote:
>
>> Hi list, I'm having a problem when dealing with operations that asks
Hi list, I'm having a problem when dealing with operations that asks too
much CPU from the server.
The scenario is this:
I have a multithreaded server, each thread with its own connection to the
database. Everything is working fine, actually great, actually
outstandingly, in normal operation.
I'v
11 matches
Mail list logo
