On Fri, Nov 3, 2017 at 5:57 PM, Alexander Korotkov <[email protected]> wrote: > On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
