Hi!
>I just meant a regular update (which might impact 0 rows) and then
insert (not exists) like you are doing already.
This causes duplicate key exception if other process adds same row to
table at same time.
>--transaction still ways. Should manual locking used or is there
better metho
I just meant a regular update (which might impact 0 rows) and then insert
(not exists) like you are doing already.
--transaction still ways. Should manual locking used or is there better
method.
I don't follow what you mean.
Hi
>Why just do a plain update, relying on row level locking to serialize
requests properly, and then just do an insert where not exists? Is there
value in doing the delete? I don't see it.
This is an option. How to do update+insert in 9+ in SQL ? Or should
plpgsql procedure created for th
Why just do a plain update, relying on row level locking to serialize
requests properly, and then just do an insert where not exists? Is there
value in doing the delete? I don't see it.
Note- On conflict clause is supported from 9.5+ and that is already past
EOL. Upgrading to at least v10 is recom
Adrian Klaver writes:
> On 3/3/21 3:58 PM, Fontana Daniel C. (Desartec S.R.L.) wrote:
>> When the update is manual, it works.
>> It does not work when the update is done using logical replication.
>> It is as if the logical replication wizard did not use the search_path
> Replication would imply
Hi!
Since we have not actually seen the entire script nor have any idea
what the other process is, there is no way to answer this.
This is the same whole script. It will ran by multiple scheduled tasks,
maybe at same time.
It registers logged in user. Different processes may have same user
On 3/3/21 3:58 PM, Fontana Daniel C. (Desartec S.R.L.) wrote:
Please reply to list also.
Ccing list.
Also please do not top post, use inline and/or bottom posting.
When the update is manual, it works.
It does not work when the update is done using logical replication.
It is as if the logical rep
On 3/3/21 10:14 PM, Andrus wrote:
Hi!
says something else is inserting/updating using that key value. So
obviously your script is not catching all the conflicts.
> At this point your best bet is to monitor the Postgres log and see
what else is happening at the time of the error. I'm guessing
hm ok, thank you Tom.
As you mentioned, I think it is not really possible to find out which of
the sessions should be there and which not.
Also, as it is a Cloud SQL instance in GCP, I don't have access to a user
with superuser attributes.
Best regards,
Tobias
On Wed, 3 Mar 2021 at 17:33, Tom Lan
okay, thank you Tom.
There were no crashes of the instance, but some issues with the connected
application, resulting in 'could not receive data from client: Connection
reset by peer' and 'unexpected EOF on client connection with an open
transaction'.
So if this might have left behind temp tables
Yes that's strange. A lot of pg_XX tables are skipped, but some of these
pg_temp schemas cause errors.
Could it be connected to a migration of the database (from an instance
running PostgreSQL 9.6 to an instance running PostgreSQL 12) done a few
weeks ago?
Regards,
Tobias
On Wed, 3 Mar 2021 at 16
Hello Magnus,
thank you very much for your answer and your support.
I can confirm that authentication now works as expected again.
Have a nice day Mathias
-Original Message-
From: Magnus Hagander
Sent: Wednesday, March 3, 2021 12:50 PM
To: Mathias Zarick
Cc: pgsql-gene...@postgresql.or
12 matches
Mail list logo
