Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGYw3-0001Tc-2D for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Nov 2017 23:23:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGYw2-0002Ch-CD for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Nov 2017 23:23:34 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eGYw2-0002CX-70 for pgsql-hackers@lists.postgresql.org; Sun, 19 Nov 2017 23:23:34 +0000 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eGYvy-0007Ex-L5 for pgsql-hackers@postgresql.org; Sun, 19 Nov 2017 23:23:33 +0000 Received: by mail-wm0-x229.google.com with SMTP id 9so15440056wme.4 for ; Sun, 19 Nov 2017 15:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PiHAPxa6ehNqQ6zre6g5F/pM3q2wyPlYG1g9HvXM2ZY=; b=CUtgNUN6sELeO4bwl7Xta+ljMCETIOLNvYNRcoxkyqkELDkFhYmR5RSG9ht88gZFtr +tmbbyUyUjiuwEnWCQYDzCGuInBwtNLiR5C/07A9sir7RCA53vzAMzM8Dzv2EoHYjzOR GYCB4wRpbhAvPl3Gsa6fIcubt2fEljAAhgN/k+Ukn5TecsUKdsZFlMmvZRjH2AlK/KzJ 8u+HP1yAtzvpiPhlNC0zmSytcxEhckc0EYF6Hpsunnu8pVuL4zHE2PaR/Rnp+sbXOZK4 PKhU9wUIIqHHrGyMggseIEtUCAXbBx6XL41sCurQslgqgwIBz1WBL3eWeVGMrUT1jnjJ izYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PiHAPxa6ehNqQ6zre6g5F/pM3q2wyPlYG1g9HvXM2ZY=; b=lhLatR5PK1GWjina5VEEdpsd7PlDM2wnZgkO33iTCGiw/ilJTybtgmhHqhxLsU8hcY tR4ol/3se7cdmIvW0WLxUAbPbB7GlnzgNYByG0bzwwCIZneo5T2vaTbGHZBpRjqTzsWr 3Pt+8ejmRZuGrbqV9qylhWiUT6mEZBwrtPpeIv3PqMfX8k1Y5aSfnzBgyj5xjIULl9eD 4FXq/s0sCLdrjApbShjMFo7jI2cKJUpAiTuly9B1WiwPSpa56cBHmjoblFG0SQ85iYgB Du4a5p92ny/3rXO2DF2zNJEGmZ6PqJl+6ScYcHTDybA/K1kXXXVodAPxj0mc9Qo9pG2Z r+pg== X-Gm-Message-State: AJaThX748U3w4yQ+RqSzL3xDdUT9VfUNqtivd66srsrYMVoxkNVUp74E PAWRcP1WSKEtid/oXEGL8nto5g== X-Google-Smtp-Source: AGs4zMb0ZdcBT/c2Slj/wCf4M4GrqO+SiQjYE8vOloteu8FILyOmO1lPCbPPd44pQcMw+1E54DH0WA== X-Received: by 10.28.198.139 with SMTP id w133mr7982757wmf.13.1511133808448; Sun, 19 Nov 2017 15:23:28 -0800 (PST) Received: from [10.137.2.19] (ip-78-102-97-226.net.upcbroadband.cz. [78.102.97.226]) by smtp.gmail.com with ESMTPSA id c54sm16078952wra.84.2017.11.19.15.23.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2017 15:23:27 -0800 (PST) Subject: Re: [HACKERS] Custom compression methods To: Robert Haas , Ildus Kurbangaliev Cc: Oleg Bartunov , Craig Ringer , Peter Eisentraut , PostgreSQL Hackers , Andres Freund References: <20170907194236.4cefce96@wp.localdomain> <20170912175505.4afa11fd@wp.localdomain> <5c84382f-1065-e9e8-dde8-4c1f5ae1007b@2ndquadrant.com> <20171102124101.5a28ecab@wp.localdomain> <20171115120928.31bee414@wp.localdomain> From: Tomas Vondra Message-ID: Date: Mon, 20 Nov 2017 00:23:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 11/15/2017 02:13 PM, Robert Haas wrote: > On Wed, Nov 15, 2017 at 4:09 AM, Ildus Kurbangaliev > wrote: >> So in the next version of the patch I can just unlink the options from >> compression methods and dropping compression method will not affect >> already compressed tuples. They still could be decompressed. > > I guess I don't understand how that can work. I mean, if somebody > removes a compression method - i.e. uninstalls the library - and you > don't have a way to make sure there are no tuples that can only be > uncompressed by that library - then you've broken the database. > Ideally, there should be a way to add a new compression method via an > extension ... and then get rid of it and all dependencies thereupon. > I share your confusion. Once you do DROP COMPRESSION METHOD, there must be no remaining data compressed with it. But that's what the patch is doing already - it enforces this using dependencies, as usual. Ildus, can you explain what you meant? How could the data still be decompressed after DROP COMPRESSION METHOD, and possibly after removing the .so library? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services