Gregg Jaskiewicz wrote:
> Also, on the subject of prepared transactions (2PC), the "select *
> from pg_prepared_xacts ;" query simply does not reveal anything,
> despite the fact that I know that there should be at least two of
> those open.
> Unless it only list saved transactions, not a transa
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
On 2 Mar 2012, at 15:28, Robert Haas wrote:
> On Fri, Mar 2, 2012 at 6:22 AM, Gregg Jaskiewicz wrote:
>> 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 t
Tom Lane wrote:
> So the real problem is slow removal of prepared transactions,
> which most likely is an application logic problem. It's certainly
> not autovac's fault.
Yeah, I've seen way too much Java code lately which fails to close
ResultSet or Statement (which includes PreparedStatemen
Alvaro Herrera writes:
> Right. I think I can explain how this locking works: autovacuum needs a
> "cleanup" lock on the page being processed, which is a special exclusive
> lock which also requires that no one is holding a "pin" on the buffer.
> Any process running a query holds a pin on the buf
On Fri, Mar 2, 2012 at 6:22 AM, Gregg Jaskiewicz wrote:
> 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
Excerpts from Gregg Jaskiewicz's message of vie mar 02 08:22:22 -0300 2012:
>
> 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 kee
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
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 also waiting for some semaphore:
>
>
> #0 0x00f07410
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
11 matches
Mail list logo
