On 2 October 2017 at 08:09, Robert Haas <robertmh...@gmail.com> wrote:
> On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik > <k.knizh...@postgrespro.ru> wrote: > > txid_status() also not always be able to return status of transaction > (if wraparound happen). > > But it is still considered as one of the key features of 10 (transaction > traceability...). > > Not by me. It's a feature, though, for sure. Same here. It's nice, and obviously I wanted it since I submitted it, but it's not a key feature by any stretch. Even if Pg also reported the xid to the client when assigned it'd still be a nice utility, not a huge headline feature. > It's also a LOT more > stable than what you're proposing. Even on a busy system, it takes a > while to go through 200 million transactions; you probably can't > realistically do that in under an hour, and you'll probably raise the > 200 million transaction limit if you're anywhere close to that rate. > In practice, you'll almost always be able to look up transactions for > several days, and often weeks or months. Not necessarily, since it doesn't hold down or delay clog truncation, so if the system is really eagerly VACUUMed it might discard things sooner. At the moment though we're quite lazy about clog truncation, mainly because we're very lazy about vacuuming template1 and template0 (which we should autofreeze, really) so they tend to hold down global datfrozenxid. If we get better about that, then we might need some way to ask Pg to keep extra clog. But for now it works well enough. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
