On Wed, Nov 7, 2012 at 5:31 PM, Amit Kapila <amit.kap...@huawei.com> wrote:
> > > > -----Original Message----- > > From: Atri Sharma [mailto:atri.j...@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.kap...@huawei.com> wrote: > > > > >> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > > >> ow...@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. Atri -- Regards, Atri *l'apprenant*