Re: WIP: long transactions on hot standby feedback replica / proof of concept

On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Oct 31, 2017 at 2:47 PM, Alexander Korotkov
> <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> > However, from user prospective of view, current behavior of
> > hot_standby_feedback is just broken, because it both increases bloat and
> > doesn't guarantee that read-only query on standby wouldn't be cancelled
> > because of vacuum. Therefore, we should be looking for solution: if one
> > approach isn't good enough, then we should look for another approach.
> >
> > I can propose following alternative approach: teach read-only queries on
> hot
> > standby to tolerate concurrent relation truncation. Therefore, when
> > non-existent heap page is accessed on hot standby, we can know that it
> was
> > deleted by concurrent truncation and should be assumed to be empty. Any
> > thoughts?
>
> Sounds like it might break MVCC?

I don't know why it might be broken. VACUUM truncates heap only when tail
to be truncated is already empty. When applying truncate WAL record,
previous WAL records deleting all those tuples in the tail are already
applied. Thus, if even MVCC is broken and we will miss some tuples after
heap truncation, they were anyway were gone before heap truncation.

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