Re: POC: Cleaning up orphaned files using undo logs

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: POC: Cleaning up orphaned files using undo logs
Date: 2019-05-03 04:45:59
Message-ID: CAFiTN-va0JWdNMCW4x-MnSRYVp4-tsFmMSmu83wRFRCdLkG-Ew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 2, 2019 at 7:00 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, May 2, 2019 at 5:32 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > Yeah, at least in this patch it looks silly. Actually, I added that
> > index to make the qsort stable when execute_undo_action sorts them in
> > block order. But, as part of this patch we don't have that processing
> > so either we can remove this structure completely as you suggested but
> > undo processing patch has to add that structure or we can just add
> > comment that why we added this index field.
>
> Well, the qsort comparator could compute the index as ptr - array_base
> just like any other code, couldn't it?
>
I might be completely missing but (ptr - array_base) is only valid
when first time you get the array, but qsort will swap the element
around and after that you will never be able to make out which element
was at lower index and which one was at higher index. Basically, our
goal is to preserve the order of the undo record for the same block
but their order might get changed due to swap when they are getting
compared with the undo record pointer of the another block and once
the order is swap we will never know what was their initial positions?

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2019-05-03 06:12:48 Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Previous Message Tom Lane 2019-05-02 23:18:19 Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6