| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: some last patches breaks plan cache |
| Date: | 2018-04-06 06:14:19 |
| Message-ID: | CAFj8pRC8g+i0BeZeMEE0J8Jt=U+YuV4yyKJ6MoP77QRCgtxWzg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2018-04-05 21:01 GMT+02:00 Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com>:
> On 4/4/18 14:03, Tomas Vondra wrote:
> >> If there's really no other way, you could use a PG_TRY block to
> >> ensure that the pointer gets reset on the way out. But I question
> >> why we've got a design that requires that in the first place. It's
> >> likely to have more problems than this.
> >
> > I agree it needs a solution that does not require us to track and
> > manually reset pointers on random places. No argument here.
>
> I've committed a fix with PG_TRY.
>
> A more complete solution would be to able to keep the plan independent
> of a resowner. That would require a bit more deep surgery in SPI, it
> seems. I'll take a look if it's doable.
>
The issues that I detected in plpgsql_check are fixed
Thank you
Pavel
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2018-04-06 06:19:01 | Re: make installcheck-world in a clean environment |
| Previous Message | Pavel Stehule | 2018-04-06 05:38:15 | Re: csv format for psql |