Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
| От | Kevin Grittner |
|---|---|
| Тема | Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1 |
| Дата | |
| Msg-id | 1384955998.30844.YahooMailNeo@web162905.mail.bf1.yahoo.com обсуждение исходный текст |
| Ответ на | Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1 (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: Data corruption issues using streaming replication on
9.0.14/9.2.5/9.3.1
|
| Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> wrote: > On 2013-11-20 05:30:39 -0800, Kevin Grittner wrote: >> Wouldn't a database VACUUM FREEZE fix it, with WAL-logged >> writing of everything that doesn't yet have hint bits set? > > Besides also being pretty expensive it still wouldn't correct the > clog - and we don't always rely on hint bits. I'm talking about after a fix is deployed, fixing up the possible corruption. Can you explain where VACUUM FREEZE would not suffice? I don't know of anywhere that we have hint bits set for a tuple and we go fetch the clog bits in spite of that. I don't understand where that would make sense; especially since I thought that a database FREEZE followed by a checkpoint releases old clog space anyway. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: