Tom, agreed - it looks like we dug the hole and got ourselves into it.
But I still want to understand why.
It looks like we have rather small table on the host where I see the
slowness. And all other tables have triggers that will update one row
in that small table. The small table contains single
Looking at the system bit more now, it look like 'waiting' states are
changing for both the query and autovacuum in pg_stat_activity.
But very slowly. It looks like they both got into that sort of state
that keeps them on the edge of starvation.
So this isn't really a deadlock, but rather very poo
On 2 March 2012 11:03, Alvaro Herrera wrote:
>
> Excerpts from Gregg Jaskiewicz's message of vie mar 02 07:44:07 -0300 2012:
>> Folks,
>>
>> I got a system here (8.3.7), that is locked up. Few queries waiting
>> for autovacuum aquired locks on a table or two.
>> But it looks like autovacuum is als
Folks,
I got a system here (8.3.7), that is locked up. Few queries waiting
for autovacuum aquired locks on a table or two.
But it looks like autovacuum is also waiting for some semaphore:
#0 0x00f07410 in __kernel_vsyscall ()
#1 0x00252d2b in semop () from /lib/libc.so.6
#2 0x081ca1ce in PGSe
On 7 November 2011 12:14, Thom Brown wrote:
>
> I notice that there are no machines in the build farm which build HEAD
> and use float timestamps, so this could silently happen again unless
> the Grzegorz Jaskiewiczs out there continue to report build issues.
I am rebuilding head once a week-ish
On 7 November 2011 11:57, Heikki Linnakangas
wrote:
> Looks like the range types patch was broken for float timestamps. I'll go
> fix that. Thanks for the report!
yup, no probs.
--
GJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
http://pastebin.com/RjiRjGZc
this is on fedora 12, gcc 4.6.1
--
GJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
