| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: recovering from "found xmin ... from before relfrozenxid ..." |
| Date: | 2020-07-14 07:08:22 |
| Message-ID: | f99aa600-406b-8de3-4aa8-e2583b282312@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-07-14 02:41, Robert Haas wrote:
> I think that our normal back-patching rules are based primarily on the
> risk of breaking things, and a new contrib module carries a pretty
> negligible risk of breaking anything that works today.
I think that all feature code ought to go through a beta cycle. So if
this code makes it to 14.0 or 14.1, then I'd consider backpatching it.
> Now, if this goes into v14, we can certainly stick it up on github, or
> put it out there in some other way for users to download,
> self-compile, and install, but that seems noticeably less convenient
> for people who need it, and I'm not clear what the benefit to the
> project is.
In the meantime, if you're wizard enough to deal with this kind of
thing, you could also clone the module from the PG14 tree and build it
against older versions manually.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2020-07-14 07:13:13 | Re: Parallel Seq Scan vs kernel read ahead |
| Previous Message | Peter Geoghegan | 2020-07-14 06:55:17 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |