Alvaro Herrera <alvherre@commandprompt.com> writes:
> My idea was to move relminxid to a new pg_class_nt non-transactional
> catalog in 8.3, but we certainly need to give a solution for the problem
> in 8.2.
Didn't we pretty much shoot down the idea of a nontransactional
extension catalog as being not worth the trouble?
> I don't remember why I concluded that we were safe against this
> problem, but you are right that we aren't.
I think there may be another set of issues here too: what about PITR?
As things stand, neither hint-bit settings nor FrozenXID replacement
are guaranteed to get propagated to a PITR slave.
We don't propagate CLOG truncation to a slave either, which means that
to some extent it'd have the ability to re-set hint bits for itself
after coming up. This isn't bulletproof though; most obviously in
the case where the PITR replay (or hot-slave lifespan) exceeded
4G transactions.
Can we fix it so it's sufficient to propagate FrozenXID replacement
to the slave? If we have to turn hint-bit setting into a logged
operation, that *will* be expensive.
regards, tom lane