Re: "multiple backends attempting to wait for pincount 1"
От | Kevin Grittner |
---|---|
Тема | Re: "multiple backends attempting to wait for pincount 1" |
Дата | |
Msg-id | 976857746.2797816.1423866815909.JavaMail.yahoo@mail.yahoo.com обсуждение исходный текст |
Ответ на | Re: "multiple backends attempting to wait for pincount 1" (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: "multiple backends attempting to wait for pincount 1"
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> wrote: > On 2015-02-13 00:27:04 -0500, Tom Lane wrote: >> I'd say we have a problem. I'd even go so far as to say that >> somebody has completely broken locking, because this looks like >> autovacuum and manual vacuuming are hitting the same table at >> the same time. > One avenue to look are my changes around both buffer pinning and > interrupt handling... I found a way to cause this reliably on my machine and did a bisect. That pointed to commit 6753333f55e1d9bcb9da4323556b456583624a07 For the record, I would build and start the cluster, start two psql sessions, and paste this into the first session: drop table if exists m; create table m (id int primary key); insert into m select generate_series(1, 1000000) x; checkpoint; vacuum analyze; checkpoint; delete from m where id between 50 and 100; begin; declare c cursor for select * from m; fetch c; fetch c; fetch c; As soon as I saw the fetches execute I hit Enter on this in the other psql session: vacuum freeze m; It would block, and then within a minute (i.e., autovacuum_naptime) I would get the error. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: