Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts |
Дата | |
Msg-id | 3655.1405959656@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
|
Список | pgsql-bugs |
Andres Freund <andres@2ndquadrant.com> writes: > 1) How about adding a elog(WARNING, "relation %u has invalid freeze > limits", ...) to vac_update_datfrozenxid()? Otherwise it's a bit hard > to understand what's going on. I wouldn't want to invest too much effort > into the precision of the message, but some log bleat seems justified. I considered that but wasn't really convinced it was a good idea. You'd be getting a lot of log spam on a 9.3 installation that had been affected by the pg_upgrade bug, until all the tables got cleaned up (and we're intentionally not forcing that to happen quickly). Anybody else have an opinion? > 2) From a pedantic POV lastSane* should be initialized to > ReadNewTransactionId()/ReadNextMultiXactId(). On a busy system we could > otherwise consider concurrently updated values as being too new if some > longrunning transaction finishes. Also GetOldestXmin() can sometimes go > backwards... If it's wrong then that's a pre-existing bug, but I don't think it's wrong. regards, tom lane
В списке pgsql-bugs по дате отправления: