On Tue, Nov 26, 2024 at 2:18 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> I haven't had a chance to experiment with that on Windows, but I'm
> hoping that in the worst case fallback to a single mapping via proposed
> infrastructure (and the consequent limitations) would be acceptable.
Yeah, if you can still fall back to a single mapping, I think that's
OK. It would be nicer if it could work on every platform in the same
way, but half a loaf is better than none.
> > code, but I'm not sure exactly which points are safe. If we have no
> > code anywhere that assumes the address of an unpinned buffer can't
> > change before we pin it, then I guess the check for pins is the only
> > thing we need, but I don't know that to be the case.
>
> Probably I'm missing something here. What scenario do you have in mind,
> when the address of a buffer is changing?
I was assuming that if you expand the mapping for shared_buffers, you
can't count on the new mapping being at the same address as the old
mapping. If you can, that makes things simpler, but what if the OS has
mapped something else just afterward, in the address space that you're
hoping to use when you expand the mapping?
> > It looks to me like the patch doesn't expand the buffer mapping table,
> > which seems essential. But maybe I missed that.
>
> Do you mean the "Shared Buffer Lookup Table"? It does expand it, but
> under somewhat unfitting name STRATEGY_SHMEM_SLOT. But now that I look
> at the code, I see a few issues around that -- so I would have to
> improve it anyway, thanks for pointing that out.
Yeah, we -- or at least I -- usually call that the buffer mapping
table. There are identifiers like BufMappingPartitionLock, for
example. I'm slightly surprised that the ShmemInitHash() call uses
something else as the identifier, but I guess that's how it is.
--
Robert Haas
EDB: http://www.enterprisedb.com
