On Wed, Aug 7, 2019 at 6:56 AM vignesh C <vignes...@gmail.com> wrote: > Going by the discussion shall we conclude that we don't need to > convert the subxids into fxid's as part of this fix. > Let me know if any further changes need to be done.
I'm not sure, but I think the prior question is whether we want this patch at all, and I'm not sure we've achieved consensus on that. Thomas's point, at least as I understand it, is that if we start doing 32-bit => 64-bit XID conversions all over the place, it's not going to be long before some incautious developer inserts one that is not actually safe. On the other hand, Andres's point, at least as I understand it, is that putting information that we don't really need into the twophase state file because of some overly rigid coding rule is not smart. Both of those arguments sound right to me, but they lead to opposite conclusions. I am somewhat inclined to Andres's conclusion on balance. I think that we can probably define a set of policies about 32 => 64 bit XID conversions both in terms of when you can do them and what comments you have to include justifying them and how the API actually works that makes it safe. It might help to think about defining the API in terms of a reference FullTransactionId that must be OLDER than the XID you're promoting to an FXID. For instance, we know that all of the relfrozenxid and datfrozenxids are from the current era because we've got freezing machinery to enforce that. So if you got a tuple from the heap, it's XID has got to be new, at least modulo bugs. In other cases, we may be able to say, hey, look, this XID can't be from before the CLOG cutoff. I'm not sure of all the details here, but I'm tentatively inclined to think that trying to lay down policies for when promotion can be done safely is more promising than holding our breath and saying we're never going to promote. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
