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 1nxo9E-0003FG-He for pgsql-sql@arkaria.postgresql.org; Sun, 05 Jun 2022 11:10:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nxo9C-00085x-1Y for pgsql-sql@arkaria.postgresql.org; Sun, 05 Jun 2022 11:10:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nxo9B-00085o-HA for pgsql-sql@lists.postgresql.org; Sun, 05 Jun 2022 11:10:17 +0000 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nxo99-0003s7-0r for pgsql-sql@lists.postgresql.org; Sun, 05 Jun 2022 11:10:16 +0000 Received: by mail-lf1-x134.google.com with SMTP id be31so19271462lfb.10 for ; Sun, 05 Jun 2022 04:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=pysMNVHrF7Z2ZjEZFgNLGX8/nAOK3pad9MODFJ7/2u0=; b=F6haAvKgTYDjpw83c2auGRrsaXv4JCxgs6aPaxzxkGqbL84VvI2hy2VClItYFVpgKk 5YUhPik8QLuRhNtG4n9BJDo56zEatvhLHl+JLqArmrZxihZB7w1u57hSuH9cxRozArvL 2uCK6XsSuHudaRfF1xuE6fQ7vz0sC4x5XiEPU5bxmlZPwMPTepEvRhcJh52NaTh+frsd 9twnMs2AOG4Phr/1Vk/V/t6HbgWSzlz5yeJs7OF1EhU7tYmos+r0DonlOeli5shqAzNx Tto+LF/ilo4dyG5SDjS8/wMffsA+MeScH6Sme6GwVRUCobLhQHQ5ZfxpEKGko7E5PTjU ttiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pysMNVHrF7Z2ZjEZFgNLGX8/nAOK3pad9MODFJ7/2u0=; b=7gLl51ULsWclpgCEZKz6OLzhD5d4W9uaJteoT4V6vmFoZdQ1C/z14il9OeJGhlQF3g GqUju9ZJfLzobxXxExqz+sO3U/dKkpoUJ9BEBTa1FP0HTAkqcEsN2orOKLTJ3XESBO/3 40DlJD/v82NRrUDO0vvnxOQNqFpT3r5Pr36V1SirCeVhY5BfSIWR75hOq4zC0TyzBYTw HIQfwsKlpj+UVWlPoU+UcqwVwNq0FiFDxGQ35uJaoLrGUKQCR0OZVnt3dxBXCoFaKHxJ 9YGid32g0idUy/sgDCFW7J45Q6elETYDJ1qspWRHt/SuCAzC8YnGjsPOjWNeb/ONLXBa exnQ== X-Gm-Message-State: AOAM530NmFIItUzEEFRDwIs78fGZcwef/i+OYa9qOUctAJqiASbgXZ5X ZchHkMzNGF8O+my52RJIhyatg7dM/qjXyqeE8g+jZTvjIexU5w== X-Google-Smtp-Source: ABdhPJy7BOEXGaPgwgZPaPnNUd8mYhqxYal1pry+bQyDLQeUd6mvIdzFQkcrDs55riHtFJnWZ3WrTUEvFiURhDkou6A= X-Received: by 2002:a05:6512:260d:b0:445:c06e:8242 with SMTP id bt13-20020a056512260d00b00445c06e8242mr12011307lfb.157.1654427412586; Sun, 05 Jun 2022 04:10:12 -0700 (PDT) MIME-Version: 1.0 From: Hui Jackson Date: Sun, 5 Jun 2022 19:10:01 +0800 Message-ID: Subject: Strange behavior of transcations To: pgsql-sql@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000003be49305e0b1663f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003be49305e0b1663f Content-Type: text/plain; charset="UTF-8" I am working on node-postgres and there is a strange transactions. The function aims at locking user's wallet until the refund process is complete, then will update item's has_refund to true. The problem I am facing is the program return no error, but the database is not updated. Unless I spam the function for multiple times then the value is updated. If I remove begin and commit, then the function work perfectly. const refundService = (itemId) =>{ await pgPool.query('BEGIN;'); const users = (await pgPool.query('SELECT * from app_user where $1=ANY(purchase_list);', [ itemId ])).rows; for(let i = 0; i < users.length; i++){ refund(users[i]) } await pgPool.query('UPDATE item_lists SET has_refund = $1 where id = $2;', [true, itemId ]); await pgPool.query('COMMIT;'); } const refund = (user) =>{ const refund = 10 await pgPool.query('UPDATE app_user SET wallet = wallet + $1', [refund ]); } --0000000000003be49305e0b1663f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am working on node-postgres and there is a strange trans= actions.
The function aims at locking user's wallet until the refun= d process=C2=A0is complete, then will update item's has_refund to true.=
The problem I am facing is the program return no error, but the databas= e is not updated. Unless I spam the function for multiple times then the va= lue is updated.
If I remove begin and commit, then the function work per= fectly.
const refundService = =3D (itemId) =3D>{
=C2=A0 =C2=A0 await pgPool.query('BEGIN;');
=C2= =A0 =C2=A0 const users =3D (await pgPool.<= span style=3D"color:rgb(220,220,170)">query('SELECT * from app_user where $1=3DANY(purchase_list);&#= 39;, [ itemId ])).rows;
=C2=A0 =C2=A0 for(let i =3D 0; i < users= .length; i++){
=C2=A0 =C2=A0 =C2=A0 =C2=A0 refund(users[i])
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 await pgPool.query('UPDATE item_lists SET has_refund =3D $1 where id = =3D $2;', [true, = =C2=A0itemId ]);
= =C2=A0 =C2=A0 await pgPool.query('COMMIT;'= ;);
}
=C2=A0 =C2=A0
const re= fund =3D (user) =3D>{
=C2=A0 =C2=A0 const refund =3D 10
=C2=A0 =C2=A0 await pgPool.query(= 9;UPDATE app_user SET wallet =3D wallet + $1', [refund ]);
}
--0000000000003be49305e0b1663f--