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

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 somewhere near that, though I have no specific idea. Per the

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

On Sun, May 7, 2023 at 10:23 AM Jeffrey Walton wrote: > This may be related... I seem to recall the GNUlib folks talking about > a cp bug on sparse files. It looks like it may be fixed in coreutils > release 9.2 (2023-03-20): > https://github.com/coreutils/coreutils/blob/master/NEWS#L233 > > If I

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

On Sat, May 6, 2023 at 6:35 AM Thomas Munro wrote: > > On Sat, May 6, 2023 at 9:58 PM Evgeny Morozov > wrote: > > Right - I should have realised that! base/1414389/2662 is indeed all > > nulls, 32KB of them. I included the file anyway in > > https://objective.realityexists.net/temp/pgstuff2.zip

Re: Check that numeric is zero

> "Gabriel" == Gabriel Furstenheim Milerud writes: Gabriel> Hi, Gabriel> I'm writing a Postgres native extension and I would like to Gabriel> check that a numeric is zero. Gabriel> My problem is that all exported methods like numeric_eq or Gabriel> numeric_sign require me to have a

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

On Sun, May 7, 2023 at 12:29 AM Evgeny Morozov wrote: > On 6/05/2023 12:34 pm, Thomas Munro wrote: > > So it does indeed look like something unknown has replaced 32KB of > > data with 32KB of zeroes underneath us. Are there more non-empty > > files that are all-zeroes? Something like this might

Re: Death postgres

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? 2) Restart the server? Your original post said the server crashed. If that

Check that numeric is zero

Hi, I'm writing a Postgres native extension and I would like to check that a numeric is zero. My problem is that all exported methods like numeric_eq or numeric_sign require me to have a numeric to start with, and const_zero is not exported in numeric.c. Any idea how to check it? Thanks Gabriel

Re: Death postgres

Le sam. 6 mai 2023 à 18:11, Adrian Klaver a écrit : > On 5/6/23 05:25, Marc Millas wrote: > > > > > > Le sam. 6 mai 2023 à 06:18, Adrian Klaver > > a écrit : > > > > On 5/5/23 18:14, Marc Millas wrote: > > > Hi, > > > > > > postgres 14.2 on

Re: Death postgres

On 5/6/23 05:25, Marc Millas wrote: Le sam. 6 mai 2023 à 06:18, Adrian Klaver > a écrit : On 5/5/23 18:14, Marc Millas wrote: > Hi, > > postgres 14.2 on Linux redhat > > temp_file_limit set around 210 GB. > > a select

Re: Death postgres

On 2023-05-05 21:14, Marc Millas wrote: Hi, 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 where postgres may grow

Re: Death postgres

On 5/6/23 08:52, Marc Millas wrote: Le sam. 6 mai 2023 à 15:15, Ron a écrit : [snip] If your question is about temp_file_limit, don't distract us with OOM issues. My question is how postgres can use space without caring about temp_file_limit. The oom info is kind of hint about

Re: Death postgres

Le sam. 6 mai 2023 à 15:15, Ron a écrit : > On 5/6/23 07:19, Marc Millas wrote: > > > > Le sam. 6 mai 2023 à 09:46, Peter J. Holzer a écrit : > >> On 2023-05-06 03:14:20 +0200, Marc Millas wrote: >> > postgres 14.2 on Linux redhat >> > >> > temp_file_limit set around 210 GB. >> > >> > a select

Re: Death postgres

Le sam. 6 mai 2023 à 15:15, Ron a écrit : > On 5/6/23 07:19, Marc Millas wrote: > > > > Le sam. 6 mai 2023 à 09:46, Peter J. Holzer a écrit : > >> On 2023-05-06 03:14:20 +0200, Marc Millas wrote: >> > postgres 14.2 on Linux redhat >> > >> > temp_file_limit set around 210 GB. >> > >> > a select

Re: Death postgres

On 5/6/23 07:19, Marc Millas wrote: Le sam. 6 mai 2023 à 09:46, Peter J. Holzer a écrit : On 2023-05-06 03:14:20 +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

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

On 6/05/2023 12:34 pm, Thomas Munro wrote: > So it does indeed look like something unknown has replaced 32KB of > data with 32KB of zeroes underneath us. Are there more non-empty > files that are all-zeroes? Something like this might find them: > > for F in base/1414389/* > do > if [ -s $F ]

Re: Death postgres

Le sam. 6 mai 2023 à 06:18, Adrian Klaver a écrit : > On 5/5/23 18:14, Marc Millas wrote: > > Hi, > > > > 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

Re: Death postgres

Le sam. 6 mai 2023 à 09:46, Peter J. Holzer a écrit : > On 2023-05-06 03:14:20 +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

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

On Sat, May 6, 2023 at 9:58 PM Evgeny Morozov wrote: > Right - I should have realised that! base/1414389/2662 is indeed all > nulls, 32KB of them. I included the file anyway in > https://objective.realityexists.net/temp/pgstuff2.zip OK so it's not just page 0, you have 32KB or 4 pages of all

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

On 6/05/2023 1:06 am, Thomas Munro wrote: > Next can you share the file base/1414389/2662? ("5" was from the wrong > database.) Right - I should have realised that! base/1414389/2662 is indeed all nulls, 32KB of them. I included the file anyway in

Re: Death postgres

On 2023-05-06 03:14:20 +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. temp_file_limit limits the space a