Re: Write visibility map during CLUSTER/VACUUM FULL

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: Write visibility map during CLUSTER/VACUUM FULL
Дата
Msg-id 20211227025931.GM17618@telsasoft.com
обсуждение исходный текст
Ответ на Re: Write visibility map during CLUSTER/VACUUM FULL  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Write visibility map during CLUSTER/VACUUM FULL  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On Mon, Nov 15, 2021 at 04:38:56PM -0600, Justin Pryzby wrote:
> On Sun, Aug 29, 2021 at 07:26:42PM -0500, Justin Pryzby wrote:
> > On Mon, Jun 28, 2021 at 11:22:01AM +0300, Anna Akenteva wrote:
> > > On 2019-11-29 05:32, Michael Paquier wrote:
> > > > These comments are unanswered for more than 2 months, so I am marking
> > > > this entry as returned with feedback.
> > > 
> > > I'd like to revive this patch. To make further work easier, attaching a
> > > rebased version of the latest patch by Alexander.
> > > 
> > > As for having yet another copy of logic determining visibility: the
> > > visibility check was mainly taken from heap_page_is_all_visible(), so I
> > > refactored the code to make sure that logic is not duplicated. The updated
> > > patch is attached too.
> > 
> > I agree that it's strange that VACUUM(FREEZE) freezes tuples but not VM bits,
> > nor page-level PD_ALL_VISIBLE (which is implied by all frozen).  After FULL
> > runs (taking an exclusive lock on the table), it's necessary to then vacuum the
> > table again to get what's intended.
> > 
> > Rebased on f10f0ae420ee62400876ab34dca2c09c20dcd030.
> 
> Rebased this patch again
> 
> Alexander, are you planning on working on this patch ?
> 
> Otherwise, Anna, would you want to "own" the patch ?

Rebased on 8e1fae193864527c931a704bd7908e4fbc983f5c.

Would someone step up to "own" this patch ?

If not, its CF entry may need to be closed (there's no status for "needs
author").

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "kuroda.hayato@fujitsu.com"
Дата:
Сообщение: RE: Allow escape in application_name
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side