Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kzBmG-00086f-Re for pgadmin-hackers@arkaria.postgresql.org; Tue, 12 Jan 2021 04:59:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kzBmF-0005aI-QI for pgadmin-hackers@arkaria.postgresql.org; Tue, 12 Jan 2021 04:59:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kzBmF-0005Zs-L8 for pgadmin-hackers@lists.postgresql.org; Tue, 12 Jan 2021 04:59:31 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kzBmD-0004Ov-6f for pgadmin-hackers@lists.postgresql.org; Tue, 12 Jan 2021 04:59:30 +0000 Received: by mail-lj1-x235.google.com with SMTP id n11so1436048lji.5 for ; Mon, 11 Jan 2021 20:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZFM5ihrZnvWU2JgxH0yYzLY+JI9+jIp9/loqh3MOJvk=; b=BDMj3gfOImgsGOuB1mbCvwoOoCgvnk9prA9JTSRm40Gipa1qvDlDWdKekyDYoj6lpF cIL07G0U8OA3OObVsV3aUDo9O3mXlGe4QA77Hi77o4BoRgxgzkSnAlfLQxHOrfGtD23V NSadapbRjp4JhEU9zkpOfvmfQAWxMZ9vb0bk+YW1woHDxHGtw4p9MDIjOzouJIS4rlJs BnwRExykdI7b+bpdjLoHIJ0SDdNIavtyU5AReMFc96JjGfU/MNL0cQ1Cerxg9hU6CnLg dRTW/6vZy4MyWVd2vFxwrp4J5uSNNv8AAXYCe0wqYtQg1teKcKxno82HgtIdKra54b4s vhhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZFM5ihrZnvWU2JgxH0yYzLY+JI9+jIp9/loqh3MOJvk=; b=MyGeYh5TMuCeaowY+zGNo6yeu2CMaAgwLyD8hk5Eihe1vEjq0Wckt3sv5X5yRDoID8 5ttNayuQg4NLNnpGfdAdwOhDpPQTv+4ZEnATf0cNFZYJ0qS0uO4LMGO1bSd0zO2HZjQu TtdS0dVqxxNIR8Jfm2J9+CTUdxY4DPNPTOZHjR05bVvWOi2dy/0rrek06awaGRzuROJl k34JZX5aFBnXhmmx37+v+FKgW3OoLJP0EXcijgqx7HXQOEfqbAWqARcG8EgVCJzHwZBo 6Pdvd7BBNPiMZq9M1ypfU8gZ9RbPhZhcfxuYp5FinaWEi5Qce3lnRqKH+lxWxOrsoJXr uYBA== X-Gm-Message-State: AOAM532X6zX28YOlFT3p3Pp+37RCxWZojRbs3wHc3cp1kan0q9yA+Dw9 CJXd/UXnMu9CYFsJZVxwRfB0IyqC9ur/MKLWTJ1rZITJzV6QM6w7BNrQZcCsynyq4EtbRdhPE02 bJ8EAc7zbwJJzcUQG8nF3vA6bX7oP+VL7uaxkKkI/kv6KNFzaRijYIuuOzTY3cdTpvwHpV5u0RS Mo7WQt7L5GV3BTFBF8nNt0QTAbriSme9DP1d9L/y+cnG40q+dkCdOqExOCHpO9GhBQ5BrmyHnWh bkKKOFNwQOp X-Google-Smtp-Source: ABdhPJwxh7bUwobhBRYWZNZfn3/8eUKPxBCDeKj29wNq1CV08FXk3eX3ndu8IjJKhKZvV8f31QITeYn9V2btWvgUlVo= X-Received: by 2002:a2e:9792:: with SMTP id y18mr1228579lji.204.1610427566137; Mon, 11 Jan 2021 20:59:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Khushboo Vashi Date: Tue, 12 Jan 2021 10:29:24 +0530 Message-ID: Subject: Re: Somewhat excessive version checks To: Magnus Hagander Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000043b2905b8ace313" X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000043b2905b8ace313 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 12, 2021 at 3:36 AM Magnus Hagander wrote: > Hi! > > If I read the code correctly, pgadmin will (unless turned off) hit the > website to check the version.json file for updates *every time it > starts*. > > Wouldn't it make sense to rate limit that to checking say once per 24 > hours maximum? Or even 48? > > It seems nobody needs the update *that* quickly, and AFAICT it does > call out to make that check synchronously on startup which means the > user is waiting. > > Agreed, we should have some mechanism in place to limit the server hit, maybe an asynchronous call from the client while loading. > And if/when doing that, it would be useful to include an > If-Modified-Since header on the request, so the server can just > respond with a tiny 304 reply when there is no update, which is going > to be the majority of the time. Or possibly even more efficiently, > create a custom etag and use If-None-Matches. If you make that etag be > say the version that the client has, it becomes very cheap to check > and you don't need to track any extra data. > > -- > Magnus Hagander > Me: https://www.hagander.net/ > Work: https://www.redpill-linpro.com/ > > > --000000000000043b2905b8ace313 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


--000000000000043b2905b8ace313--