Re: WIP patch for hint bit i/o mitigation

On Wed, Nov 7, 2012 at 5:31 PM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:

>
>
> > -----Original Message-----
> > From: Atri Sharma [mailto:atri(dot)jiit(at)gmail(dot)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(dot)kapila(at)huawei(dot)com> wrote:
> >
> > >> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> > >> owner(at)postgresql(dot)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*