On Wed, Nov 7, 2012 at 6:01 AM, Amit Kapila <amit.kap...@huawei.com> wrote: >> >> Following the sig is a first cut at a patch (written by Atri) that >> >> attempts to mitigate hint bit i/o penalty when many pages worth of >> >> tuples are sequentially written out with the same transaction id. >> >> There have been other attempts to deal with this problem that fit >> >> niche cases (especially those that create the table in the same >> >> transaction as the one inserting) that work but don't really solve >> the >> >> problem generally. >> >> As we are now dealing with only the last xid(please refer to the details >> of the patch attached), the invalidation issues are not significant any >> more. > > I think you are right, but please check below the scenario I have in mind > due to which I got confused: > > Session -1 > 1. let's say for tup-1 on page, cachedVisibilityXid is not set, and it go > inside SetHinbits and set it to xid of tuple which is let's say = 708 > 2. now for all consecutive tuples which have same xmin (708), it can > directly refer > cached id and cached status, even if hint bit is not set. > > Other Sessions > 3. now from other sessions, large operations happened on all other tables > except this table. > 4. The situation can reach where xid can wrap around. > > Session -1 > 5. It again tries to query the same table, at this point it will compare > the xid in tuple with cachedVisibilityXid. > > Now if all tuple's xid's for that particular table are frozen in all cases > then it seems to be okay, otherwise it might be problem. > I am not fully aware about this wrap around and frozed xid concept, thats > why I had doubted > that it might create problem, on further thought, it appears that I was > wrong.
Well there's that. But more to the point for the cache to fail you'd have to have a scenario where a table didn't scan any records for 1 billion+ transactions. See note [3] above for reasoning why this is implausible. Also we're already relying on this effect in transam.c. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
