Robert Haas wrote: > OK, I have made this change. Barring further trouble reports, this > completes the multixact work I plan to do for the next release.
Many thanks for all the effort here -- much appreciated. > 2. The recent changes adjust things - for good reason - so that the > safe threshold for multixact member creation is advanced only at > checkpoint time. This means it's theoretically possible to have a > situation where autovacuum has done all it can, but because no > checkpoint has happened yet, the user can't create any more > multixacts. Thanks to some good work by Thomas, autovacuum will > realize this and avoid spinning uselessly over every table in the > system, which is good, but you're still stuck with errors until the > next checkpoint. Essentially, we're hoping that autovacuum will clean > things up far enough in advance of hitting the threshold where we have > to throw an error that a checkpoint will intervene before the error > starts happening. It's possible we could improve this further, but I > think it would be unwise to mess with it right now. It may be that > there is no real-world problem here. See my response to Josh. I think much of the current rube-goldbergian design is due to the fact that pg_control cannot be changed in back branches. Going forward, I think a better plan is to include more info in pg_control, WAL-log more operations, remove checkpoint from the loop and have everything happen at vacuum time. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, 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
