Tom Lane wrote:
>
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> >> That'll be true in any case, unless we refuse to start up at all upon
> >> detecting xlog corruption (which doesn't seem like the way to fly).
> >> Not sure what we can do about that.
>
> > What I would refuse in the event of
"Mikheev, Vadim" wrote:
>
> > >> What I was thinking about in that last paragraph was manual
> > >> analysis and recovery. I don't think it's a good idea for automatic
> > >> system startup to skip over gaps in the log.
> >
> > > But if we'll not try to read after gap then after restart
> > > syst
Maybe there should be an error message like :
"PostgreSQL has detected severe xlog corruption. Please fix this with
pg_recover (or similar) manually before restarting the database"?
Guess I'm suggesting a separate xlog recovery tool for "bad cases" of
xlog corruption, so decisions can by manual
> > It will be sufficient if DB will not use all 2^32 XIDs
> > without shutdown.
>
> I liked the xid wraparound idea, won't that be sufficient here too ?
> I don't like the idea to reuse a xid sooner than absolutely necessary.
We need it to reduce pg_log size requirements.
> This would complic
> > StartUpID counts database startups and so has timestamp characteristics.
> > Actually, idea is to use SUI in future to allow reusing XIDs after startup: seeing
> > old SUI in data pages we'll know that all transaction on this page was committed
> > "long ago" (ie visible from MVCC POV). This r
> > Anyway I like idea of StartUpID in page headers - this will help
>
> Can you please describe StartUpID for me ?
> Ideal would be a stamp that has the last (smallest open) XID, or something else
> that has more or less timestamp characteristics (without the actual need of
>wallclock)
> in r
