Re: Strange update behaviour
От | Tom Lane |
---|---|
Тема | Re: Strange update behaviour |
Дата | |
Msg-id | 4141157.1687485367@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Strange update behaviour (ProfiVPS Support <support@profivps.hu>) |
Ответы |
Re: Strange update behaviour
|
Список | pgsql-sql |
ProfiVPS Support <support@profivps.hu> writes: > I hope everything is there to enable testing. Thanks for sending a test case! But I think this is a logic bug in your function. There are several updates of app_devices in that function. Adding some "raise notice" commands to track the logic flow, I see that the given case results in # SELECT collectd_insert(CURRENT_TIMESTAMP, 'DE:AD:A7:14:69:9210.123.4.12', 'ruckusphp', '', 'pstates_enabled', 'state', '{et}', '{0}', '{1}'); NOTICE: first update happening NOTICE: fourth update happening collectd_insert ----------------- (1 row) So it is first doing UPDATE app_devices SET device_state=1, device_changets=NOW(), device_updatets=NOW() WHERE device_id= dev_id; and then later doing the UPDATE you showed. But at that point, device_state is already 1 so neither of the device_alertstate or device_changets updates change the column's value. It's unobvious that the device_changets update is a no-op because the first UPDATE already set it to the same new value. regards, tom lane
В списке pgsql-sql по дате отправления: