RE: reloption to prevent VACUUM from truncating empty pages at theend of relation

Поиск
Список
Период
Сортировка
От Jamison, Kirk
Тема RE: reloption to prevent VACUUM from truncating empty pages at theend of relation
Дата
Msg-id D09B13F772D2274BB348A310EE3027C6410F1B@g01jpexmbkw24
обсуждение исходный текст
Ответ на Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы RE: reloption to prevent VACUUM from truncating empty pages at theend of relation  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Список pgsql-hackers
>On Thu, Nov 15, 2018 at 2:30 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>>
>> On 2018-Nov-15, Laurenz Albe wrote:
>>
> > > This new option would not only mitigate the long shared_buffers 
> > > scan, it would also get rid of the replication conflict caused by 
> > > the AccessExclusiveLock taken during truncation, which is discussed 
> > > in 
> > > https://www.postgresql.org/message-id/c9374921e50a5e8fb1ecf04eb8c6eb
> > > c3%40postgrespro.ru and seems to be a more difficult problem than 
> > > anticipated.
> >
> > FWIW I was just reminded yesterday that the AEL-for-truncation has 
> > been diagnosed to be a severe problem in production, and with no other 
> > solution in sight, I propose to move forward with the stop-gap.

I just want to ask whether or not we could proceed with this approach for now and 
if it is possible that we could have this solution integrated before PG12 development ends?

Regards,
Kirk Jamison

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

Предыдущее
От: Erik Rijkers
Дата:
Сообщение: Re: [HACKERS] generated columns
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name