Re: Unexpected behavior after OOM errors

On Wed, Jun 17, 2026 at 02:27:25PM +0200, Matthias van de Meent wrote:
> On Wed, 17 Jun 2026 at 08:00, Alexander Lakhin <exclusion@gmail.com> wrote:
>> 1) An issue in lookup_type_cache()
> 
> I believe this is caused by partial subsystem initialization. Attached
> patch 0001 should address this failure without causing the server to
> restart on OOM.

Hmm.  I think that this is an ordering problem.  We could make the
callbacks be registered last, once we are sure that the two hash 
tables and the in-progress list have been initialized.  I am not sure
that this requires a new facility; it is also an advantage to keep the
initialization sequence in a one code path, without an abstraction.

RelIdToTypeIdCacheHash and RelIdToTypeIdCacheHash are in the
TopMemoryContext, static to the process, so we could just check them
for NULL-ness to make the initialization repeatable.  That gives me
the attached v2.  Reusing Alexander's randomness trick, that looks
stable here.

>> 2) An issue in GetSnapshotData()
> 
> Again, caused by partial initialization, though in this case it's of a
> SnapshotData* which is later checked again. Attached patch 0002 should
> address this failure.

Yeah, that seems right to make repeated calls of GetSnapshotData()
able to work.  LGTM.

>> 3) An issue in StandbyAcquireAccessExclusiveLock()
> <snip>
> 
> I'm not sure how to solve this correctly; I think ideally the
> StandbyAcquireAccessExclusiveLock() hash code would be wrapped by a
> critical section, but I'm not 100% sure if that will be a sufficient
> approach; and it'd definitely need some code to allow the various
> hashmaps' memctxs to alloc during critical sections.

Not checked this one yet.

Thoughts about the first part?
--
Michael