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 1iSije-0002Bq-4m for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Nov 2019 14:26:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iSijc-0002s1-Uy for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Nov 2019 14:26:04 +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 1iSijc-0002ou-IR for pgsql-hackers@lists.postgresql.org; Thu, 07 Nov 2019 14:26:04 +0000 Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iSijW-0000gD-6O for pgsql-hackers@postgresql.org; Thu, 07 Nov 2019 14:26:04 +0000 Received: by mail-pf1-x42a.google.com with SMTP id p26so2763098pfq.8 for ; Thu, 07 Nov 2019 06:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yX99RcKjH0o/imW4LkiRcAV+lJr0JW66iMIkhe/ZCgc=; b=OB/K1zwxOOHxrwvot5CQcSzSGuGIATYn3QhsRNi1m4JEX8Gr6Xs1D2RD1u58Mfa3Um 7Yc8/StrCnP932xQqJ9PoyEj5MB0INsIawqWebtKmxc7KBGzn2d+WoOkP/DmOIIEhrUZ gBTVmC7HGXqHF7g3wBsqEJMpnYtYp4+4CDkWLVKeqF4lH19e5TZRUJS5bMuLHXScMlSK CB75j2i1W11s8vQhJQCPGEAbIDAPLNJd07BkI5ajxwtv0XgMIgWM1PMfD54mkd8kDPr0 9gCOOaZMMy7xHU+w4phIuvmMqhgSx3BrnZeY3x7QrnbXaQTDQvoimhuxzuiMR7bJlS5S i0oQ== 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=yX99RcKjH0o/imW4LkiRcAV+lJr0JW66iMIkhe/ZCgc=; b=P+XOGOo9vUbsrr2mtlA4QxBEHBveO7dWqBjYuFH/7+SKMeXpFbV724PRfPQChyuzIO m04c3HM5Qe2j68c3Cm0dLfg9XNhXMGb7fzo/LSt9QHr+yHxepeyv1Quxx8/ll2HHXQ5U yvyGxiS7n2rs/BmpkI9RAf4Sez6HzSONxSwW/LHcYG04LgNBDXFssF5FMhLeDStUglHP dW30I0jhLHJkHa+EcP3O19E7tVt2lW3gRJmobSnJh74ept+LoPPWFPMTzm/i+lzivoZB F70rm5DHynqSTlUUV2foGegjudlUJ3mxTCrt2tHn33eOzQ4mqmv3jNOyR1IMiH9QDa0m t4xw== X-Gm-Message-State: APjAAAUOun3O9HMGZBTi/mlratZL56ARkpyuy5sPEkqNsBGUsnv+iBhJ rTw9JMBEYeE/UVRaa7MtlabNcDkl X-Google-Smtp-Source: APXvYqydXgaStGJeZbTXlrGiWvpu7jZbZzXQxUalz34G8+Fpvo+VbzyU72iFlHNd6p32fhb0ip7YPg== X-Received: by 2002:a63:6786:: with SMTP id b128mr4781355pgc.126.1573136755737; Thu, 07 Nov 2019 06:25:55 -0800 (PST) Received: from [192.168.0.17] (24-113-193-150.wavecable.com. [24.113.193.150]) by smtp.gmail.com with ESMTPSA id hi2sm2386972pjb.22.2019.11.07.06.25.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Nov 2019 06:25:55 -0800 (PST) Subject: Re: Missing test of SPI copy functionality To: Michael Paquier Cc: PostgreSQL-development References: <20191107022716.GF1768@paquier.xyz> From: Mark Dilger Message-ID: <59befd2c-0159-5c1c-80b4-92ec72f8db19@gmail.com> Date: Thu, 7 Nov 2019 06:25:54 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20191107022716.GF1768@paquier.xyz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 11/6/19 6:27 PM, Michael Paquier wrote: > On Wed, Nov 06, 2019 at 04:16:14PM -0800, Mark Dilger wrote: >> While working on cleaning up the SPI interface, I found that one of the SPI >> error codes, SPI_ERROR_COPY, is never encountered in any test case when >> running `make check-world`. This case is certainly reachable by a user, as >> is shown in the attached patch. Is this tested from some other >> infrastructure? > > Hard to say, but I think that it would be good to test that part > independently anyway. The transaction part close by is actually > getting stressed with plpgsql_transaction, so the split done in your > patch looks fine. I'll look at it again in a couple of days to > double-check for missing spots, and commit it if there are no > objections. Thanks for reviewing! -- Mark Dilger