Subject: Re: failure to drop table due to pg_temp_7 schema

From: Adrian Klaver <[email-masked]>
Date: Sat, 15 Nov 2025 10:36:54 -0800

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?

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?

> 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
[email-masked]

---

From: "Peter 'PMc' Much" <[email-masked]>
Date: Sat, 15 Nov 2025 21:25:47 +0100

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
! [email-masked]

---

From: Adrian Klaver <[email-masked]>
Date: Sat, 15 Nov 2025 14:10:49 -0800

> often happened to curtate in delightfulness (with PostgreSQL sadly

Where is delightfulness short changed in?:

https://www.postgresql.org/docs/18/release-18.html#RELEASE-18-HIGHLIGHTS

---

From: "Peter 'PMc' Much" <[email-masked]>
Date: Mon, 17 Nov 2025 23:08:17 +0100

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

! > 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).
! 
! 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. 

Recap: The last time I was really overjoyed, that was when
Erwin Brandstetter showed me about window functions and with-
clauses, and what they can do:
        https://stackoverflow.com/a/36659866/6201427
I didn't understand that immediately (because when you do
everything, and try to do it in-depth, you cannot do it quickly also,
you have to choose two of these three). But it was that feeling,
wow, there are things to learn, and it will get better and better.

Now for the downside, there are these usual sources of frustration
that just do happen. For instance, whenever I get into the mood
of doing a bit of lengthy SQL coding, I end up at the point where
some erratic fluctuations of execution times appear, like 50 vs.
2000 ms for the same query with roughly the same amount of rows,
just some different timestamps in the payload.
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.

The greater trouble comes from things being "improved" to
cater for stupidity. In most cases that doesn't make things better.
And the postgtreSQL example for this would be the backup scheme - 
that is a funny little story about how to overwrite your production
database (well, if you consider that funny):

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.

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.)

So I created some filespaces and did the test restore. All went
fine, so far. I carefully read the manual (section 26.3.4. in the
Rel.15 manual) and noticed item 4:

         If you are using tablespaces, you should verify that the
         symbolic links in pg_tblspc/ were correctly restored.

Oh yes, I thought, a good point! They were obviousely NOT correct
for a test restore: they pointed into the production tablespace.
I fixed them appropriately, and assumed that should do the trick.
Then I started the rollforward show.

Some one or two hours into the flight, I was wondering why my test
partitions had no disk traffic. Then I noticed that my production
tablespaces had a lot of disk traffic.

And then I figured the rest: the new backup scheme requires that a
file "tablespace_map" gets included in the backup. And then obviousely
also in the restore. The server had found that file, had happily
deleted my carefully crafted symlinks and replaced them with some
new ones created from that file - which now again pointed into
the *production* filespace.
And that was it with the production database.

Crap, I thought - I told them not to do it. They did it nevertheless,
"for safety", as they said. And now we see what that "safety" can do.

Corrollary: Its the same as with the public transport here. I tell
them, that doesn't work, they say "don't worry and shut up", and in
the end I have to pay the price. (Specifically, they wanted to switch
from paper tickets to chipcard. I said, as a passenger I cannot ensure
that such a chipcard would work correctly, because I didn't build it
and not even have means check if it is working. Doesn't matter, they
said, for the customer nothing does change. It took about two years
for that cheapest-vendor-chip to go dead, and then they charged me
penalty. See our terms of service, they said: when the chip doesn't
work, then you have failed to present a valid ticket and therefore
are a fare dodger and get punished.)

Well, over all, nothing really bad had happened. I did another, real
restore, and found that there hadn't been any transactions in the
critical timeframe - because the timeline didn't switch.
(That's another little gotcha: if we do point-in-time restore,
and give a point-in-time that is *after* the last recorded
transaction, then the rollforward does not fully complete, and
the timeline does not switch. But the stuff works nevertheless.)

cheers,
PMc

---

From: Adrian Klaver <[email-masked]>
Date: Mon, 17 Nov 2025 14:59:34 -0800

> 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.

> 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.

> 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?

> logical proof that the correct data is saved to the correct place,

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.