Re: why there is not VACUUM FULL CONCURRENTLY?
От | Alvaro Herrera |
---|---|
Тема | Re: why there is not VACUUM FULL CONCURRENTLY? |
Дата | |
Msg-id | 202501310932.ugw3k5c4orgv@alvherre.pgsql обсуждение исходный текст |
Ответ на | why there is not VACUUM FULL CONCURRENTLY? (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: why there is not VACUUM FULL CONCURRENTLY?
|
Список | pgsql-hackers |
On 2025-Jan-31, Antonin Houska wrote: > I assume the patch should mark CLUSTER deprecated rather than removing it > immediately. Yeah, we should certainly not make any statements fail that work today. Same goes for VACUUM FULL. > I also agree that tables not being REPACKed should be treated as not being > logically decoded, i.e. the logical decoding specific information should not > be written to WAL for them. Neither time nor energy should be wasted :-) Cool. Something that Robert Haas just mentioned to me is handling of row locks: if concurrent transactions are keeping rows in the original table locked (especially SELECT FOR KEY SHARE, since that's not considered by logical decoding at present and it would be possible to break foreign keys if we just do nothing), them we need these to be "transferred" to the new table somehow. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "¿Qué importan los años? Lo que realmente importa es comprobar que a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda)
В списке pgsql-hackers по дате отправления: