Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
От | Andres Freund |
---|---|
Тема | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |
Дата | |
Msg-id | 20220331042443.ax34p5r2fwgwup4n@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
Hi, On 2022-03-30 21:11:48 -0700, Peter Geoghegan wrote: > On Wed, Mar 30, 2022 at 9:04 PM Andres Freund <andres@anarazel.de> wrote: > > (gdb) p vacrel->NewRelfrozenXid > > $3 = 717 > > (gdb) p vacrel->relfrozenxid > > $4 = 717 > > (gdb) p OldestXmin > > $5 = 5112 > > (gdb) p aggressive > > $6 = false > > Does this OldestXmin seem reasonable at this point in execution, based > on context? Does it look too high? Something else? Reasonable: (gdb) p *ShmemVariableCache $1 = {nextOid = 78969, oidCount = 2951, nextXid = {value = 21411}, oldestXid = 714, xidVacLimit = 200000714, xidWarnLimit= 2107484361, xidStopLimit = 2144484361, xidWrapLimit = 2147484361, oldestXidDB = 1, oldestCommitTsXid = 0, newestCommitTsXid = 0, latestCompletedXid= {value = 21408}, xactCompletionCount = 1635, oldestClogXid = 714} I think the explanation I just sent explains the problem, without "in-memory" confusion about what's running and what's not. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: