Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iBM6X-0000r1-55 for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Sep 2019 16:49:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iBM6V-00009V-Eo for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Sep 2019 16:49:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iBM6U-000098-VL for pgsql-hackers@lists.postgresql.org; Fri, 20 Sep 2019 16:49:55 +0000 Received: from mail-qt1-x843.google.com ([2607:f8b0:4864:20::843]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iBM6R-000404-W1 for pgsql-hackers@postgresql.org; Fri, 20 Sep 2019 16:49:53 +0000 Received: by mail-qt1-x843.google.com with SMTP id j31so9421240qta.5 for ; Fri, 20 Sep 2019 09:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=dDbRVSMKIEVhVIrRTCARJo9Z0bS7YDctac0UkX1OQKU=; b=VmHW+6eexG2gd/GoifBX8vyBx8kVn5x1eIFMrgOtLLieTagUELgSMMSWepshewE19v Tz0EVmPt4hxnSaopf5DqSwKqPF2FZkDuk+QluKZuf+ulwSLGNAm0QD5bSBTn2QnwAcdA 8Jzt0v4uRCh5XxWHydGvzmDtPnpkAgSja0BqZyel0Tgfzozvr4sqmQwiOQPIGyp4btCu GQPwys9/53GGwJkfNYptsPy8V/bv1qGEy3btFlyPU38IdBWy82tcmsAyMh+B+s31dMd6 8JI/jMrQic4U16EhIZyHzia9p9ptX2cMiXuFGve3TWjn1JOu563ymrj7fIy010Niknz6 PSVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=dDbRVSMKIEVhVIrRTCARJo9Z0bS7YDctac0UkX1OQKU=; b=m54ObeECoVx8QhM/eBDyBYBb3Ws1NCdqAD90/1cArEB2TLM9CnBUXIwImYHvwSDDXa b5oyBeopARQYsOsbNYOu0dtgbLw/dv16N0zsSpHMQGUoRMOSAkjQXjefhjLAEjMcWgCN cQMrP8Df0On2jZeJE2KqZ9xdUVpbdFLxLoHSeGKWjpbHIaWFuaIz9/I/R6rZxRSpSG69 T8of1WsSAoB7vosvvmlTu38q4t5asILwGZWogr5CmjJLF6DxcCtLI/0QQUnR9PWdGbCI cMv/fOl2A+zCU3kgWvfVDFZB1MuDbw6IgF+9YsrL2gNx3xLkiaVI1s+w+NoESjZuVUOG HuIw== X-Gm-Message-State: APjAAAXh0YZWVUkDN2oHdMuWA60KoU1oeo6yGk9aMn3zAYYc2M5z+L57 q67KzhzrsGlXSZnBmJiL1RR4eg== X-Google-Smtp-Source: APXvYqyqZ5T/qLnV8Tz0mDSlA4JsWZFXIkgga1yflDpvjfsR2cInTZrK+GAWw4um54okOcxih33v1w== X-Received: by 2002:aed:2806:: with SMTP id r6mr4273520qtd.206.1568998191100; Fri, 20 Sep 2019 09:49:51 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([179.56.51.60]) by smtp.gmail.com with ESMTPSA id z5sm1110038qkl.101.2019.09.20.09.49.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Sep 2019 09:49:49 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 41CC41207A3; Fri, 20 Sep 2019 13:49:47 -0300 (-03) Date: Fri, 20 Sep 2019 13:49:47 -0300 From: Alvaro Herrera To: Michael Paquier Cc: Robert Haas , Masahiko Sawada , Tatsuro Yamada , Rafia Sabih , Dmitry Dolgov <9erthalion6@gmail.com>, Peter Geoghegan , PostgreSQL-development , Jeff Janes , Thomas Munro , Michael Paquier , Peter Eisentraut Subject: Re: [HACKERS] CLUSTER command progress monitor Message-ID: <20190920164947.GA19171@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190918021031.GK8909@paquier.xyz> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Sep-18, Michael Paquier wrote: > On Tue, Sep 17, 2019 at 10:50:22PM -0300, Alvaro Herrera wrote: > > On 2019-Sep-18, Michael Paquier wrote: > >> So, with the clock ticking and the release getting close by, what do > >> we do for this set of issues? REINDEX, CREATE INDEX and CLUSTER all > >> try to build indexes and the current infrastructure is not really > >> adapted to hold all that. Robert, Alvaro and Peter E, do you have any > >> comments to offer? > > > > Which part of it is not already fixed? > > I can still see at least two problems. There is one issue with > pgstat_progress_update_param() which gets called in reindex_table() > for a progress phase of CLUSTER, and this even if > REINDEXOPT_REPORT_PROGRESS is not set in the options. (You mean reindex_relation.) ... but that param update is there for CLUSTER, not for REINDEX, so if we made it dependent on the option to turn on CREATE INDEX progress updates, it would break CLUSTER progress reporting. Also, the parameter being updated is not used by CREATE INDEX, so there's no spurious change. I think this ain't broke, and thus it don't need fixin'. If anything, I would like the CLUSTER report to show index creation progress, which would go the opposite way. But that seems a patch for pg13. > Also it seems > to me that the calls to pgstat_progress_start_command() and > pgstat_progress_end_command() are at incorrect locations for > reindex_index() and that those should be one level higher on the stack > to avoid any kind of interactions with another command whose progress > has already started. That doesn't work, because the caller doesn't have the OID of the table, which pgstat_progress_start_command() needs. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services