> -----Original Message----- > From: Atri Sharma [mailto:atri.jiit@gmail.com] > Sent: Wednesday, November 07, 2012 4:02 PM > To: Amit Kapila > Cc: Merlin Moncure; PostgreSQL-development > Subject: Re: [HACKERS] WIP patch for hint bit i/o mitigation > > On 07-Nov-2012, at 15:46, Amit Kapila <amit.kapila@huawei.com> wrote: > > >> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- > >> owner@postgresql.org] On Behalf Of Merlin Moncure > >> Sent: Wednesday, November 07, 2012 5:26 AM > >> To: PostgreSQL-development > >> Cc: Atri Sharma > >> Subject: [HACKERS] WIP patch for hint bit i/o mitigation > >> > >> 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.
With Regards, Amit Kapila.
AFAIK, xid are managed by reference xids, that have a range of +- 2 billion xids. Once this limit is reached, then reference xids are moved forward, and the xids that do not fall in the reference xid +- 2 billion are freezed.Hence, in the given scenario, I believe once the wrap around happens, since the xmin is same for all the tuples in session-1's table, there should no be no problem and all tuple's xid for that particular table will be frozen.
