| From: | Benoit Lobréau <benoit(dot)lobreau(at)gmail(dot)com> |
|---|---|
| To: | Shayon Mukherjee <shayonj(at)gmail(dot)com> |
| Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch) |
| Date: | 2025-01-30 13:51:24 |
| Message-ID: | CAPE8EZ7jUdcbmBWmr2+EeweQozAD5ACFY9KqdMCJwAhpr=6UZg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I did some additional testing with this command within transactions.
I had the "BEGIN; ALTER INDEX; EXPLAIN; ROLLBACK;" scenario in mind, but
didn't realise we acquire an AccessExclusiveLock on the index. Therefore, it's
not possible to change the visibility within a single transaction....
unless you don’t mind blocking all access to the relation.
I read the comments at the top of "AlterTableGetLockLevel" and in the
documentation and I understand that this behavior seems unavoidable.
I suppose this is what was meant by the "globally visible effects" of an ALTER
INDEX in the old discussion ? [1]
Being able to rollback the changes is nice, but in this case there is
not much to alter
back anyway. This is probably not the intended use case (hence the
discussion about
GUCs and hints).
[1] https://www.postgresql.org/message-id/30558.1529359929%40sss.pgh.pa.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2025-01-30 14:02:16 | Re: Improve error handling for invalid slots and ensure a same 'inactive_since' time for inactive slots |
| Previous Message | Ashutosh Sharma | 2025-01-30 13:45:30 | Re: Orphaned users in PG16 and above can only be managed by Superusers |