| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Robins Tharakan <tharakan(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: ALTER TABLE ALTER COLUMN SET TYPE crash |
| Date: | 2020-08-25 17:35:11 |
| Message-ID: | 20200825173511.GA20679@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, Aug 25, 2020 at 12:14:20PM -0400, Tom Lane wrote:
> I think the nature of the problem (and Robins' other report too) is pretty
> clear. We have a SQL or plpgsql function that's trying to access a table
> that is inconsistent during an ALTER TABLE operation. The function would
> be locked out from seeing that transient state if it were in another
> session, thanks to normal locking rules; but the lock acquisition rules
> don't prevent same-session accesses.
>
> ALTER TABLE and related utility commands contain guards against the
> reverse form of this problem: CheckTableNotInUse will bitch if there's
> some already-active outer query referencing the table. But we haven't
> thought about the possibility of one of these commands executing
> user-defined code midway through.
That does explain why it fails on the _second_ time through those
lower-level functions.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2020-08-25 20:07:28 | BUG #16592: websearch_to_tsquery() returns queries that don't result in expected matches |
| Previous Message | Tom Lane | 2020-08-25 16:14:20 | Re: ALTER TABLE ALTER COLUMN SET TYPE crash |