Re: Something's busted in plpgsql composite-variable handling

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Something's busted in plpgsql composite-variable handling
Date: 2018-08-28 15:04:41
Message-ID: 6854CC86-81A7-41CD-BFA3-AA5FD2D74125@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On Aug 28, 2018, at 10:45 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>
>
> 2018-08-28 16:38 GMT+02:00 Jonathan S. Katz <jkatz(at)postgresql(dot)org <mailto:jkatz(at)postgresql(dot)org>>:
>
> > On Aug 26, 2018, at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
> >
> > I wrote:
> >> [ dropping and recreating a composite type confuses plpgsql ]
> >> That's not very nice. What's worse is that it works cleanly in v10,
> >> making this a regression, no doubt caused by the hacking I did on
> >> plpgsql's handling of composite variables.
> >
> > So I'm now inclined to withdraw this as an open item. On the other
> > hand, it is a bit worrisome that I happened to hit on a case that
> > worked better before. Maybe I'm wrong to judge this unlikely to
> > happen in the field.
> >
> > Thoughts?
>
> Typically if you’re creating a composite type, you’re planning to store
> data in that type, so you’re probably not going to just drop it without
> an appropriate migration strategy around it, which would (hopefully)
> prevent the above case from happening.
>
> I wouldn’t let this block the release, so +1 for removing from open
> items.
>
> That depends - the question is - what is a reason of this issue, and how to fix it?

Tom explained the cause and a proposed a fix earlier in the thread, and
cautioned that it could involve a performance hit.

> It is not strong issue, but it is issue, that breaks without outage deployment.

Have you encountered this issue in the field? It is a bug, but it seems to
be an edge case based on normal usage of PostgreSQL, and I still don’t
see a reason why it needs to be fixed prior to the release of 11. If there’s
an easier solution for solving it, yes, we could go ahead, but it sounds like
there’s a nontrivial amount of work + testing to do.

I do think it should be fixed for 12 now that we’ve identified it. We could move
it from the “Open Items” to the “Live Issues” list for what it’s worth.

Jonathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2018-08-28 15:20:41 Re: Dimension limit in contrib/cube (dump/restore hazard?)
Previous Message Bernd Helmle 2018-08-28 15:03:52 Re: pg_verify_checksums failure with hash indexes