| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Ivan Kartyshov <i(dot)kartyshov(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WIP: long transactions on hot standby feedback replica / proof of concept |
| Date: | 2017-11-02 02:56:57 |
| Message-ID: | CA+Tgmob7FL+ij8QVUya3ZA=q0VdQXf1oymGExyMeNRhPadAivQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2017-11-02 02:58:33 | Re: MERGE SQL Statement for PG11 |
| Previous Message | Craig Ringer | 2017-11-02 02:43:07 | Re: Statement-level rollback |