Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cj4RC-0006PN-6p for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Mar 2017 13:37:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cj4RB-0007Ju-GP for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Mar 2017 13:37:01 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cj4R9-0007Ei-Vx for pgsql-hackers@postgresql.org; Wed, 01 Mar 2017 13:37:00 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cj4R7-0004mY-P0 for pgsql-hackers@postgresql.org; Wed, 01 Mar 2017 13:36:58 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1DD96208AB; Wed, 1 Mar 2017 08:36:56 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 01 Mar 2017 08:36:56 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=RMV3Xa5Lxqz6gcKgWDNhcHQQrGk=; b=qD3m1DyvQIubAgRoGIfP 9IV+Hmus2zcBDIJGWSEyeE+9NjExFWGRuzM9mBR4f04j4OZCpARaIR2UBfWvgxt1 rwhTLzcHqsgIQ+sYh5Gj6v5atWyH3PrjhAV0FSGUWk2ZPC4GBTUekBI9OjbRQIa9 PTfu3MHl2z/gMlyRn9dF96E= X-ME-Sender: X-Sasl-enc: hFDRLvDC+pbK3aPAM4/3AmOT61VC1OjQAobUHde/gnTL 1488375415 Received: from april.local (c-73-13-66-39.hsd1.pa.comcast.net [73.13.66.39]) by mail.messagingengine.com (Postfix) with ESMTPA id E6EB27E050; Wed, 1 Mar 2017 08:36:55 -0500 (EST) Subject: Re: Change in "policy" on dump ordering? To: Jim Nasby , Pg Hackers References: <87866740-ef55-8a6d-6480-499b92aa23c0@BlueTreble.com> <8f64786e-824d-7c0d-33a6-3d9e1c8e9fde@2ndquadrant.com> <33b25c65-94f1-6ff6-c717-61a56294a255@2ndquadrant.com> <75409fb1-bd96-25c2-f6b0-c24e28ed2684@2ndquadrant.com> <65049c27-96bf-317b-b435-931f6041f94c@BlueTreble.com> From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <67d35333-ef65-074a-b2be-52440f245e43@2ndquadrant.com> Date: Wed, 1 Mar 2017 08:36:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <65049c27-96bf-317b-b435-931f6041f94c@BlueTreble.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2/22/17 18:24, Jim Nasby wrote: > On 2/22/17 12:29 PM, Peter Eisentraut wrote: >> On 2/22/17 10:14, Jim Nasby wrote: >>> CREATE MATERIALIZED VIEW tmv AS SELECT * FROM pg_subscription; >>> SELECT 0 >>> >>> IOW, you can create matviews that depend on any other >>> table/view/matview, but right now if the matview includes certain items >>> it will mysteriously end up empty post-restore. >> >> Yes, by that logic matview refresh should always be last. > > Patches for head attached. > > RLS was the first item added after DO_REFRESH_MATVIEW, which was added > in 9.5. So if we want to treat this as a bug, they'd need to be patched > as well, which is a simple matter of swapping 33 and 34. I wonder whether we should emphasize this change by assigning DO_REFRESH_MATVIEW a higher number, like 100? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers