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 1hiFmP-00027m-S5 for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jul 2019 10:12:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hiFmO-00041Z-9x for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jul 2019 10:12:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hiFmN-0003zj-Tw for pgsql-hackers@lists.postgresql.org; Tue, 02 Jul 2019 10:12:52 +0000 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hiFmF-0002KH-GM for pgsql-hackers@lists.postgresql.org; Tue, 02 Jul 2019 10:12:51 +0000 Received: by mail-wm1-x343.google.com with SMTP id s15so326361wmj.3 for ; Tue, 02 Jul 2019 03:12:43 -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:references:mime-version :content-disposition:in-reply-to:user-agent; bh=733gPagSQ2E6CYlmXR+Yt/Yc3L5FavgzKZM/AitPJGA=; b=R9rvS/R95CscCakPj2gsjuiBGEDM3ef6Lb7UpUtvDsduXoD0WBV4QglvMGJxCdW2MB dkADJ2eLOQ4LDF0lFYUIA1fRhsEGyjZjM+7cxligIMofJ59JowTxLipiMpI0FkSqHFys sNVCBpb+Bugh57cqJIcasLT6cDNWxeL8nhhvqgYICOHUTfqo+adUj/uq9xh+W310OJVZ jltMKXRILdWtfPoy1aqJUNQOW8AXqK44btuqvisaAnq2dknug4StVqbSGMDSX80KC19J 11R9Ao453w2dm7hw4dK8/YTv2G27tbCzZMjacu5QAUFoJ76cPAfduSe3hgI5fhVJeE83 iHjg== 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=733gPagSQ2E6CYlmXR+Yt/Yc3L5FavgzKZM/AitPJGA=; b=p3vqlNgCdDGoFMoVGj3KZIGUrTImBeoXHUju3ZbUUTJaWxiZ9toAbuW1Xk/Y7sGTOK NoFsKP9KoSkRPPQFd+nkUwq4YOoxmo5r5HrLz6Dcgp78bVFp2SC3RujHyyh7qRPWfRAZ f0MYEqF7OM4dA62F6cV6LTISVWJ/GkH9b2oLe/G4Vo1HLPwCZKc4bTE3cvxqErZHhpNG YirUjzazL3XlUFWuVgMi192W2BYx0EBkSm8cD7AbCM4LuEjBas5lwaEH2NGtM5cNZ1my udZewZnKKMWYhrpVz5/S2dUWBnpyTEGdsFylC9usvCfmAyyhgEERy7n3mJl1zc7YvWWB lW8w== X-Gm-Message-State: APjAAAUOrJF2Sr2OtyOkgm+AKqB+2uz906U6VL528jv2JPf9D3FjsPY3 Y+9+zeqRLmFthk+i9dvwjAfSsw== X-Google-Smtp-Source: APXvYqxNO/NrGOa7NZqSBoO/98NFoEqQCp0UaWkBH4yVnlpOULAvaVuEMybjUJB85WdMuwx2/WF16w== X-Received: by 2002:a1c:cf0b:: with SMTP id f11mr3038747wmg.138.1562062362803; Tue, 02 Jul 2019 03:12:42 -0700 (PDT) Received: from localhost (host86-187-167-41.range86-187.btcentralplus.com. [86.187.167.41]) by smtp.gmail.com with ESMTPSA id e7sm14067660wrt.94.2019.07.02.03.12.42 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 02 Jul 2019 03:12:42 -0700 (PDT) Date: Tue, 2 Jul 2019 12:12:40 +0200 From: Tomas Vondra To: Julien Rouhaud Cc: PostgreSQL Hackers , Kevin Grittner , Michael Paquier Subject: Re: Add parallelism and glibc dependent only options to reindexdb Message-ID: <20190702101240.dipk7wphmsoitlw3@development> References: <20190702082804.e7qgfncsyvxpcgra@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-1444-295967-dirty List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Jul 02, 2019 at 10:45:44AM +0200, Julien Rouhaud wrote: >On Tue, Jul 2, 2019 at 10:28 AM Tomas Vondra > wrote: >> >> I wonder why this is necessary: >> >> pg_log_error("cannot reindex glibc dependent objects and a subset of objects"); >> >> What's the reasoning behind that? It seems like a valid use case to me - >> imagine you have a bug database, but only a couple of tables are used by >> the application regularly (the rest may be archive tables, for example). >> Why not to allow rebuilding glibc-dependent indexes on the used tables, so >> that the database can be opened for users sooner. > >It just seemed wrong to me to allow a partial processing for something >that's aimed to prevent corruption. I'd think that if users are >knowledgeable enough to only reindex a subset of indexes/tables in >such cases, they can also discard indexes that don't get affected by a >collation lib upgrade. I'm not strongly opposed to supporting if >though, as there indeed can be valid use cases. > I don't know, it just seems like an unnecessary limitation. >> BTW now that we allow rebuilding only some of the indexes, it'd be great >> to have a dry-run mode, were we just print which indexes will be rebuilt >> without actually rebuilding them. > >+1. If we end up doing the filter in the backend, we'd have to add >such option in the REINDEX command, and actually issue all the orders >to retrieve the list. Hmmm, yeah. FWIW I'm not requesting v0 to have that feature, but it'd be good to design the feature in a way that allows adding it later. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services