Re: new heapcheck contrib module
От | Robert Haas |
---|---|
Тема | Re: new heapcheck contrib module |
Дата | |
Msg-id | CA+Tgmoa0o8SRhnAPiSRUGpOXrbreUngP9CT1HqhytH6m9VFJeA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: new heapcheck contrib module (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: new heapcheck contrib module
|
Список | pgsql-hackers |
On Thu, Jul 30, 2020 at 4:18 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > > Maybe I'm just being dense here -- exactly what problem are you worried about? > > Per tuple, tuple_is_visible() potentially checks whether the xmin or xmax committed via TransactionIdDidCommit. I am worriedabout concurrent truncation of clog entries causing I/O errors on SLRU lookup when performing that check. The threestrategies I had for dealing with that were taking the XactTruncationLock (formerly known as CLogTruncationLock, forthose reading this thread from the beginning), locking out vacuum, and the idea upthread from Andres about setting PROC_IN_VACUUMand such. Maybe I'm being dense and don't need to worry about this. But I haven't convinced myself of that,yet. I don't get it. If you've already checked that the XIDs are >= relfrozenxid and <= ReadNewFullTransactionId(), then this shouldn't be a problem. It could be, if CLOG is hosed, which is possible, because if the table is corrupted, why shouldn't CLOG also be corrupted? But I'm not sure that's what your concern is here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: