Re: multixacts woes

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