On Tue, Jul 05, 2022 at 11:29:03PM -0400, Tom Lane wrote:
> Yeah. I think that 08385ed26 fixes this, but we've had no new
> reports yet :-(
Indeed. Things are right now. Thanks!
--
Michael
signature.asc
Description: PGP signature
Michael Paquier writes:
> crake and drongo look unhappy after that, as of the upgrade from 9.6:
Yeah. I think that 08385ed26 fixes this, but we've had no new
reports yet :-(
regards, tom lane
On Tue, Jul 05, 2022 at 01:07:48PM -0400, Tom Lane wrote:
> It looks about ready to me. Pushed with some minor cosmetic
> adjustments.
crake and drongo look unhappy after that, as of the upgrade from 9.6:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2022-07-05%2020%3A48%3A21
h
Andrey Borodin writes:
> The patch is marked WiP, what is in progress as of now?
It looks about ready to me. Pushed with some minor cosmetic
adjustments.
regards, tom lane
> On 29 Jun 2022, at 23:07, Justin Pryzby wrote:
>
> On Wed, Jun 29, 2022 at 10:58:44PM +0500, Andrey Borodin wrote:
>>> On 28 Jun 2022, at 04:30, Justin Pryzby wrote:
>>>
>>> Nope, it's as I said: this would break pg_upgrade from older versions.
>>
>> As far as I understand 9.5 is not supp
On Wed, Jun 29, 2022 at 10:58:44PM +0500, Andrey Borodin wrote:
> > On 28 Jun 2022, at 04:30, Justin Pryzby wrote:
> >
> > Nope, it's as I said: this would break pg_upgrade from older versions.
>
> As far as I understand 9.5 is not supported. Probably, it makes sense to keep
> pg_upgrade runnin
> On 28 Jun 2022, at 04:30, Justin Pryzby wrote:
>
> Nope, it's as I said: this would break pg_upgrade from older versions.
As far as I understand 9.5 is not supported. Probably, it makes sense to keep
pg_upgrade running against 9.5 clusters, but I'm not sure if we do this
routinely.
Besid
On Sat, Jun 25, 2022 at 03:34:49PM +0500, Andrey Borodin wrote:
> > On 25 Jun 2022, at 01:28, Justin Pryzby wrote:
>
> > this is my latest.
> > <0001-WIP-pg_upgrade-check-detect-old-polymorphics-from-pr.patch>
>
> Let's rename "databases_with_old_polymorphics.txt" to somthing like
> "old_polym
> On 25 Jun 2022, at 01:28, Justin Pryzby wrote:
>
> But what I wrote already shows what you want.
Just tested that, you are right. My version was printing name, I didn't know
regproc prints so nice definition.
> this is my latest.
> <0001-WIP-pg_upgrade-check-detect-old-polymorphics-from-p
On Fri, Jun 24, 2022 at 11:43:18PM +0500, Andrey Borodin wrote:
> > On 23 Jun 2022, at 04:58, Justin Pryzby wrote:
> >
> > On Fri, Jun 17, 2022 at 10:14:13AM -0400, Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby
> >>> wrote:
> To me, oid>=163
> On 23 Jun 2022, at 04:58, Justin Pryzby wrote:
>
> On Fri, Jun 17, 2022 at 10:14:13AM -0400, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby wrote:
To me, oid>=16384 seems more hard-wired than namespace!='pg_catalog'.
>>
>>> Extensions can be
On Fri, Jun 17, 2022 at 10:14:13AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby wrote:
> >> To me, oid>=16384 seems more hard-wired than namespace!='pg_catalog'.
>
> > Extensions can be installed into pg_catalog, but they can't get
> > low-numbe
Robert Haas writes:
> On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby wrote:
>> To me, oid>=16384 seems more hard-wired than namespace!='pg_catalog'.
> Extensions can be installed into pg_catalog, but they can't get
> low-numbered OIDs.
Exactly. (To be clear, I had in mind writing something inv
pá 17. 6. 2022 v 15:07 odesílatel Robert Haas
napsal:
> On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby
> wrote:
> > > Also, I'd be inclined to reject system-provided objects by checking
> > > for OID >= 16384 rather than hard-wiring assumptions about things
> > > being in pg_catalog or not.
> >
On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby wrote:
> > Also, I'd be inclined to reject system-provided objects by checking
> > for OID >= 16384 rather than hard-wiring assumptions about things
> > being in pg_catalog or not.
>
> To me, oid>=16384 seems more hard-wired than namespace!='pg_catalo
On Wed, Jun 15, 2022 at 03:32:04PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > But Petr has a point - pg_upgrade should aspire to catch errors in --check,
> > rather than starting and then leaving a mess behind for the user to clean up
>
> Agreed; pg_upgrade has historically tried to find
Justin Pryzby writes:
> But Petr has a point - pg_upgrade should aspire to catch errors in --check,
> rather than starting and then leaving a mess behind for the user to clean up
Agreed; pg_upgrade has historically tried to find problems similar to
this. However, it's not just aggregates that ar
On Wed, May 04, 2022 at 07:34:15AM -0700, David G. Johnston wrote:
> On Wed, May 4, 2022 at 7:29 AM Petr Vejsada wrote:
> > We solved it (in our case) dropping the aggregate before upgrade and
> > re-create in using new syntax in V14:
> >
> > but pg_upgrade shouldn't fail on this.
> >
> > I hope i
18 matches
Mail list logo
