Re: pg_stat_*_columns?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Jun 20, 2015 at 6:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Hmmm. This sounds attractive, but what happens if we fail to create
>> a new DSM when needed?

> Presumably you keep using the old one and retry later. I mean, out of
> memory is out of memory; you can't move a variable-size data structure
> into shared memory without the possibility of running into OOM
> failures at some point.

Right, which is one reason that Magnus' thought of replacing the file
transmission mechanism with a message queue might be a good alternative.

> If we arranged things so that the processes could use the data in the
> DSM directly rather than having to copy it out, we'd presumably save
> quite a bit of memory, since the whole structure would be shared
> rather than each backend having its own copy.

That is not going to happen, because it would imply locking out the stats
collector from doing any more updates for the entire time that any backend
is looking at the results. We *do* need to copy.

> But if the structure
> got too big to map (on a 32-bit system), then you'd be sort of hosed,
> because there's no way to attach just part of it. That might not be
> worth worrying about, but it depends on how big it's likely to get - a
> 32-bit system is very likely to choke on a 1GB mapping, and maybe even
> on a much smaller one.

Yeah, I'm quite worried about assuming that we can map a data structure
that might be of very significant size into shared memory on 32-bit
machines. The address space just isn't there.

regards, tom lane