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.96) (envelope-from ) id 1vKN0n-009cZn-0f for pgsql-general@arkaria.postgresql.org; Sat, 15 Nov 2025 20:36:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vKN0j-00A4ow-0O for pgsql-general@arkaria.postgresql.org; Sat, 15 Nov 2025 20:36:41 +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.96) (envelope-from ) id 1vKN0i-00A4oo-2V for pgsql-general@lists.postgresql.org; Sat, 15 Nov 2025 20:36:40 +0000 Received: from uucp.dinoex.org ([2a0b:f840::12]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vKN0f-007JHP-2A for pgsql-general@lists.postgresql.org; Sat, 15 Nov 2025 20:36:39 +0000 Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.18.1/8.18.1) with ESMTPS id 5AFKa676077296 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 15 Nov 2025 21:36:07 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) ARC-Seal: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1763238970; cv=none; b=nnotAek0UBgm5nM4kKjsKDkOnwNb9v4z+nit09AIB4tWmfPXjVSrm32UScEW6F2w+R6SmoEfADCigO452iLI8PzvplgqbwniyNnVZiFWBgYLLAJCu6O1zg5r6dZlOxAPnQdBCV2GmIFOHSUN7NrP/VBztotyR8GvjWtZBsPgQIg= ARC-Message-Signature: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1763238970; c=relaxed/simple; bh=EzwvZuX3JJnpXHnicujRx76Pqe1jQSmNyct4uZ7OnJE=; h=Received:Received:Received:Received:X-Authentication-Warning:Date: From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:X-Milter:X-Greylist; b=HRYyUztAS+wWRvLPblVO3i3ZOyfryniVaX7jNIoelLgr1Wo2CGmnOcpDnVyKS4sIZ32atr2i2SmJ9TgjrVIFqFEm4jtkCUath5u2Na71SoZOkAI3jCkA5Pdk8dDFb2oTxywSKsltEWBQeL7inmdr8RvySlmIM5QJchtPi4c2w7k= ARC-Authentication-Results: i=1; uucp.dinoex.org Received: (from uucp@localhost) by uucp.dinoex.org (8.18.1/8.18.1/Submit) with UUCP id 5AFKa6j5077295; Sat, 15 Nov 2025 21:36:06 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.18.1/8.18.1) with ESMTPS id 5AFKSCON007043 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Sat, 15 Nov 2025 21:28:13 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.18.1/8.18.1) with ESMTPS id 5AFKPlAL082351 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 15 Nov 2025 21:25:47 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.18.1/8.18.1/Submit) id 5AFKPlgf082350; Sat, 15 Nov 2025 21:25:47 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Sat, 15 Nov 2025 21:25:47 +0100 From: "Peter 'PMc' Much" To: Adrian Klaver Cc: pgsql-general@lists.postgresql.org, laurenz.albe@cybertec.at Subject: Re: failure to drop table due to pg_temp_7 schema Message-ID: References: <8d0135f1-f69f-48bf-9956-9e64534cdf30@aklaver.com> <512ab673-06c3-408c-9e42-19427f9fa9df@aklaver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <512ab673-06c3-408c-9e42-19427f9fa9df@aklaver.com> X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Sat, 15 Nov 2025 21:36:10 +0100 (CET) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Nov 15, 2025 at 10:36:54AM -0800, Adrian Klaver wrote: ! On 11/15/25 10:10, Peter 'PMc' Much wrote: ! > On Sat, Nov 15, 2025 at 08:06:22AM -0800, Adrian Klaver wrote: ! > ! On 11/15/25 06:57, Peter 'PMc' Much wrote: ! > ! > ! > ! > Hi, ! > ! ! > ! > Que is this: https://github.com/que-rb/que ! > ! ! > ! Personally I would be more worried about an application ! > ! where the last commit was: ! > ! ! > ! Changelog: Add entry for version 2.4.1 ! > ! committed ! > ! on Oct 27, 2024. ! > ! > Really? I'd call that quite recently. ! > ! > And there is an explanation: Rails has dropped automated support ! > for Que. That doesn't matter to me, because I'm not using it in the ! > automated fashion. But it means the big user base is gone, and ! > therewith the influx of improvement desires. ! > ! > ! Makes you wonder what will happen if you upgrade to a newer version ! > ! of Postgres? ! > ! > I'll see when I'm there. Still have to wait for the new kerberos in ! > FreeBSD - there will be a lot more to mangle anyway. ! > ! > But speaking generally, I am quite bewildered that a simple tool ! > being stable for a year might already be considered worrisome. ! ! If the tool was self contained and did not rely on other software that might ! be alright. This tool does not, it has dependencies on Postgres and Rails ! and OS. They will be moving on. If you never change any of current versions ! of these then again you may be alright. Is that your intention? You're right in that regard, regular maintenance is necessary. But sadly, this is what people seem not so fond of doing, so we either get tools that constantly bring new features and are well maintained, or that lack in maintenance over all. ! Then there is the issue of issues: ! ! https://github.com/que-rb/que/issues ! ! The last one was closed Jan 30, 2024, with six new ones added since then and ! 37 open ones from before. The question is it moving from stable to moribund? ! Or more to the point are you willing to do your own tech support for the ! tool? In my case, absolutely the latter. :) I have local patchsets for the OS (mainly IPv6 firewalling stuff), for some applications, and have the tools to properly manage these modifications, i.e. local build&deploy, versioning etc. To me, it's a way to stay in control, to somehow surf the future shockwave. In this case, I looked into what Rails now supports as a scheduler, and found it too elabore (for now) to grok in-depth. And a small and a bit older tool has an advantage, that one can quite easily understand it and, if need arises, make it do what is locally required. So it's a balance. And in recent years, the modernizations often happened to curtate in delightfulness (with PostgreSQL sadly not being an exception). cheers, PMc ! ! ! ! > Normally, a new technology brings a vast amount of innovation for ! > the first or second decade, and then it starts to stabilize. ! > We in the IT do the opposite, we ever increase the change rate, ! > and I am wondering where this is supposed to lead. ! > ! > cheers, ! > PMc ! ! ! -- ! Adrian Klaver ! adrian.klaver@aklaver.com