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 1slQ36-007Yez-K8 for pgadmin-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 09:42:09 +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 1slQ35-009eT2-Lt for pgadmin-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 09:42:07 +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 1slQ2Z-009cFv-Vh for pgadmin-hackers@lists.postgresql.org; Tue, 03 Sep 2024 09:41:36 +0000 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slQ2X-000RBu-2V for pgadmin-hackers@postgresql.org; Tue, 03 Sep 2024 09:41:35 +0000 Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-53346132365so6300273e87.1 for ; Tue, 03 Sep 2024 02:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1725356492; x=1725961292; 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=Kz0uqp2it/aC5M6B3ITus56MdpuFOAxYC3PP8WcRDms=; b=Uf53KjL9w3MTG4WRpkfHBTkk7hCU62KSmHtCrizzOpXfG7wf6g7DXNW+o/yfCizPa8 YENd+YLy3O5zhjLLcp4dLxdIZWLYZ2XC1qdgt46Nm5DKATp9gnYVZkppvOg+l6+85rmY 2s7PySvMBNgfxkIjJl9uFdXHM2BTpxuRwhPEzJh++EvnkcH7OsNJFaM825Tk4M0fiGSC IDdndaECN+vnvXLBBOMjmhKegCgZXclTPzbi/hypOg2zC3jr4IyYCZf33AyzXU0qDbX7 /LfH08ur/LU5R0zV8jExAFcT1GzZldoGW+l5hEh0gfHQsa/aleiDBtmSxefR4iJF4UCo MxJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725356492; x=1725961292; 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=Kz0uqp2it/aC5M6B3ITus56MdpuFOAxYC3PP8WcRDms=; b=mxY6PEOzyoFehscLSllPsFO6l2nSt/FXouMOyfspy7qVKxTWXLKqJXLC+PV2QcyM6N KUiVYFt2giFBSp4RpA8J0oBG6NMqjvNOOdsfZwcfiOMs+MADESREz5NWNsVUxV3uPRQ6 nBK4lnHjfvcUH5yzeyebFRf1Dw9cLWd0E8dLGPxHWFJwopokOZu5zNVaIYAT7DYFsqTs tnqTU8HhZs5/hfdjF1oHI99VxQi85URlrQ1sSNJSSXLqXHSIiHxtf8VLTrDylh7DPTHb HZKublyIQUYf1OrVUdO6S38x8f+Tiw9LEgWG8iMzjdHbaFZgSKcLGtEtCLLEfwDSSRJl mDQQ== X-Forwarded-Encrypted: i=1; AJvYcCW+dgQRhTHguGEomReB1SDI0JX4YwYDW534V0NpktdwOrhC+0Re8S56AsRex9Wtygu5Kz5kGy/OSsXptr6Xuwk=@postgresql.org X-Gm-Message-State: AOJu0YxhCnJVhjz6jkKnDsy+OWFi2Bl+M1quJ2T4I9UCeEZqooaBnDgH tYwRx6/uc4c6R4OnlMbNVPDuQPQ9FeFUIh0x2e/+NC5U0X3hmOVWR6nbLrbAlHz0mN4uroEpY1O cjOCzK80Eolm05zvsE6PoTllnYq8DtXEkgE2aQkJp8DIQCDcCbQ== X-Google-Smtp-Source: AGHT+IFhQBOHK9kOqX5ShMQmwmOQ5Tk7uqg54O8qu2lOik4ztqqbHvKsiWwDna0GPUYQ5h0ZWBrqMZuwaraSdiVlzDY= X-Received: by 2002:ac2:4c54:0:b0:52c:df51:20bc with SMTP id 2adb3069b0e04-53546b060ccmr10151767e87.16.1725356492023; Tue, 03 Sep 2024 02:41:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Tue, 3 Sep 2024 10:41:21 +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="000000000000d180a2062133dcc2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d180a2062133dcc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 thi= s > 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 --replace option whilst PostgreSQL is not (though I can't imagine why that would be the case)? 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 the 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 wrot= e: > >> >> >> 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 wr= ote: >>> >>>> 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 duplic= ate >>>>> server entries when a container with a mapped servers.json file is >>>>> restarted. >>>>> >>>>> The proposed solution is to implement a check when loading servers. W= e >>>>> 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 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 ov= er >>>> 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.jso= n. >> >> -- >> 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/ --000000000000d180a2062133dcc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Tue, 3 Sept 2024 at 10:32, Yogesh Mahajan <yogesh.mahajan@enterprised= b.com> wrote:
Hi Dave= ,

This isn&= #39;t the issue in the case of sqlite db while using persistent storage. Is= sue appears only if external database is used as pgadmin configuration db. = Just having different way=C2=A0of persistent storage( in this case backend = database) behaviour should not be different.=C2=A0

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

However, I = retract my previous comment (though if this were new behaviour, perhaps I w= ouldn'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 on= ly loaded on first launch, i.e. when the configuration database is created,= and not on subsequent launches using the same configuration database.
<= /div>
=3D=3D=3D=3D=3D

So the advertised featur= e is that we do only load the servers once into any given configuration dat= abase.
=C2=A0

Also, on re= start admin user specified while container is not recreated. Can't we f= ix on similar lines?

Thanks,
Yogesh Mahajan
EnterpriseDB


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


On Tue, 3 Sept 2024 at 09= :29, Pravesh Sharma <pravesh.sharma@enterprisedb.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
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, Pravesh Sharma <pravesh.sharma@e= nterprisedb.com> wrote:
H= i Hackers,

I am working on issue #7811= , where using an external database for storing pgAdmin configuration re= sults in duplicate server entries when a container with a mapped servers.js= on file is restarted.


The proposed solut= ion is to implement a check when loading servers. We would verify the serve= r=E2=80=99s name, host, port, and username to determine if the server alrea= dy exists in the database. If it does, we would skip registering it again.<= /p>


Please share any suggestions or feedback on this app= roach.


I would say &q= uot;Won't fix". If someone is using persistent storage for setting= s, why launch containers to import the same servers over and over again? Ju= st load them once, manually.=C2=A0
What = if the container=C2=A0needs to be restarted? In that case it will again imp= ort the server making a duplicate entry.

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

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/

--000000000000d180a2062133dcc2--