Kevin Brown <kevin@sysexperts.com> writes:
> Instead, have each backend maintain its own separate list in shared
> memory. The only readers of a given list would be the backend it belongs
> to and the bgwriter, and the only time bgwriter attempts to read the
> list is at checkpoint time.
> The sum total size of all the lists shouldn't be that much larger than
> it would be if you maintained it as a global list.
I fear that is just wishful thinking. Consider the system catalogs as a
counterexample of files that are likely to be touched/modified by many
different backends.
The bigger problem though with this is that it makes the problem of
list overflow much worse. The hard part about shared memory management
is not so much that the available space is small, as that the available
space is fixed --- we can't easily change it after postmaster start.
The more finely you slice your workspace, the more likely it becomes
that one particular part will run out of space. So the inefficient case
where a backend isn't able to insert something into the appropriate list
will become considerably more of a factor.
> but it seems clear to me that you want to do
> a sync() *first*, then the fsync()s.
Hmm, that's an interesting thought. On a machine that's doing a lot of
stuff besides running the database, a global sync would be
counterproductive --- but we could easily make it configurable as to
whether to issue the sync() or not. It wouldn't affect correctness.
regards, tom lane
