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 1slQiq-007ek0-2j for pgadmin-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 10:25: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 1slQio-00A6Vk-G9 for pgadmin-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 10:25: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 1slQio-00A6VW-06 for pgadmin-hackers@lists.postgresql.org; Tue, 03 Sep 2024 10:25:14 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slQik-000Qy5-LS for pgadmin-hackers@postgresql.org; Tue, 03 Sep 2024 10:25:12 +0000 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-53346132348so6345563e87.2 for ; Tue, 03 Sep 2024 03:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1725359109; x=1725963909; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VnrU+fHPbka94A1tyLYeKuVwE8vU8Z13/AwaLMxDPSQ=; b=XRWWFhs2eThAjPm1skDeXn4p5NwdSW7+MyMNWnWlp4UcYhhoRzrt7rA4mNBj0en0QO YY7HishojfP6hM/REljTgFJhbVs5lKpBvx/fiM0Pfm9zsJfa6MPcq3QJqsh/AfiyP/Sm VXB2i/XDGgOeqtn/4zmf6/oXgwThsx13PXrTMnNtLDWNJqMCvNWOXiFEjZwZV6CD9v06 R9WS4HP9HNng8fQeMk64wHcrwBDCBXXgBFnZ7lLy2ckjIvRddZiPb2qzw9qevPV3nNJb i0leUW4YJoB9w4YZi8u0XlRDlmoxExjKojau3IsI5pKZxtStm7wvUjor4gZnzj2XN/jv YwaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725359109; x=1725963909; 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=VnrU+fHPbka94A1tyLYeKuVwE8vU8Z13/AwaLMxDPSQ=; b=i9PxiOoeGimq1cQ9YbflhpW4F2+f3LNl/OUlPA7yxSaP+rFJFE9H2iFrprKgAV9uxV F3VxMK9eTdiO6kTtoMPz0jXY4nEigEMYaPdmtVqxuPFOQXzGAOO1AH1h8KFidCxtXTMz ryr26xBH40KW8zl6uIyb4lYsyIT9D5PQWLOWS+1x8fo0l3pLspts9RbudugYAmYcN92L XU8b/KVovCi3GiSX8z+3Vv+dVIjbtE8NYAbH+blPAqOn61IIl8Ioub8hkAE58+dN6S5v +PRxmchqEmT9TOxbV6FgfSjliCLjI81wKtfzkeHU/juKLqKioA00E+2fSk3zjrBMtgv3 +JfQ== X-Forwarded-Encrypted: i=1; AJvYcCU424FwG95684gV5HQ8DjpZ1ex6oDKS+YrWyuZ/cwZ1ZkgsT//BMeGjrcjZBQoDrRl+52Q6X4l+UIyHEIIDhL8=@postgresql.org X-Gm-Message-State: AOJu0YwrwMaPjw3mnnGvc53BvFxYJHbbYP2eq8gU4cy2arqskP2Pp3Zx NHz5qEyEPZ7smnUqvQNf+fNOfobsjYC1lXdbHmTe7gUP1hIQbY5nWuMOi1dF4Zl1ZOkDE7annCl FRnBSiLM2IrCF2pzN9YNFqbyzrBj7zyI5cYZk X-Google-Smtp-Source: AGHT+IHui6wF1zjmJwV6spEkD4lXfS2ZemUXKcQDcoBZ4KwxeDq+b4fJUfDIDCcT7w14z6CLPNNxN2nUx17K3LG1x0A= X-Received: by 2002:a05:6512:3b11:b0:52c:812b:6e72 with SMTP id 2adb3069b0e04-53546af0069mr8803781e87.1.1725359108538; Tue, 03 Sep 2024 03:25:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Tue, 3 Sep 2024 11:24:57 +0100 Message-ID: Subject: Re: Require suggestions on issue #7811 To: Yogesh Mahajan Cc: Pravesh Sharma , pgadmin-hackers@postgresql.org Content-Type: multipart/alternative; boundary="000000000000c6619006213478d2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c6619006213478d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 3 Sept 2024 at 10:51, Yogesh Mahajan < yogesh.mahajan@enterprisedb.com> wrote: > > Thanks, > Yogesh Mahajan > EnterpriseDB > > > > On Tue, Sep 3, 2024 at 3:11=E2=80=AFPM Dave Page wrot= e: > > Hi > > Hi >> >> On Tue, 3 Sept 2024 at 10:32, Yogesh Mahajan < >> yogesh.mahajan@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> This isn't the issue in the case of sqlite db while using persistent >>> storage. Issue appears only if external database is used as pgadmin >>> configuration db. Just having different way of persistent storage( in t= his >>> case backend database) behaviour should not be different. >>> >> >> No, the two database types should behave the same way. Why then, is >> PostgreSQL different from SQLite? Is SQLIte effectively using the --repl= ace >> option whilst PostgreSQL is not (though I can't imagine why that would b= e >> the case)? >> > > Issue is because the loading server is performed in the absence of the ' > /var/lib/pgadmin/pgadmin4.db' file which is always true in case of an > external database. > Ah, well in that case for PostgreSQL we can just check if the pgAdmin schema has all been created/loaded right? > > However, I retract my previous comment (though if this were new behaviour= , >> perhaps I wouldn't) - the docs say: >> >> =3D=3D=3D=3D=3D >> If this file is mapped, server definitions found in it will be loaded at >> launch time. This allows connection information to be pre-loaded into th= e >> instance of pgAdmin in the container. Note that server definitions are o= nly >> loaded on first launch, i.e. when the configuration database is created, >> and not on subsequent launches using the same configuration database. >> =3D=3D=3D=3D=3D >> >> So the advertised feature is that we do only load the servers once into >> any given configuration database. >> >> >>> >>> Also, on restart admin user specified while container is not recreated. >>> Can't we fix on similar lines? >>> >>> Thanks, >>> Yogesh Mahajan >>> EnterpriseDB >>> >>> >>> On Tue, Sep 3, 2024 at 2:05=E2=80=AFPM Dave Page wr= ote: >>> >>>> >>>> >>>> On Tue, 3 Sept 2024 at 09:29, Pravesh Sharma < >>>> pravesh.sharma@enterprisedb.com> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> On Tue, Sep 3, 2024 at 1:47=E2=80=AFPM Dave Page = wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Tue, 3 Sept 2024 at 09:10, Pravesh Sharma < >>>>>> pravesh.sharma@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi Hackers, >>>>>>> >>>>>>> I am working on issue #7811 >>>>>>> , where using >>>>>>> an external database for storing pgAdmin configuration results in d= uplicate >>>>>>> server entries when a container with a mapped servers.json file is >>>>>>> restarted. >>>>>>> >>>>>>> The proposed solution is to implement a check when loading servers. >>>>>>> We would verify the server=E2=80=99s name, host, port, and username= to determine if >>>>>>> the server already exists in the database. If it does, we would ski= p >>>>>>> registering it again. >>>>>>> >>>>>>> >>>>>>> Please share any suggestions or feedback on this approach. >>>>>>> >>>>>> >>>>>> I would say "Won't fix". If someone is using persistent storage for >>>>>> settings, why launch containers to import the same servers over and = over >>>>>> again? Just load them once, manually. >>>>>> >>>>> What if the container needs to be restarted? In that case it will >>>>> again import the server making a duplicate entry. >>>>> >>>> >>>> Not if the servers are manually imported rather than through >>>> servers.json. >>>> >>>> -- >>>> Dave Page >>>> pgAdmin: https://www.pgadmin.org >>>> PostgreSQL: https://www.postgresql.org >>>> EDB: https://www.enterprisedb.com >>>> >>>> PGDay UK 2024, 11th September, London: https://2024.pgday.uk/ >>>> >>>> >> >> -- >> Dave Page >> pgAdmin: https://www.pgadmin.org >> PostgreSQL: https://www.postgresql.org >> EDB: https://www.enterprisedb.com >> >> PGDay UK 2024, 11th September, London: https://2024.pgday.uk/ >> >> --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org EDB: https://www.enterprisedb.com PGDay UK 2024, 11th September, London: https://2024.pgday.uk/ --000000000000c6619006213478d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 3 Sept 2024 at 10:51, Yogesh = Mahajan <yogesh.mahaj= an@enterprisedb.com> wrote:

Thanks,
= Yogesh Mahajan
EnterpriseDB
<= br>


On Tue, Sep 3, 2024 at 3:11=E2=80=AFPM Dave P= age <dpage@pgadmi= n.org> wrote:

Hi

Hi

On Tue, 3 Sept 2024 at 10:32, Yogesh Mahajan <yogesh.mahajan@enter= prisedb.com> wrote:
H= i Dave,
=
Thi= s isn't the issue in the case of sqlite db while using persistent stora= ge. Issue appears only if external database is used as pgadmin configuratio= n db. Just having different way=C2=A0of persistent storage( in this case ba= ckend database) behaviour should not be different.=C2=A0
<= /blockquote>

No, the=C2=A0two database types should beha= ve the same way. Why then, is PostgreSQL different from SQLite? Is SQLIte e= ffectively using the --replace option whilst PostgreSQL is not (though I ca= n't imagine why that would be the case)?
=

Issue is because the loading server is performed in the absence of the = =C2=A0'/var/lib/pgadmin/pgadmin4.db'= =C2=A0 file which is always=C2=A0true in case of an external database.

Ah, well in that case for Pos= tgreSQL we can just check if the pgAdmin schema has all been created/loaded= right?

=C2=A0

However, I retract my previous comment (though if this w= ere new behaviour, perhaps I wouldn't) - the docs say:

=3D=3D=3D=3D=3D
If this file is mapped, server definitio= ns found in it will be loaded at launch time. This allows connection inform= ation to be pre-loaded into the instance of pgAdmin in the container. Note = that server definitions are only loaded on first launch, i.e. when the conf= iguration database is created, and not on subsequent launches using the sam= e configuration database.
=3D=3D=3D=3D=3D

So the advertised feature is that we do only load the servers once in= to any given configuration database.
=C2=A0

Also, on restart admin user specified while container is= not recreated. Can't we fix on similar lines?

Thanks,
Yogesh Mahajan
EnterpriseDB


On Tue, Sep 3, 2024 at 2:05=E2=80=AFPM Dave Page &= lt;dpage@pgadmin.org= > wrote:


On Tue, 3 Sept 2024 at 09:29, Pravesh Sharma <pravesh.sharma@enterprisedb= .com> wrote:
Hi Dave= ,

On Tue, Sep 3, 2024 at 1:47=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Tue, 3 Sept 2024 at 09:10, Pra= vesh Sharma <pravesh.sharma@enterprisedb.com> wrote:
Hi Hackers,

I am w= orking on issue #7811, where using an external database for stor= ing pgAdmin configuration results in duplicate server entries when a contai= ner with a mapped servers.json file is restarted.


<= div>

The proposed solution is to implement a check when loading server= s. We would verify the server=E2=80=99s name, host, port, and username to d= etermine if the server already exists in the database. If it does, we would= skip registering it again.


Please share any suggest= ions or feedback on this approach.

<= br>
I would say "Won't fix". If someone is using pe= rsistent storage for settings, why launch containers to import the same ser= vers over and over again? Just load them once, manually.=C2=A0
<= /div>
What if the container=C2=A0needs to be restarted? In= that case it will again import the server making a duplicate entry.
<= /div>

Not if the servers are manually= imported rather than through servers.json.
=C2=A0
--
Dave Page
= PostgreSQL: https:= //www.postgresql.org

<= /div>
PGDay UK 2024, 11th September, London: https://2024.pgday.uk/

<= /div>


--
Dave Page
PostgreSQL: https://www.postgresql.or= g

PGDay UK = 2024, 11th September, London: https://2024.pgday.uk/



--
Dave Page
PostgreSQL: https://www.postgresql.or= g

PGDay UK = 2024, 11th September, London: https://2024.pgday.uk/

--000000000000c6619006213478d2--