On Tue, Oct 31, 2017 at 2:47 PM, Alexander Korotkov <a.korotkov@postgrespro.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.
