Feedback-ID: i76984098:Fastmail
Message-ID: <bec72986-441f-40ce-845d-638fb64a829e@aklaver.com>
Date: Mon, 17 Nov 2025 14:59:34 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: failure to drop table due to pg_temp_7 schema
To: Peter 'PMc' Much <pmc@citylink.dinoex.sub.org>
Cc: pgsql-general@lists.postgresql.org, laurenz.albe@cybertec.at
References: <aRiU72GYiytZUyQv@disp.intra.daemon.contact>
 <8d0135f1-f69f-48bf-9956-9e64534cdf30@aklaver.com>
 <aRjCLWBJ5AQnc5B5@disp.intra.daemon.contact>
 <512ab673-06c3-408c-9e42-19427f9fa9df@aklaver.com>
 <aRjhy2ptAitfxUML@disp.intra.daemon.contact>
 <26adadfe-6c51-4154-8ce1-409c2b800a29@aklaver.com>
 <aRuc0d0n5VbHT5nI@disp.intra.daemon.contact>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <aRuc0d0n5VbHT5nI@disp.intra.daemon.contact>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/bec72986-441f-40ce-845d-638fb64a829e%40aklaver.com>
Precedence: bulk

On 11/17/25 14:08, Peter 'PMc' Much wrote:
> On Sat, Nov 15, 2025 at 02:10:49PM -0800, Adrian Klaver wrote:

> ! Where is delightfulness short changed in?:
> !
> ! https://www.postgresql.org/docs/18/release-18.html#RELEASE-18-HIGHLIGHTS
> 
> Oh yes, these are fine things, and I know people will be delighted.
> But, honestly, none of them would make me upgrade, as I do not
> currently have a specific usecase.

Alright so what makes you happy. The chance the project make everyone 
happy for any given release is slim to none. That is the consequence of 
developing a general purpose piece of software.


> But these things do happen, the web has a lot of articles on
> switching off nestloop, and you can't store statistics for a CTE
> before invoking the query.

Your problem description is sort of broad, have you tried MATERIALIZED 
or NOT MATERIALIZED as the case may be?

Otherwise start a new thread with a more complete description of the 
issue including EXPLAIN ANALYZE that might help folks troubleshoot the 
problem.


> 
> With Rel.13 came a new fashion of backup, and I was against it.
> I think I mentioned it here, and that was not well received - it's
> necessary for safety, was the bottomline.

What new fashion of backup and what is your issue with it?

Why could you not use an older type of backup?

> 
> So I sat down and wrote the new backup routine, all precisely
> according to the book - since my backup tool didn't have
> anything suitable to offer, at that time.
> Then finally, last year or so, they (Bareos) came along with a proper
> backup routine, and I wanted to switch. But before retiring my own
> script, I wanted to see if the restore would actually work as smooth
> as I had imagined. (I do not normally do restore tests, I think the
> logical proof that the correct data is saved to the correct place,
> should suffice.)

To me, "...correct data is saved to the correct place, ...",  is only 
correct if you can use it to recreate the database instance or the 
entire cluster. In other words prove the restore process works.


> cheers,
> PMc


-- 
Adrian Klaver
adrian.klaver@aklaver.com