| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Rick Otten <rottenwindfish(at)gmail(dot)com>, ronan(dot)dunklau(at)dalibo(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: your mail |
| Date: | 2017-08-08 21:19:41 |
| Message-ID: | 20170808211941.p74wtzo5oxt7t5is@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2017-08-08 17:12:14 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2017-08-08 16:15:15 -0400, Tom Lane wrote:
> >> I don't see much of a way to do that in the "typical" case where
> >> the library load happens as a result of a SQL command. You can't
> >> just say "oh, we're not in a transaction" and then later "wait,
> >> yes we are".
>
> > Transaction seems hard, but setting CurrentMemoryContext = NULL during
> > library load seems quite possible. And that'll cause a lot of code that
> > assumes an in-progress transaction to fail.
>
> And it would cause a lot of code that *doesn't* assume that to fail,
> too. That has basically nothing to do with not being in a transaction,
> so I don't think it would be helpful here.
Wouldn't mostsuch code be a bad idea anyway? If it's in transaction
context, you can't rely on the lifetime of allocated memory. If it's
TopMemoryContext, the code should be careful about not leaking. So
being aware of/explicit about the context used seems advisable.
- Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jarred Ward | 2017-08-08 21:56:53 | 9.6.3 - Backend Crash - Parallel Worker Prepared Statements |
| Previous Message | Tom Lane | 2017-08-08 21:12:14 | Re: your mail |