Policy for Abandoned Extensions

"David E. Wheeler" <david@justatheory.com> writes:

A couple times in the last year, people have hit me up to ask about taking ownership of abandoned extensions on PGXN. In neither case was I able to track down the original owner, not for lack of trying. Then this past week I was alerted to potential superuser escalations in two more abandoned extensions on PGXN.

Clearly not a good situation.

So I think it may be time for a policy on this. What do you recommend? I have a few thoughts and options, some of which would require additional work on PGXN at some point.
* Set up a committee of some kind to investigate abandoned extensions and find vet and find replacement developers when possible.
* Cease transferring extensions without permission from long-gone developers and instead suggest that people fork extensions and give them new names.
* Add an annotation to apparently abandoned extensions and mark them as such on pgxn.org, along with relevant pointers to replacement extensions and contact information for the original developer to get in touch and reclaim access. Or maybe it goes away if they create a new release.

I think we have to think first of the users' experience. It's not
good if an extension that is abandoned and has known problems looks
the same as actively-maintained ones. So I would prioritize your last
bullet point of somehow annotating seemingly-abandoned extensions.

By the same token, I don't think "fork under a different name" offers
good user experience: what it offers is confusion. So I prefer a
mechanism that allows a new developer to take over an abandoned
extension over one that encourages forking, even if the latter is
supported by a pointer-to-replacement mechanism. For myself, if I'd
stopped maintaining something for lack of time/interest, I'd be very
happy if someone else picked it up; but I do realize that probably
not everyone feels that way. (Probably-impractical idea: when an
extension is first listed on pgxn, ask if it'd be okay to reassign
ownership in the event that development seems dead.)

In any case, I agree that you should have some sort of defined
process for deciding that an extension is abandoned. Whether
that's a committee or just a checklist, I don't have a strong
opinion about. But it should be unsurprising to all concerned
when such a determination is made.

regards, tom lane

On 10/10/26 13:15, Tom Lane wrote:

"David E. Wheeler" <david@justatheory.com> writes:

A couple times in the last year, people have hit me up to ask about taking ownership of abandoned extensions on PGXN. In neither case was I able to track down the original owner, not for lack of trying. Then this past week I was alerted to potential superuser escalations in two more abandoned extensions on PGXN.

Clearly not a good situation.

So I think it may be time for a policy on this. What do you recommend? I have a few thoughts and options, some of which would require additional work on PGXN at some point.
* Set up a committee of some kind to investigate abandoned extensions and find vet and find replacement developers when possible.
* Cease transferring extensions without permission from long-gone developers and instead suggest that people fork extensions and give them new names.
* Add an annotation to apparently abandoned extensions and mark them as such on pgxn.org, along with relevant pointers to replacement extensions and contact information for the original developer to get in touch and reclaim access. Or maybe it goes away if they create a new release.

I think we have to think first of the users' experience. It's not
good if an extension that is abandoned and has known problems looks
the same as actively-maintained ones. So I would prioritize your last
bullet point of somehow annotating seemingly-abandoned extensions.

By the same token, I don't think "fork under a different name" offers
good user experience: what it offers is confusion. So I prefer a
mechanism that allows a new developer to take over an abandoned
extension over one that encourages forking, even if the latter is
supported by a pointer-to-replacement mechanism. For myself, if I'd
stopped maintaining something for lack of time/interest, I'd be very
happy if someone else picked it up; but I do realize that probably
not everyone feels that way. (Probably-impractical idea: when an
extension is first listed on pgxn, ask if it'd be okay to reassign
ownership in the event that development seems dead.)

In any case, I agree that you should have some sort of defined
process for deciding that an extension is abandoned. Whether
that's a committee or just a checklist, I don't have a strong
opinion about. But it should be unsurprising to all concerned
when such a determination is made.

It may be impractical, but given cases like the XZ Utils backdoor
situation (i.e where a malicious person showed up offering to "help"
maintain an open source project where the original maintainer was
stepping away), it seems like any transfer process needs a vetting step.

--
Joe Conway
PostgreSQL Contributors Team
Amazon Web Services: https://aws.amazon.com

Joe Conway <mail@joeconway.com> writes:

It may be impractical, but given cases like the XZ Utils backdoor
situation (i.e where a malicious person showed up offering to "help"
maintain an open source project where the original maintainer was
stepping away), it seems like any transfer process needs a vetting step.

Yeah, if the replacement maintainer is malicious or even merely
incompetent, things could be worse than leaving the extension alone.
But that wasn't on David's list of worries, so I imagine he thinks
that's a soluble problem.

regards, tom lane

Maybe we can add "end-of-life" versions to extensions?

So if we have versions x.y.z-alpha and x.y.z-beta before x.y.z , maybe we
can also have x.y.z-abandoned and/or x.y.z-unmaintained at the other end?

So anyone installing such will habe better chance to notice.

And we could make them als sort after normal versions in
postgres_debversion and pg_debver :)

---
Hannu

On Sat, Oct 10, 2026 at 8:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

On Sat, Oct 10, 2026 at 9:55 PM Hannu Krosing <hannuk@google.com> wrote:

Maybe we can add "end-of-life" versions to extensions?

So if we have versions x.y.z-alpha and x.y.z-beta before x.y.z , maybe we
can also have x.y.z-abandoned and/or x.y.z-unmaintained at the other end?

So anyone installing such will habe better chance to notice.

That of course implies that the repository maintainer would be the one to
re-release the latest version with -unmaintained at the end when this
happens.
So when it is picked up again, the maintained version needs to get a
version pump

On Oct 10, 2026, at 15:58, Hannu Krosing <hannuk@google.com> wrote:

That of course implies that the repository maintainer would be the one to re-release the latest version with -unmaintained at the end when this happens.
So when it is picked up again, the maintained version needs to get a version pump

Yeah, I could see adding some metadata that authors could use for this purpose. CPAN added something like this a while back so that various messages appear at the top of their pages on metacpan.org. Could hunt that down and copy it.

D

Hi David,

I(with fable) pulled some numbers from master.pgxn.org today.

For 218 of the 496 distributions the last PGXN release is more than five
years old. I checked the repositories with a script and looked at the
unclear ones one by one.

- 51 are alive upstream. 37 at the repository in META.json, for example hll
and rum, and 14 that moved, for example mongo_fdw and redis_fdw.
- 13 were replaced by something in core.
- 32 had some activity two to five years ago, or I could not tell.
- 122 show no sign of life for five years. 70 of them ship C code.

Only 3 of the 122 are still packaged in the PGDG apt or yum repositories
for 17 and 18.

So the dead and still shipped set looks small. The 51 look like a different
case, the project is alive but nobody releases on PGXN. A pointer to
upstream may be enough there.

I may have missed some moves, so 122 is an upper bound. I can send the
table if you want more detailed data.

Thanks,
Shihao

On Oct 10, 2026, at 13:57, Joe Conway <mail@joeconway.com> wrote:

It may be impractical, but given cases like the XZ Utils backdoor situation (i.e where a malicious person showed up offering to "help" maintain an open source project where the original maintainer was stepping away), it seems like any transfer process needs a vetting step.

Joe, I hear you volunteering to help me form a group and process to do so. 😂

Best,

David

On Oct 10, 2026, at 14:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Yeah, if the replacement maintainer is malicious or even merely
incompetent, things could be worse than leaving the extension alone.
But that wasn't on David's list of worries, so I imagine he thinks
that's a soluble problem.

Oh I worry about it, but it was implied, because it’s bigger than just abandoned extensions, as the xz case makes clear.

D

On Oct 10, 2026, at 17:19, shihao zhong <zhong950419@gmail.com> wrote:

I may have missed some moves, so 122 is an upper bound. I can send the table if you want more detailed data.

Thanks for the offer but I can query the PGXN database directly. Will be useful to do so to figure out what to do for each case, but not so much for the overall problem.

D

"David E. Wheeler" <david@justatheory.com> writes:

On Oct 10, 2026, at 17:19, shihao zhong <zhong950419@gmail.com> wrote:

I may have missed some moves, so 122 is an upper bound. I can send the table if you want more detailed data.

Thanks for the offer but I can query the PGXN database directly. Will be useful to do so to figure out what to do for each case, but not so much for the overall problem.

Shihao's numbers did comfort me a little bit, because they show that
unmaintained extensions tend to drop out of use more quickly than I'd
have guessed. For the ones that include C code, there's an obvious
forcing function for that: the code will tend to stop being compilable
under newer Postgres releases if it's never getting touched at all.

Which is not to say that it's not important for PGXN to take some
action here. But perhaps it's less urgent than I first thought.

regards, tom lane

On Oct 11, 2026, at 14:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Which is not to say that it's not important for PGXN to take some
action here. But perhaps it's less urgent than I first thought.

Oh, sure. I don’t think it’s *super* urgent, but as I’ve had a couple inquiries in the past year, after 15 years without any, I figured it was time to start the conversation.

I agree with your upthread comments that we should aim to minimize pain for users. But it may also be the case, at some point, where there is an extension with a vulnerability and no one able and willing to take it over, in which case we might need to do something else.

Bah, I never implemented deletion of extensions from PGXN. Let’s hope that situation doesn’t come up any time soon!

D