On 2014-01-22 01:18:36 +0100, Simon Riggs wrote: > > My understanding is that if it runs out of buffer space while in an > > XLogInsert, it will be holding one or more buffer content locks exclusively, > > and unless it can complete the xlog (or scrounge up the info to return that > > buffer to its previous state), it can never release that lock. There might > > be other paths were it could get by with an ERROR, but if no one can write > > xlog anymore, all of those paths must quickly converge to the one that > > cannot simply ERROR. > > Agreed. You don't say it but I presume you intend to point out that > such long-lived contention could easily have a knock on effect to > other read-only statements. I'm pretty sure other databases work the > same way. > > Our choice are > > 1. Waiting > 2. Abort transactions > 3. Some kind of release-locks-then-wait-and-retry > > (3) is a step too far for me, even though it is easier than you say > since we write WAL before changing the data block so a failure to > insert WAL could just result in a temporary drop lock, sleep and > retry. > > I would go for (1) waiting for up to checkpoint_timeout then (2), if > we think that is a problem.
How are we supposed to wait while e.g. ProcArrayLock? Aborting transactions doesn't work either, that writes abort records which can get signficantly large. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
