Re: Add parallelism and glibc dependent only options to reindexdb

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kevin Grittner <kgrittn(at)gmail(dot)com>
Subject: Re: Add parallelism and glibc dependent only options to reindexdb
Date: 2019-07-17 17:46:10
Message-ID: CAOBaU_YdAfbrZD7hYX05YVz_OeOexweS6LFip8PZfqOQBwe8XQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 17, 2019 at 9:59 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Jul 16, 2019 at 02:03:16PM +0200, Julien Rouhaud wrote:
> > After more thinking about schema and multiple jobs, I think that
> > erroring out is quite user unfriendly, as it's entirely ok to ask
> > for
> > multiple indexes and multiple object that do support parallelism in
> > a
> > single call. So I think it's better to remove the error, ignore the
> > given --jobs options for indexes and document this behavior.
>
> No objections to that. I still need to study a bit more 0002 though
> to come to a clear conclusion.
>
> Actually, from patch 0002:
> + free_slot = ParallelSlotsGetIdle(slots, concurrentCons, progname);
> + if (!free_slot)
> + {
> + failed = true;
> + goto finish;
> + }
> +
> + run_reindex_command(conn, process_type, objname, progname, echo,
> + verbose, concurrently, true);
> The same connection gets reused, shouldn't the connection come from
> the free slot?

Ouch indeed.

> On top of that quick lookup, I have done an in-depth review on 0001 to
> bring it to a committable state, fixing a couple of typos, incorrect
> comments (description of ParallelSlotsGetIdle was for example
> incorrect) on the way. Other things include that connectDatabase
> should have an assertion for a non-NULL connection,

disconnectDatabase you mean? Fine by me.

> calling pg_free()
> on the slots terminate is more consistent as pg_malloc is used first.
> A comment at the top of processQueryResult still referred to
> vacuuming of a missing relation. Most of the patch was in a clean
> state, with a clear interface for parallel slots, the place of the new
> routines also makes sense, so I did not have much to do :)

Thanks :)

> Another thing I have noticed is that we don't really need to pass down
> progname across all those layers as we finish by using pg_log_error()
> when processing results, so more simplifications can be done. Let's
> handle all that in the same patch as we are messing with the area.
> connectDatabase() and connectMaintenanceDatabase() still need it
> though as this is used in the connection string, so
> ParallelSlotsSetup() also needs it. This part is not really your
> fault but as I am looking at it, it does not hurt to clean up what we
> can. Attached is an updated version of 0001 that I am comfortable
> with. I'd like to commit that with the cleanups included and then
> let's move to the real deal with 0002.

Good catch, I totally missed this progname change. I read the patch
you attached, I have a few comments:

+/*
+ * Disconnect the given connection, canceling any statement if one is active.
+ */
+void
+disconnectDatabase(PGconn *conn)

Nitpicking, but this comment doesn't follow the style of other
functions' comments (it's also the case for existing comment on
executeQuery at least).

While reading the comments you added on ParallelSlotsSetup(), I
wondered if we couldn't also add an Assert(conn) at the beginning?

+void
+ParallelSlotsTerminate(ParallelSlot *slots, int numslots)
+{
+ int i;
+
+ for (i = 0; i < numslots; i++)
+ {
+ PGconn *conn = slots[i].connection;
+
+ if (conn == NULL)
+ continue;
+
+ disconnectDatabase(conn);
+ }
+
+ pg_free(slots);
+}

Is it ok to call pg_free(slots) and let caller have a pointer pointing
to freed memory?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-07-17 17:56:27 Re: Change ereport level for QueuePartitionConstraintValidation
Previous Message Andres Freund 2019-07-17 17:33:02 Re: buildfarm's typedefs list has gone completely nutso