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

From Robert Haas
Subject Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
Date
Msg-id CA+Tgmob7FL+ij8QVUya3ZA=q0VdQXf1oymGExyMeNRhPadAivQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
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?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] Statement-level rollback
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] MERGE SQL Statement for PG11