Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
От | Tom Lane |
---|---|
Тема | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin |
Дата | |
Msg-id | 932345.1721687794@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
|
Список | pgsql-hackers |
Melanie Plageman <melanieplageman@gmail.com> writes: > We've only run tests with this commit on some of the back branches for > some of these animals. Of those, I don't see any failures so far. So, > it seems the test instability is just related to trying to get > multiple passes of index vacuuming reliably with TIDStore. > AFAICT, all the 32bit machine failures are timeouts waiting for the > standby to catch up (mamba, gull, merswine). Unfortunately, the > failures on copperhead (a 64 bit machine) are because we don't > actually succeed in triggering a second vacuum pass. This would not be > fixed by a longer timeout. Ouch. This seems to me to raise the importance of getting a better way to test multiple-index-vacuum-passes. Peter argued upthread that we don't need a better way, but I don't see how that argument holds water if copperhead was not reaching it despite being 64-bit. (Did you figure out exactly why it doesn't reach the code?) > Because of this, I'm inclined to revert the test on 17 and master to > avoid distracting folks committing other work and seeing those animals > go red. Agreed as a short-term measure. regards, tom lane
В списке pgsql-hackers по дате отправления: