| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> |
| Subject: | Re: locking [user] catalog tables vs 2pc vs logical rep |
| Date: | 2021-05-24 05:03:12 |
| Message-ID: | YKszkBugv7heub1G@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Feb 22, 2021 at 02:28:47PM -0800, Andres Freund wrote:
> Perhaps all that we need to do is to disallow 2PC prepare if [user]
> catalog tables have been locked exclusively? Similar to how we're
> disallowing preparing tables with temp table access.
At least for anything involving critical relations that get loaded at
startup? It seems to me that if we can avoid users to get them
completely locked out even if they run the operation on an object
they own, that would be better than requiring tweaks involving
pg_resetwal or equal to rip of the 2PC transaction from existence.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2021-05-24 05:04:36 | Re: Race condition in recovery? |
| Previous Message | Michael Paquier | 2021-05-24 04:50:13 | Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump |