Tom Lane wrote: > Alvaro Herrera <alvhe...@commandprompt.com> writes: > > While looking at this code I notice something that troubles me. Just > > after extending the relation, we don't insert the new page into the FSM. > > So if the extending backend does not do any other insertion on the page, > > it is forgotten as possible insert target until the next vacuum. > > That is intentional so as not to have write contention on that page. > We would rather have several backends concurrently inserting into > different pages. Unless you've got a lot of very short-lived backends > doing one insertion apiece, it seems like the right tradeoff to me.
Yes, I notice it's intentional. I can't really say if this works as intended in this case. For example I think it is possible that rd_targblock is reset when there's a relcache flush. Hmm ... this is something that had not occured to me earlier. There is a connection pool here (JDBCConnectionPool I'm told; hadn't heard about that one) and there are about 100 backends permanently, not all of which are always busy. Perhaps what's going on here is that some of them are idle for long enough that the sinval queue gets full. > > I regularly (several times a day) see five or six processes all with > > pg_locks locktype=extend granted=f on the same table, waiting for a long > > time. > > I'm not sure what's causing that, but I *seriously* doubt that adding > new pages to FSM right away would make it better. What it sounds like > is someone is getting hung up while holding the lock. Yeah, I tried to see what was this about; I was fooled by the bit where we fsync the segment, but AFAICS this should not happen on a regular backend. One point of interest is that PGDATA lies on a SAN, so perhaps it's just the protocol being inefficient there. > You should try to investigate who's got the lock when this happens, > and what they're doing or waiting for. I've been trying to research this but I can't say the tools are great. We'll keep at it. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
