Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mHsN5-0007wL-2h for pgsql-bugs@arkaria.postgresql.org; Sun, 22 Aug 2021 18:39:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mHsN3-0001xt-VS for pgsql-bugs@arkaria.postgresql.org; Sun, 22 Aug 2021 18:39:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mHsN3-0001xl-Ht for pgsql-bugs@lists.postgresql.org; Sun, 22 Aug 2021 18:39:01 +0000 Received: from mail-qv1-xf36.google.com ([2607:f8b0:4864:20::f36]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mHsMw-0001uL-SV for pgsql-bugs@lists.postgresql.org; Sun, 22 Aug 2021 18:39:00 +0000 Received: by mail-qv1-xf36.google.com with SMTP id jz1so8487574qvb.13 for ; Sun, 22 Aug 2021 11:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=pc1BsMwrz3AoCWQ2sGDuOWLUDBj6OkSPGGotjk73yhI=; b=ZldhKtF/qk1KeKGXlXgLMHPE6YkSspamMrWHC27ngvg5ai35iID5uLiGnf3quUQxsO RV8VpL+uYBZjSY1HKGcXyV2VRSiGFYEE57zqGQc/7AHNaFLpR7igcScsHNLwZ79mJS3z vkQAulD1aBQOQSE6It762quX3nWG96YiwDqwM= 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:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=pc1BsMwrz3AoCWQ2sGDuOWLUDBj6OkSPGGotjk73yhI=; b=nCt6wll3VbHiSIMutsDuH8AEYrXLWO34kDd1wVmyCKbgXihbncn7j8xhLx2EZZJhZ8 izkH/HvmsShiBmGBfv6NGH9yOcM03AUpc+JalxXY4esZ7WjGZSmXe/T99g/3MT5VuK+n A6YXfs9cwdjzRtHO1e0zcbV56Y81UhD2ZWWBkkCUUgU7QShdX0BLGlMlUKKBtRjZicQg oXNieFkbb3ToIi7TmBd2p7cpOA75MAsaglC3wIXt5NoS8gRKey08FLm3076GwTzGDGQr 7mAy6NOw3PpVI4jBcBcRoTFgEym0+z7RMjlO1e3Ndo7CKs1JsffndNAfzStw2CbQJOqR MadA== X-Gm-Message-State: AOAM531PcYck+77THw+B78lPGv398FJDDsi3h3ZJk2gXrxOdoJIMOiSj /PyhWOj9msmZK9LLJAxhiEXvIg== X-Google-Smtp-Source: ABdhPJxnOxlN6sB7n3Z4cPNY5tXJluMQPjQ8ztKoq4aNePpCalc7CmonmkeixbzFuxvcIEehowtHeg== X-Received: by 2002:a05:6214:d83:: with SMTP id e3mr29655425qve.23.1629657532961; Sun, 22 Aug 2021 11:38:52 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::46]) by smtp.gmail.com with ESMTPSA id t64sm7340583qkd.71.2021.08.22.11.38.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Aug 2021 11:38:52 -0700 (PDT) Date: Sun, 22 Aug 2021 11:38:49 -0700 From: Noah Misch To: d.sekretov@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17070: Sometimes copy from ingnores transaction Message-ID: <20210822183849.GA1747628@rfd.leadboat.com> References: <17070-701777d014fe5684@postgresql.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17070-701777d014fe5684@postgresql.org> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jun 23, 2021 at 07:02:18AM +0000, PG Bug reporting form wrote: > The following bug has been logged on the website: > > Bug reference: 17070 > Logged by: Дмитрий Секретов > Email address: d.sekretov@gmail.com > PostgreSQL version: 12.1 > Operating system: Windows Server 2016 > Description: > > Driver: Npgsql 4.0.9 (.net 4.7.1) > > We use following construction in our code: > 1. Start transaction > 2. COPY FROM STDIN BINARY (table name depends on context) > 3. Insert into "some_table"("some_value") > 4. Commit transaction > > It works fine. When something goes wrong then transaction rollbacks. > But we found the issue. We do copy operation (step 2). When copy commands > ended the driver sends “copy done” command to postgresql backed and starts > waiting for “command complete” message and error occurs during waiting. > > 2021-04-29 02:40:01,593 ERROR Exception while reading from stream ---> > System.IO.IOException: Unable to read data from the transport connection: A > connection attempt failed because the connected party did not properly > respond after a period of time, or established connection failed because > connected host has failed to respond. > > In a 160 seconds postgresql reported in logs > > 2021-04-29 02:42:41 database LOG: duration: 202590.129 ms statement: COPY > "principal_reference" (id,"some_payload") FROM STDIN BINARY; > 2021-04-29 02:42:41 database LOG: could not receive data from client: An > established connection was aborted by the software in your host machine. > > In our application code we retry operation, if something goes wrong. And > when we start retrying we've got an exception > 2021-04-29 02:42:41 database ERROR: duplicate key value violates unique > constraint "PK_principal_reference_id" > > We didn't commit transaction. But copy done successfully and there is no row > inserted at step 3. Most likely, (1) never happened, so your application was actually running (2) as an implied transaction that did commit. One way to confirm this is to set log_statement=all and look for the BEGIN (or START TRANSACTION) command in the logs. What sequence of commands does the server log show from the session that experiences the problem? > Is there a workaround? Like a copy into temp table and then insert from temp > table? There probably would be a workaround, but if COPY results are visible after a transaction rollback, that would be a bug.