Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept |
Дата | |
Msg-id | CA+TgmoY1=GVNO1Ffe6o7sM8jkg7123ngwkvu52QsaZxxThkZtw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Список | pgsql-hackers |
On Fri, Nov 3, 2017 at 5:57 PM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote: > On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> > 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. Ah - I was thinking of the TRUNCATE command, rather than truncation by VACUUM. Your argument makes sense, although the case where the relation is truncated and later re-extended might need some thought. -- 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 по дате отправления: