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 1slQCX-007a3e-QR for pgadmin-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 09:51:54 +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 1slQCW-009jrN-Iz for pgadmin-hackers@arkaria.postgresql.org; Tue, 03 Sep 2024 09:51:52 +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 1slQCW-009jrF-8H for pgadmin-hackers@lists.postgresql.org; Tue, 03 Sep 2024 09:51:52 +0000 Received: from mail-yb1-xb36.google.com ([2607:f8b0:4864:20::b36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slQCS-000RGA-W9 for pgadmin-hackers@postgresql.org; Tue, 03 Sep 2024 09:51:51 +0000 Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-e1a9dc3efc1so2781622276.2 for ; Tue, 03 Sep 2024 02:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1725357107; x=1725961907; 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=JSs7vno5wkO/pKxLkPzdjdevWsbWrhdofVjF/dWPGmY=; b=Lj+07q0szdFrm5f8ZkElgUdmVn+/Fhn6MeYhnBMi75aAuVrcajp6dBauoaKMqyvCZU yQT5nHusomj33HW21D88YSAvwNctQIOTOUmOWlfXM2lO5699PqjT+EcZGEwpf5NPM8gY sxgUReFDQPzBhIstyKe3fHS9b1hKpmnOsvUesUvQuk6job3G3DUxlJ8CB40wkY5Hhjxj CQzQJKZB1La3/yp6UIi/G1c+eEf2UPJ8D7j4WFs2H3lfKAdrSonItMoRQ5vdkJk2CICU cRnLkVJC/DhFZnMRJ01HwZYjgPLlep3qLM5ms1SOJc5gu/3Z//sFyJY0P2tnnSZEQiJt kOjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725357107; x=1725961907; 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=JSs7vno5wkO/pKxLkPzdjdevWsbWrhdofVjF/dWPGmY=; b=RTo+0UL5Wj9i7gsy+1MXadR/HGHM4CwevXLtZNa2HeNXTaSXAEYhai0rQBR9BNXYFQ opzH2iy7b30nmFdq0g6e7ehRWEf2JaQDfcxBoknl4z60q2eOBX2eDxKtNJzh6RqhpRzb YPqsE4JsbJ4jrmBu+Nqnor8zX4lqq8Cz01mMYwuwZBPY+J57DLuOmn9+I1cpSCHKaOQH eXdM4kF+t/V+IgJwb+d7oZnqRxZjWNLhD2QYGI3s2VGEfFJs03VfE9zHkZ5nzCRuRVjh ZJenUU/u7i4eHQVxwzUNm+zA6DOOPICFJ7W+KfLUcvuG2dh6zeD16izR5wIPlsIfO1Vb +T5A== X-Forwarded-Encrypted: i=1; AJvYcCVyFNZ9WfSt1eflxiMqcEChY04/KTN3p5FXPDtw6pImLaSCCqeEvVERP7aTKAQkAM7NLRujj2YaWKfSTOW5BuE=@postgresql.org X-Gm-Message-State: AOJu0YxvXrTpHXAjoMr4KuV044gaMYaxi9OF/eswy3yvSwzegqb2+oKl YfiBDiBqj7UnPIaJ0ko9lYhE4Plhs+HLMrc24k/rKL5aSo4zkJPa5TFHaYKkz1NQswRd8nVPwv9 IQJIkfjj1msBNj2diZye5dc1P9npdQaYfRGzpUErhvkQ/svBchA== X-Google-Smtp-Source: AGHT+IEEd11TKqTskpIIdgFIc8/O6F2t0evwQ1v3g4mz554tkEX9PoDvpbCCta0ZSYARbSv6RvdUx2ktzLeYyLL2r68= X-Received: by 2002:a05:6902:15c3:b0:e11:7e64:175b with SMTP id 3f1490d57ef6-e1a7a1cd22bmr15370393276.53.1725357107033; Tue, 03 Sep 2024 02:51:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yogesh Mahajan Date: Tue, 3 Sep 2024 15:21:10 +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="00000000000079d6b3062134011b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000079d6b3062134011b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Yogesh Mahajan EnterpriseDB On Tue, Sep 3, 2024 at 3:11=E2=80=AFPM Dave Page wrote: 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 th= is >> 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 --repla= ce > 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. 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 on= ly > 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 wro= te: >> >>> >>> >>> 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 w= rote: >>>> >>>>> 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 du= plicate >>>>>> 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 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 o= ver >>>>> again? Just load them once, manually. >>>>> >>>> What if the container needs to be restarted? In that case it will agai= n >>>> 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/ > > --00000000000079d6b3062134011b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= div dir=3D"ltr" class=3D"gmail_signature">
Thanks,
Yo= gesh Mahajan
Enterprise= DB


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

Hi<= /div>
Hi

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

This isn't the issue in the ca= se of sqlite db while using persistent storage. Issue appears only if exter= nal database is used as pgadmin configuration db. Just having different way= =C2=A0of persistent storage( in this case backend database) behaviour shoul= d not be different.=C2=A0

No, the=C2=A0two database types should behave the same way. Why then, is P= ostgreSQL 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)?

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

However, I retract my previous comment (though if this were new behaviou= r, 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 def= initions are only loaded on first launch, i.e. when the configuration datab= ase is created, and not on subsequent launches using the same configuration= database.
=3D=3D=3D=3D=3D

So the ad= vertised feature is that we do only load the servers once into any given co= nfiguration database.
=C2=A0

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

Thanks,
Yogesh Mahajan
<= font face=3D"verdana, sans-serif">EnterpriseDB
=


On Tue, 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> wr= ote:
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 <= ;prave= sh.sharma@enterprisedb.com> wrote:
Hi Hackers,

I am working on issue <= a href=3D"https://github.com/pgadmin-org/pgadmin4/issues/7811" target=3D"_b= lank">#7811, where using an external database for storing pgAdmin confi= guration results in duplicate server entries when a container with a mapped= servers.json file is restarted.


The pro= posed solution is to implement a check when loading servers. We would verif= y the server=E2=80=99s name, host, port, and username to determine if the s= erver already exists in the database. If it does, we would skip registering= it again.


Please share any suggestions or feedback = on this approach.


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

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

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/

--00000000000079d6b3062134011b--