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 1qCSB9-0007lR-QG for pgsql-sql@arkaria.postgresql.org; Thu, 22 Jun 2023 21:49:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qCSB8-00086X-J1 for pgsql-sql@arkaria.postgresql.org; Thu, 22 Jun 2023 21:49:22 +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 1qCSB8-00086N-7I for pgsql-sql@lists.postgresql.org; Thu, 22 Jun 2023 21:49:22 +0000 Received: from web.profivps.hu ([84.21.7.15]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qCSB4-0045i7-VQ for pgsql-sql@lists.postgresql.org; Thu, 22 Jun 2023 21:49:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by web.profivps.hu (Postfix) with ESMTP id A983052C9D36 for ; Thu, 22 Jun 2023 23:49:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=profivps.hu; h= content-type:content-type:organization:message-id:user-agent :subject:subject:from:from:date:date:mime-version; s=default; t= 1687470555; x=1689284956; bh=35cWVj4vfLrmwf1U1InVxCRkIQxp3XKoEGD RtU0gB5w=; b=nxwlHPn0TkdVK1mzZTkKaoV513bfpFVx7h/yGiInbbUq4+6Zx4Z sUid1TatRbUTZxCxQWWummw3kr6yb+fxPLhrxlMW0R1Lo0RxOU32UPgXNLVjNEzr U1D3LQBv08qUxGMsx0Wg0XOAs3Ay2Z1Iqrkr9YlblSq6yQZVJLH/2ViPHKUBG5+c K4WpmZBAPFdNwLxXuFh0B7d2047uWzyQGWQc4EERinm25mvVBkKuhnbKbAbQYyg5 U+mBWZKucT/2x44DsIFdUzfWMb/E9o+gaDY+NFJSAvbTZAUvzKydP4Yync4ZI1h3 sUEYaXROtWaEoNcdYYdg+O7zAxCN9MMLULg== X-Virus-Scanned: amavisd-new at web.profivps.hu Received: from web.profivps.hu ([127.0.0.1]) by localhost (web.profivps.hu [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 6xViRcEKP4W7 for ; Thu, 22 Jun 2023 23:49:15 +0200 (CEST) Received: from profivps.hu (localhost [IPv6:::1]) by web.profivps.hu (Postfix) with ESMTP id BB17A52C9D35 for ; Thu, 22 Jun 2023 23:49:15 +0200 (CEST) MIME-Version: 1.0 Date: Thu, 22 Jun 2023 23:49:15 +0200 From: ProfiVPS Support To: pgsql-sql@lists.postgresql.org Subject: Strange update behaviour User-Agent: Roundcube Webmail/1.4.11 Message-ID: <257ece670da80be9e2d08126aba9c641@profivps.hu> X-Sender: support@profivps.hu Organization: ProfiVPS.hu Content-Type: multipart/alternative; boundary="=_d627b4fb29eb398d28edba00f53bd679" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --=_d627b4fb29eb398d28edba00f53bd679 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Gentz, I'm in a dire need of help, because this bug is killing me for weeks=20 now. I got a function, and that function has a simple update query in it: UPDATE app_devices SET device_state =3D p_values[1], device_updateTs =3D=20 NOW(), device_changets =3D CASE WHEN device_state <> p_values[1] THEN NOW() ELSE= =20 device_changets END, device_alertstate =3D CASE WHEN device_state <> p_values[1] THEN 0 ELSE=20 device_alertstate END WHERE device_id=3Ddev_id; The device_alertstate's default value is 200. update and changets are=20 null by default. And I constantly face a result when the device_state is updated,=20 changets and updatets are populated, but the device_alertstate remains=20 on the default 200. As far as I can tell from the second round and forward it works well. I am simply not able to come up with any reasons for this to happen. Thank you very much in advance! Bests, Andr=C3=A1s --- Olcs=C3=B3 Virtu=C3=A1lis szerver: http://www.ProfiVPS.hu T=C3=A1mogat=C3=A1s: Support@ProfiVPS.hu --=_d627b4fb29eb398d28edba00f53bd679 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Gentz, 

  I'm in a dire need of help, because this bug is killing me for we= eks now. 

  I got a function, and that function has a simple update query in = it: 

UPDATE app_devices SET device_state =3D p_values[1], device_updateTs =3D= NOW(),
device_changets =3D CASE WHEN device_state <> p_values[1= ] THEN NOW() ELSE device_changets END,
device_alertstate =3D CASE WHEN= device_state <> p_values[1] THEN 0 ELSE device_alertstate END
W= HERE device_id=3Ddev_id;


 The device_alertstate's default value is 200. update and changets = are null by default. 

 And I constantly face a result when the device_state is updated, c= hangets and updatets are populated, but the device_alertstate remains on th= e default 200. 

  As far as I can tell from the second round and forward it works w= ell. 

  I am simply not able to come up with any reasons for this to happ= en. 


Thank you very much in advance!

Bests, 

András

= ---
Olcsó Virtuális szerver:
http://www.Pr= ofiVPS.hu

Támogatás: Support@ProfiVPS.hu
--=_d627b4fb29eb398d28edba00f53bd679--