Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rid40-000fy4-Nj for pgsql-sql@arkaria.postgresql.org; Fri, 08 Mar 2024 16:27:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rid3y-00E7G6-7B for pgsql-sql@arkaria.postgresql.org; Fri, 08 Mar 2024 16:27:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rid3x-00E7Fy-LW for pgsql-sql@lists.postgresql.org; Fri, 08 Mar 2024 16:27:14 +0000 Received: from mail-ed1-f43.google.com ([209.85.208.43]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rid3t-003VNf-Qc for pgsql-sql@lists.postgresql.org; Fri, 08 Mar 2024 16:27:12 +0000 Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-567fbbd723cso1252408a12.3 for ; Fri, 08 Mar 2024 08:27:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709915229; x=1710520029; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GB0nqnXgAl4hbRLYIsbcihtQ3x9s6w64wKps7TUvUq4=; b=QcN1JMEl2ChsScenzOaiqoQ9X3amI6uhJ28iDvkO3jmjVW5xZP9U6ulQp5GwnK6Nq9 I7+wZQClXoW2U1SXiLVv+rLZ07/QdfPNloziEnE/E+NK45ZhFzAXNueFzoGdMUCS1Gy7 0EzBGw9QsidsIzqdiGzBsyqSdKXwY60Gyj2C2wXxfZN+rlV+qhjd/MMsP7JIUqOSZicc CH1ho1LvsW3xi56GI6ArQ4dhbglxucocrlOHD5ht7ej1n3db1rrAgyWMtxJ59Bp8O9aW JYuWHlJFCNRF9z6lHi29fswcTfsjev/XGIhudKxR7bqLvWws9ix6LvzvdBzg/U9rU9PC wvDg== X-Gm-Message-State: AOJu0Yz2Mvri+qpdcahbfuNr6Ctzls7CUv7efzoqJ0EuJJ3tKdOqCFmO Qap0Hv/WA4PKPqXjDljCXivhbV5c3mwEFAkFYIFM5lw6xpd/lOczmlDb6PCXj211Mg== X-Google-Smtp-Source: AGHT+IFAQ4KllmiqXmnTq0Wph94FhX7f0bcNNJIPRIm59yrK8Q3S/5clFtlC8xhgkbMYuHJo6fYLIg== X-Received: by 2002:a50:cd1e:0:b0:566:5ea2:1257 with SMTP id z30-20020a50cd1e000000b005665ea21257mr2446250edi.16.1709915228661; Fri, 08 Mar 2024 08:27:08 -0800 (PST) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com. [209.85.221.54]) by smtp.gmail.com with ESMTPSA id bx15-20020a0564020b4f00b0056826248468sm1192268edb.89.2024.03.08.08.27.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Mar 2024 08:27:07 -0800 (PST) Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-33e796cc90dso334676f8f.1 for ; Fri, 08 Mar 2024 08:27:07 -0800 (PST) X-Received: by 2002:a5d:6a50:0:b0:33e:5fb9:af28 with SMTP id t16-20020a5d6a50000000b0033e5fb9af28mr4424956wrw.57.1709915227474; Fri, 08 Mar 2024 08:27:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Steve Midgley Date: Fri, 8 Mar 2024 08:26:21 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: How to know if all insertions are finished To: intmail01 Cc: pgsql-sql@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000bae952061328a9c3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bae952061328a9c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 8, 2024 at 4:01=E2=80=AFAM intmail01 wrot= e: > Hi, > > Is there any way to know if several insertion are terminated. > I use libreoffice base to import at the same time many lines. When all > lines are inserted I have to do some data check. I dont find any way to > know if the insertion ends to start some function automatically. > I tried to use a STATEMENT trigger type but all lines are treated as > statement. > I think you are saying in your last line that each insert line is treated as an individual statement, so you get a bunch of trigger notifications instead of just one, and you don't know how to detect when you have received the final insert? The first thing I'd look for is whether I could wrap all the libreoffice inserts into a single transaction block, and then event off of the transaction block completing. Barring that, and noting I'm not familiar with how libreoffice would send the inserts, one option could be to put a listen/notify pattern at the end of your insert code, if it's possible to add a line of sql at the end of the inserts? Of course, if you can do that, you might also be able to wrap the whole thing with a transaction, but listen/notify might be simpler to event off of.. -- In session/connection 1 BEGIN; -- Perform your bulk insert operation here COMMIT; NOTIFY inserts_done; -- In session/connection 2 LISTEN inserts_done; -- Once notification is received, proceed with necessary operations If you can't do something like this, the only other (relatively horrible) things I can think of would be to: 1. Put a dummy row at the end of your insert data (if you can guarantee it would be inserted last during the bulk operation), and then build a trigger/condition to detect insertion of a row matching the dummy data t= hat deletes the dummy row and then proceeds to kick off whatever other processes you want, or: 2. Use a time based model, where you build an understanding of how long your inserts take to execute, and build a monitor that kicks off on each insert, and if another insert is not detected within a certain amount of wait time, you conclude that there are no more inserts coming, and you t= hen kick off whatever other processes you want.. Hopefully someone with deeper Postgres knowledge has other, more reliable solutions that leverage Postgres, but if your inserts are all discrete, and you don't have control over the sql itself. Steve --000000000000bae952061328a9c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 8, 2024 = at 4:01=E2=80=AFAM intmail01 <int= mail01@gmail.com> wrote:
Hi,

Is there = any way to know if several insertion are terminated.
I use libreo= ffice base to import at the same time many lines. When all lines are insert= ed I have to do some data check. I dont find any way to know if the inserti= on ends to start some function automatically.
I tried to use a ST= ATEMENT trigger type but all lines are treated as statement.

I think you are saying in you= r last line that each insert line is treated as an individual statement, so= you get a bunch of trigger notifications instead of just one, and you don&= #39;t know how to detect when you have received the final insert?

The first thing I'd look for is whether I could wrap al= l the libreoffice inserts into a single transaction block, and then event o= ff of the transaction block completing.

Barring th= at, and noting I'm not familiar with how libreoffice would send the ins= erts, one option could be to put a listen/notify pattern at the end of your= insert code, if it's possible to add a line of sql at the end of the i= nserts? Of course, if you can do that, you might also be able to wrap the w= hole thing with a transaction, but listen/notify might be simpler to event = off of..

-- In sessi= on/connection 1
BEGIN;
-- Perform your bulk insert operation here<= /font>
COMMIT;
NOTIFY inserts_done;

-- In session/connectio= n 2
LISTEN inserts_done;
-- Once notification is received, proceed= with necessary operations

If you can= 't do something like this, the only other (relatively horrible) things = I can think of would be to:
  1. Put a dummy row at the end of= your insert data (if you can guarantee it would be inserted last during th= e bulk operation), and then build a trigger/condition to detect insertion o= f a row matching the dummy data that deletes the dummy row and then proceed= s to kick off whatever other processes you want, or:
  2. Use a time bas= ed model, where you build an understanding of how long your inserts take to= execute, and build a monitor that kicks off on each insert, and if another= insert is not detected within a certain amount of wait time, you conclude = that there are no more inserts coming, and you then kick off whatever other= processes you want..
Hopefully someone with deeper Postgres = knowledge has other, more reliable solutions that leverage Postgres, but if= your inserts are all discrete, and you don't have control over the sql= itself.

Steve
--000000000000bae952061328a9c3--