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 1slRn8-007nzT-4Q for pgadmin-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 11:33:47 +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 1slRn7-00An2F-8l for pgadmin-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 11:33:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1slRn6-00An27-UV for pgadmin-hackers@lists.postgresql.org; Tue, 03 Sep 2024 11:33:45 +0000 Received: from mail-yw1-x1133.google.com ([2607:f8b0:4864:20::1133]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slRn3-000S5i-DV for pgadmin-hackers@postgresql.org; Tue, 03 Sep 2024 11:33:43 +0000 Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-6b4412fac76so40905547b3.1 for ; Tue, 03 Sep 2024 04:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1725363219; x=1725968019; 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=SCjRDWWx4vggVPMoVe1ye9CA+OvIMUr3+X+w+JL90GI=; b=PJwHNJFwmj8GJfYTXtg4XVA2PM46yXw5wImLe5iNcXEQoMn+D1hYhlbEQrfrzLulPK qhfUi86asDLWOvV6hdWjH2jvgMfdWMm28awkmZeQzs+QQSrVXZfOXCD4uMXDTSC9t4oL AE9Yn9CjaZbW92AqJHd3wpNIPvKDFRIBTtVg6CQNse3xMR52tHHR0TbPhvdK1xT3lNYn B9xOmNaMy0ybXI4iZuckZP8DhnD2w03E0fpI0GteEomc+cVx3/cgDO4dJZWK8QFSZQYh 4fcP0Zx8NolwbmWwM5o5FHuHEPFz2v0NuPUBzWTUz5+PUlo/Ils06Bgq/6Pokh4fO34E NL4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725363219; x=1725968019; 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=SCjRDWWx4vggVPMoVe1ye9CA+OvIMUr3+X+w+JL90GI=; b=KG8Ew3wQtGhYmRUH+DJBclBHHVAHVkJF94WWi9xufUMULMglQ3uNIqVHfZYUp2p80u tB+p/+olNGAuqbyiHlyoZwi4IkM2JVLMRsRxw4IHiazdfuVitv0WhQjRJay9nd3tOVwj 1z5h5vo5uhV1QmtbA7CWop+4Tfxxvr37yfYjzgWWl0u7/MQAxJex7K2qqe2Owv3ykxXP un+0Dz8vFwx8Hai1CPv65Sf/liHK5H/S+4PmVoChWqucx/hJs+0fqBVYi7D9aU66dnro H6LeDjzQl4VMXzTRkn2vERxexn618HuJPY/cvbqxAiweV51LFip/mRti7cZYGKRkkCNH JLbw== X-Forwarded-Encrypted: i=1; AJvYcCU4kVYvTbualeSbBTWUB9A+gIEN1dfJytQOuRvSf0sxHajHxKnyUwTjHXLfSfqmQIh3I+mzpYwsVPm1HTIWTtM=@postgresql.org X-Gm-Message-State: AOJu0Yziz2cnfxLjMICQ01d0CfeQiIl2b8D3JPe3I1UoVY2xP5NvNErX mpCIb/mzKuuviZoIgw8Nge6c5gJigUOwkzla+9ax2OAyZ8q1SzGyvknN0SubXRwnm5bxBhu4QYz 75JPrfnwwe9r8G/W03RSswHE6z23IvDwu9PD3p0U3Sbo+krzMAA== X-Google-Smtp-Source: AGHT+IHoqZ8Hn1od3MdPYc6Rj7TMO2rTwzaUqCrMoo2lOaFrKnNBScp40N7Yl6n2OWCwcX5E1rJJqfwL2KwLBH1ND+A= X-Received: by 2002:a05:690c:6788:b0:6d4:e841:20b7 with SMTP id 00721157ae682-6d4e8412806mr129568887b3.17.1725363219318; Tue, 03 Sep 2024 04:33:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yogesh Mahajan Date: Tue, 3 Sep 2024 17:03:03 +0530 Message-ID: Subject: Re: Require suggestions on issue #7811 To: Dave Page Cc: Pravesh Sharma , pgadmin-hackers@postgresql.org Content-Type: multipart/alternative; boundary="000000000000cbea530621356de8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000cbea530621356de8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Tue, Sep 3, 2024 at 3:55=E2=80=AFPM Dave Page wrote: > > > 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 wro= te: >> >> 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 = this >>>> 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 --rep= lace >>> option whilst PostgreSQL is not (though I can't imagine why that would = be >>> 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? > Yes, we can try this way. Thanks, Yogesh Mahajan EnterpriseDB > > >> >> 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 a= t >>> launch time. This allows connection information to be pre-loaded into t= he >>> instance of pgAdmin in the container. Note that server definitions are = only >>> 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 w= rote: >>>> >>>>> >>>>> >>>>> 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 = duplicate >>>>>>>> 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 usernam= e to determine if >>>>>>>> the server already exists in the database. If it does, we would sk= ip >>>>>>>> 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/ >>> >>> > > -- > 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/ > > --000000000000cbea530621356de8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= div dir=3D"ltr" class=3D"gmail_signature">

Hi,<= /div>

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


On Tue, 3 Sept 2024 at 10:51, Yog= esh Mahajan <yogesh.mahajan@enterprisedb.com> wrote:

Thanks,
Yogesh Mahajan
EnterpriseDB
<= /div>


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

Hi

Hi

On Tue, 3 Sept 2024 at 10:32, Yogesh Mahaja= n <= 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 a= s pgadmin configuration db. Just having different way=C2=A0of persistent st= orage( in this case backend database) behaviour should not be different.=C2= =A0

No, the=C2=A0two data= base types should behave the same way. Why then, is PostgreSQL different fr= om SQLite? Is SQLIte effectively using the --replace option whilst PostgreS= QL is not (though I can'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/pgad= min4.db'=C2=A0 file which is always=C2=A0true in case of an exte= rnal database.

Ah, well i= n that case for PostgreSQL we can just check if the pgAdmin schema has all = been created/loaded right?

Yes, we can try this way.=C2=A0

Thanks,
Yogesh Mah= ajan
EnterpriseDB
<= br>
=C2=A0
<= br>
= 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 wil= l be loaded at launch time. This allows connection information to be pre-lo= aded into the instance of pgAdmin in the container. Note that server defini= tions are only loaded on first launch, i.e. when the configuration database= is created, and not on subsequent launches using the same configuration da= tabase.
=3D=3D=3D=3D=3D

So the adver= tised feature is that we do only load the servers once into any given confi= guration database.
=C2=A0
=

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

Thanks,<= div>Yogesh Mahajan
EnterpriseDB


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


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

On Tue, Sep 3, 20= 24 at 1:47=E2=80=AFPM Dave Page <dpage@pgadmin.org> 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 config= uration results in duplicate server entries when a container with a mapped = servers.json file is restarted.


The prop= osed 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 se= rver already exists in the database. If it does, we would skip registering = it again.


Please share any suggestions or feedback o= n this approach.


I wo= uld say "Won't fix". If someone is using persistent storage f= or settings, why launch containers to import the same servers over and over= again? Just load them once, manually.=C2=A0
=
What if the container=C2=A0needs to be restarted? In that case it will= again import the server making a duplicate entry.

Not if the servers are manually imported rather t= han through servers.json.
=C2=A0
--
=
Dave Page
PostgreSQL: https://www.postgresql.o= rg

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/

--000000000000cbea530621356de8--