Horton

Thread

Commits

  1. Avoid useless allocations for information of dumpable objects in pg_dump/

  1. Avoid incorrect allocation in buildIndexArray

    Daniel Gustafsson <daniel@yesql.se> — 2020-09-11T11:38:29Z

    Looking at a pg_dump patch I realized that when we call buildIndexArray without
having found objects to index, we still call pg_malloc with zero which in turn
mallocs 1 byte.  The byte in question is of course negligable, but it does seem
cleaner to return early with NULL instead of returning an empty allocation
which doesn't actually contain an index.

Any reason not to bail early as per the attached?

cheers ./daniel

  2. Re: Avoid incorrect allocation in buildIndexArray

    Julien Rouhaud <rjuju123@gmail.com> — 2020-09-11T11:49:26Z

    On Fri, Sep 11, 2020 at 1:39 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>
> Looking at a pg_dump patch I realized that when we call buildIndexArray without
> having found objects to index, we still call pg_malloc with zero which in turn
> mallocs 1 byte.  The byte in question is of course negligable, but it does seem
> cleaner to return early with NULL instead of returning an empty allocation
> which doesn't actually contain an index.
>
> Any reason not to bail early as per the attached?

+1

  3. Re: Avoid incorrect allocation in buildIndexArray

    Michael Paquier <michael@paquier.xyz> — 2020-09-12T09:13:56Z

    On Fri, Sep 11, 2020 at 01:49:26PM +0200, Julien Rouhaud wrote:
> On Fri, Sep 11, 2020 at 1:39 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>> Any reason not to bail early as per the attached?
> 
> +1

Makes sense to me.  This has also the advantage to cause a crash if
there is an attempt to refer to those empty arrays in case of future
refactoring, which is rather defensive.  By looking at
findObjectByOid(), I can also see that we check for a negative number,
so I concur with Ranier's comment to check after that on top of 0.
If there are no objections, I'll apply that on HEAD.
--
Michael

  4. Re: Avoid incorrect allocation in buildIndexArray

    Julien Rouhaud <rjuju123@gmail.com> — 2020-09-12T10:40:49Z

    Le sam. 12 sept. 2020 à 11:14, Michael Paquier <michael@paquier.xyz> a
écrit :

> On Fri, Sep 11, 2020 at 01:49:26PM +0200, Julien Rouhaud wrote:
> > On Fri, Sep 11, 2020 at 1:39 PM Daniel Gustafsson <daniel@yesql.se>
> wrote:
> >> Any reason not to bail early as per the attached?
> >
> > +1
>
> Makes sense to me.  This has also the advantage to cause a crash if
> there is an attempt to refer to those empty arrays in case of future
> refactoring, which is rather defensive.  By looking at
> findObjectByOid(), I can also see that we check for a negative number,
>

yes, I also checked that current code is already checking for that.

so I concur with Ranier's comment to check after that on top of 0.
> If there are no objections, I'll apply that on HEAD.


agreed.

>

  5. Re: Avoid incorrect allocation in buildIndexArray

    Michael Paquier <michael@paquier.xyz> — 2020-09-14T01:45:49Z

    On Sat, Sep 12, 2020 at 12:40:49PM +0200, Julien Rouhaud wrote:
> agreed.

Ok, done as ac673a1 then.
--
Michael

  6. Re: Avoid incorrect allocation in buildIndexArray

    Ranier Vilela <ranier.vf@gmail.com> — 2020-09-14T11:49:38Z

    Em dom., 13 de set. de 2020 às 22:46, Michael Paquier <michael@paquier.xyz>
escreveu:

> On Sat, Sep 12, 2020 at 12:40:49PM +0200, Julien Rouhaud wrote:
> > agreed.
>
> Ok, done as ac673a1 then.
>
Thanks Michael.

regards,
Ranier Vilela