Thanks or the confirmation, and here's hoping no ICBMs!
On 2023-Jun-13, Morris de Oryx wrote:
> Quick follow-up: I've heard back from AWS regarding applying Tom Lane's
> patch. Nope. RDS releases numbered versions, nothing else.
Sounds like a reasonable policy to me.
> As Postgres is now at 15.8/15.3 in the wild and on 15.7/15.3 on RDS,
> I'm guessin
Quick follow-up: I've heard back from AWS regarding applying Tom Lane's
patch. Nope. RDS releases numbered versions, nothing else. As Postgres is
now at 15.8/15.3 in the wild and on 15.7/15.3 on RDS, I'm guessing that the
patch won't be available until 14.9/15.4.
Am I right in thinking that this p
Another suggestion for AWS/RDS: Expose *all of the logs in the upgrade tool
chain*. If I'd had all of the logs at the start of this, I'd have been able
to track down the issue myself quite quickly. Setting up that simple case
database took me less than an hour today. Without the logs, it's been
imp
Reminds me to say a *big* *thank you* to everyone involved in and
contributing to Postgres development for making error messages which are so
good. For a programmer, error text is a primary UI. Most Postgres errors
and log messages are clear and sufficient. Even when they're a bit obscure,
they alw
On Sun, Jun 4, 2023 at 1:41 PM Tom Lane wrote:
> Kirk Wolak writes:
> .. to strings of other lengths. So the new output (before 016107478
> fixed it) is
>
> pg_dump: warning: could not resolve dependency loop among these items:
> pg_dump: detail: FUNCTION a_f (ID 216 OID 40532)
> pg_dump: deta
Well *that *was quick. Thank you!
Imseih, Sami what are the chances of getting RDS to apply this patch?
Postgres 15 was released nearly 8 months ago, and it would be great to get
onto it.
Thanks
On Mon, Jun 5, 2023 at 3:01 PM Tom Lane wrote:
> Morris de Oryx writes:
> > Can anyone suggest a p
Morris de Oryx writes:
> Can anyone suggest a path forward for me with the upgrade to PG 15?
Apply this patch:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ca9e79274938d8ede07d9990c2f6f5107553b524
or more likely, pester RDS to do so sooner than the next quarterly
releases.
Edit error above, I said that dependency tracking "does not seem to work."
Not what I mean, it works great...It just does not seem to work for me with
any of the upgrade options.
>
Thanks to Imseih and Sami at AWS for reporting this. The original case
comes from an upgrade I've been trying to complete for a couple of months
now, since RDS started supporting 15 with a 15.2 release.
The process has been slow and painful because, originally, there was a bug
on the RDS side that
Kirk Wolak writes:
> On Sat, Jun 3, 2023 at 2:28 PM Tom Lane wrote:
>> I'm not really sure which of these I like better. The first one
>> is a much simpler code change, and there is some value in labeling
>> the output like that. The second patch's output seems less cluttered,
>> but it's commi
"Imseih (AWS), Sami" writes:
> Some minor comments I have:
> 1/
> + agginfo[i].aggfn.postponed_def = false; /* might get set during sort */
> This is probably not needed as it seems that we can only
> get into this situation when function dependencies are tracked.
That's just to keep from
On Sat, Jun 3, 2023 at 2:28 PM Tom Lane wrote:
> Kirk Wolak writes:
> > On Fri, Jun 2, 2023 at 8:16 AM Tom Lane wrote:
> > If I comprehend the suggestion, it will label each line with a warning.
> > Which implies I have 6 Warnings.
>
> Right, I'd forgotten that pg_log_warning() will interpose
Kirk Wolak writes:
> On Fri, Jun 2, 2023 at 8:16 AM Tom Lane wrote:
>> BTW, now that I see a case the default printout here seems
>> completely ridiculous. I think we need to do
>> - pg_log_info(" %s", buf);
>> + pg_log_warning(" %s", buf);
> If I comprehend the suggestion, it w
> So it's lacking a rule to tell it what to do in this case, and the
> default is the wrong way around. I think we need to fix it in
> about the same way as the equivalent case for matviews, which
> leads to the attached barely-tested patch.
Thanks for the patch! A test on the initially reported u
On Fri, Jun 2, 2023 at 8:16 AM Tom Lane wrote:
> or with -v:
>
> pg_dump: warning: could not resolve dependency loop among these items:
> pg_dump: FUNCTION a_f (ID 218 OID 40664)
> pg_dump: CONSTRAINT a_pkey (ID 4131 OID 40663)
> pg_dump: POST-DATA BOUNDARY (ID 4281)
> pg_dump: TABLE D
"Imseih (AWS), Sami" writes:
> With the attached repro, pg_restore fails with
> pg_restore: error: could not execute query: ERROR: constraint "a_pkey" for
> table "a" does not exist
> Command was: CREATE FUNCTION public.a_f(c1_in text, c2 integer DEFAULT 60)
> RETURNS void
Hmph. The other thi
Hi,
What appears to be a pg_dump/pg_restore bug was observed with the new
BEGIN ATOMIC function body syntax introduced in Postgres 14.
Dependencies inside a BEGIN ATOMIC function cannot be resolved
if those dependencies are dumped after the function body. The repro
case is when a primary key cons
18 matches
Mail list logo
