Re: "PANIC: could not open critical system index 2662" - twice

On Mon, May 08, 2023 at 02:46:37PM +1200, Thomas Munro wrote: > That sounds like good news, but I'm still confused: do you see all 0s > in the target database (popo)'s catalogs, as reported (and if so can > you explain how they got there?), or is it regression that is > corrupted in more subtle way

Re: "PANIC: could not open critical system index 2662" - twice

On Mon, May 8, 2023 at 2:24 PM Michael Paquier wrote: > I can reproduce the same backtrace here. That's just my usual laptop > with ext4, so this would be a Postgres bug. First, here are the four > things running in parallel so as I can get a failure in loading a > critical index when connecting

Re: "PANIC: could not open critical system index 2662" - twice

On Sun, May 07, 2023 at 10:30:52PM +1200, Thomas Munro wrote: > Bug-in-PostgreSQL explanations could include that we forgot it was > dirty, or some backend wrote it out to the wrong file; but if we were > forgetting something like permanent or dirty, would there be a more > systematic failure? Oh,

Re: "PANIC: could not open critical system index 2662" - twice

On Mon, May 8, 2023 at 4:10 AM Evgeny Morozov wrote: > On 6/05/2023 11:13 pm, Thomas Munro wrote: > > Would you like to try requesting FILE_COPY for a while and see if it > > eventually happens like that too? > Sure, we can try that. Maybe you could do some one way and some the other, so that we

Re: Hung Query with No Locking Issues

"Michael P. McDonnell" writes: > On Sun, May 7, 2023 at 4:25 PM Tom Lane wrote: >> Perhaps an "ANALYZE table_b" in between would help. > Okay - that worked. > How did you know that would work? That's incredible. Well, I guessed ;-) ... but it was a well-educated guess. The symptoms sounded lik

Re: Hung Query with No Locking Issues

"Michael P. McDonnell" writes: > I have 2 stored procedures that need to run back to back. It could > convert to a single one - but it's easier from a maintenance perspective to > keep them separated. > The first procedure effectively is > INSERT INTO table_b () SELECT FROM _table_a_; > COMM

Hung Query with No Locking Issues

Hey team - I have 2 stored procedures that need to run back to back. It could convert to a single one - but it's easier from a maintenance perspective to keep them separated. The first procedure effectively is INSERT INTO table_b () SELECT FROM _table_a_; COMMIT; Total execution time - about

Re: Death postgres

On Sat, 2023-05-06 at 03:14 +0200, Marc Millas wrote: > postgres 14.2 on Linux redhat > > temp_file_limit set around 210 GB. > > a select request with 2 left join have crashed the server (oom killer) after > the postgres > disk occupation did grow from 15TB to 16 TB. > > What are the cases wher

Re: Death postgres

On 5/7/23 04:46, Marc Millas wrote: Le sam. 6 mai 2023 à 21:46, Adrian Klaver > a écrit : On 5/6/23 10:13, Marc Millas wrote: > > >     When you restarted the server where there any warnings shown? > > Sadly, I cannot. Will be do

Re: "PANIC: could not open critical system index 2662" - twice

On 6/05/2023 11:13 pm, Thomas Munro wrote: > Did you previously run this same workload on versions < 15 and never > see any problem? Yes, kind of. We have a test suite that creates one test DB and runs a bunch of tests on it. Two of these tests, however, create another DB each (also by cloning the

Re: Death postgres

Le sam. 6 mai 2023 à 21:46, Adrian Klaver a écrit : > On 5/6/23 10:13, Marc Millas wrote: > > > > > > > When you restarted the server where there any warnings shown? > > > > Sadly, I cannot. Will be done next tuesday. > > Cannot do what: > > 1) Get to the log to see if there are warnings? > >

Re: "PANIC: could not open critical system index 2662" - twice

On Sun, May 7, 2023 at 1:21 PM Tom Lane wrote: > Thomas Munro writes: > > Did you previously run this same workload on versions < 15 and never > > see any problem? 15 gained a new feature CREATE DATABASE ... > > STRATEGY=WAL_LOG, which is also the default. I wonder if there is a > > bug somewhe