Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
Date
Msg-id CAPpHfduXBXLy1NwCrVL0Casr3Qc29_+AK7t33WT__w42U8+6Qw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
List pgsql-hackers
Hi!

On Tue, Aug 14, 2018 at 12:05 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Feb 28, 2018 at 11:24 PM, Ivan Kartyshov
> <i.kartyshov@postgrespro.ru> wrote:
> > The main goal of my changes is to let long read-only transactions run on
> > replica if hot_standby_feedback is turned on.
>
> FWIW the idea proposed on the thread[1], which allows us to disable
> the heap truncation by vacuum per tables, might help this issue. Since
> the original problem on that thread is a performance problem an
> alternative proposal would be better, but I think the way would be
> helpful for this issue too and is simple. A downside of that idea is
> that there is additional work for user to configure the reloption to
> each tables.

Thank you for pointing this thread.  It's possible to cope this
downside to introduce GUC which would serve as default, when reloption
is not defined.  But real downside is inability to truncate the heap.
So, options are good if they provide workaround for users, but that
shouldn't stop us from fixing issues around heap truncation.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] Bug in to_timestamp().
Next
From: Andres Freund
Date:
Subject: Re: C99 compliance for src/port/snprintf.c