Re: Fixing or Mitigating this ERROR: invalid page in block 35217 of relation base/16421/3192429

On Thu, Nov 30, 2023 at 9:03 AM Abdul Qoyyuum wrote: > Hi Chris, > > On Wed, Nov 29, 2023 at 7:38 PM Chris Travers > wrote: > >> >> >> On Wed, Nov 29, 2023 at 4:36 PM Abdul Qoyyuum >> wrote: >> >>> Hi all, >>> >>> Knowing that it's a data corruption issue, the only way to fix this is >>> to vac

Re: Could not read from file "pg_subtrans/00F5" at offset 122880: Success.

At Wed, 29 Nov 2023 18:29:15 +0100, Alvaro Herrera wrote in > The code in master is completely different (it uses pg_pread rather than > seek + read): it does test for errno and reports accordingly. > > So, nothing to do here. Oops! Thank you and sorry for the noise. regards. -- Kyotaro Hor

Re: Removing oids with pg_repack

Στις 27/11/23 16:51, ο/η CG έγραψε: On Wednesday, November 22, 2023 at 12:38:54 PM EST, Achilleas Mantzios wrote: Στις 22/11/23 15:14, ο/η CG έγραψε: On Wednesday, November 22, 2023 at 01:20:18 AM EST, Achilleas Mantzios wrote: Στις 21/11/23

Re: Installing extension temporal_tables for PG13

On 11/28/2023 12:38 AM, Adrian Klaver wrote: > On 11/27/23 18:18, H wrote: >> On November 27, 2023 8:48:35 PM GMT-05:00, Adrian Klaver >> wrote: >>> On 11/27/23 17:41, H wrote: On 11/27/2023 08:38 PM, Adrian Klaver wrote: > On 11/27/23 17:17, H wrote: > >>> I don't use PGXN so I am flyin

RE: [EXT] Re: Query runtime differences- trying to understand why.

Sorry. DB is Aurora Postgres 14.6. Hints are enabled via extension pg_hint_plan. But my question isn't so much about the hints but the execution plan and where the time is going and why it appears for 1 execution of the query skipping locked rows seems to take a lot more time than another exe

Re: Query runtime differences- trying to understand why.

Am 29.11.23 um 21:25 schrieb Dirschel, Steve: I have a question on the execution time of a query and the fluctuations I'm seeing.  I enabled auto_trace to capture some actual executions of a query by an app.  Below are 2 executions of it.  The top one took 1.697 milliseconds. The 2nd one t

Query runtime differences- trying to understand why.

I have a question on the execution time of a query and the fluctuations I'm seeing. I enabled auto_trace to capture some actual executions of a query by an app. Below are 2 executions of it. The top one took 1.697 milliseconds. The 2nd one took 31.241 milliseconds. Note the query has hints

Re: Could not read from file "pg_subtrans/00F5" at offset 122880: Success.

On Wed, Nov 29, 2023 at 12:20 PM Sri Mrudula Attili wrote: > Hello Laurenz, > > > Thanks for your response. > > > This error we are seeing on a delphix Virtual database that was > refreshed using the snapshot of production standalone database. > > > It keeps the database in pg_start_backup and

Re: Could not read from file "pg_subtrans/00F5" at offset 122880: Success.

On 2023-Nov-28, Kyotaro Horiguchi wrote: > By the way, just out of curiosity, but errno should not be zero at the > time the message above was output, yet "%m" is showing "success", > which implies errno = 0 in Linux. How can that happen? If the file is exactly of the length given then seek will

Re: Could not read from file "pg_subtrans/00F5" at offset 122880: Success.

Hello Laurenz,  Thanks for your response. This error we are seeing on a delphix Virtual database that was refreshed using the snapshot of production standalone database. It keeps the database in pg_start_backup and to take the snapshot. I did check the dsource(production) database logs a

Re: Emitting JSON to file using COPY TO

Thanks for the responses everyone. I worked around the issue using the `psql -tc` method as Filip described. I think it would be great to support writing JSON using COPY TO at some point so I can emit JSON to files using a PostgreSQL function directly. -Davin On Tue, Nov 28, 2023 at 2:36 AM Fil

Re: Fixing or Mitigating this ERROR: invalid page in block 35217 of relation base/16421/3192429

On Wed, Nov 29, 2023 at 4:36 PM Abdul Qoyyuum wrote: > Hi all, > > Knowing that it's a data corruption issue, the only way to fix this is to > vacuum and reindex the database. What was suggested was the following: > > SET zero_damaged_pages = 0; # This is so that we can have the application > to

Re: Fixing or Mitigating this ERROR: invalid page in block 35217 of relation base/16421/3192429

Greetings, * Abdul Qoyyuum (aqoyy...@cardaccess.com.bn) wrote: > Knowing that it's a data corruption issue, the only way to fix this is to > vacuum and reindex the database. What was suggested was the following: > > SET zero_damaged_pages = 0; # This is so that we can have the application > to co

Fixing or Mitigating this ERROR: invalid page in block 35217 of relation base/16421/3192429

Hi all, Knowing that it's a data corruption issue, the only way to fix this is to vacuum and reindex the database. What was suggested was the following: SET zero_damaged_pages = 0; # This is so that we can have the application to continue to run VACUUM FULL VERBOSE ANALYSE; # Do a full vacuum and