[18] Fix a few issues with the collation cache - Mailing list pgsql-hackers

From Jeff Davis
Subject [18] Fix a few issues with the collation cache
Date
Msg-id 54d20e812bd6c3e44c10eddcd757ec494ebf1803.camel@j-davis.com
Whole thread Raw
List pgsql-hackers
The collation cache, which maps collation oids to pg_locale_t objects,
has a few longstanding issues:

1. Using TopMemoryContext too much, with potential for leaks on error
paths.

2. Creating collators (UCollator for ICU or locale_t for libc) that can
leak on some error paths. For instance, the following will leak the
result of newlocale():

  create collation c2 (provider=libc,
    locale='C.utf8', version='bogus');

3. Not invalidating the cache. Collations don't change in a way that
matters during the lifetime of a backend, so the main problem is DROP
COLLATION. That can leave dangling entries in the cache until the
backend exits, and perhaps be a problem if there's OID wraparound.

The patches make use of resource owners for problems #2 and #3. There
aren't a lot of examples where resource owners are used in this way, so
I'd appreciate feedback on whether this is a reasonable thing to do or
not. Does it feel over-engineered? We can solve these problems by
rearranging the code to avoid problem #2 and iterating through the hash
table for problem #3, but using resource owners felt cleaner to me.

These problems exist in all supported branches, but the fixes are
somewhat invasive so I'm not inclined to backport them unless someone
thinks the problems are serious enough.

Regards,
    Jeff Davis


Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [patch] Imporve pqmq
Next
From: Tom Lane
Date:
Subject: Re: Don't overwrite scan key in systable_beginscan()