pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedUrgent !!!! Tables inaccessible postgres v17.6
15+ messages / 6 participants
[nested] [flat]
* Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-06 14:11 mahamood hussain <hussain.ieg@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: mahamood hussain @ 2026-08-06 14:11 UTC (permalink / raw)
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Hi Team,
I need some urgent help. I'm unable to access one of the tables. Even a
simple SELECT statement fails with the error below. Could someone please
help investigate and fix this issue?
prod=# SELECT count(*) FROM schema.tablename;
WARNING: page verification failed, calculated checksum 50897 but expected 50048
ERROR: invalid page in block 696770 of relation base/16388/447758
CONTEXT: parallel worker
Any assistance would be greatly appreciated. Thanks!
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-06 14:16 Ron Johnson <ronljohnsonjr@gmail.com>
parent: mahamood hussain <hussain.ieg@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Ron Johnson @ 2026-08-06 14:16 UTC (permalink / raw)
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
On Thu, Aug 6, 2026 at 10:11 AM mahamood hussain <hussain.ieg@gmail.com>
wrote:
> Hi Team,
>
> I need some urgent help. I'm unable to access one of the tables. Even a
> simple SELECT statement fails with the error below. Could someone please
> help investigate and fix this issue?
>
> prod=# SELECT count(*) FROM schema.tablename;
>
> WARNING: page verification failed, calculated checksum 50897 but expected 50048
> ERROR: invalid page in block 696770 of relation base/16388/447758
> CONTEXT: parallel worker
>
> Any assistance would be greatly appreciated. Thanks!
>
* Have you tested your backup/restore process lately?
* How old is the latest backup?
* Do the system logs show any errors around that time?
* What kind of disks do you have? One might be dying.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-06 14:27 mahamood hussain <hussain.ieg@gmail.com>
parent: Ron Johnson <ronljohnsonjr@gmail.com>
0 siblings, 2 replies; 15+ messages in thread
From: mahamood hussain @ 2026-08-06 14:27 UTC (permalink / raw)
To: Ron Johnson <ronljohnsonjr@gmail.com>; Pgsql-admin <pgsql-admin@lists.postgresql.org>
Hi Ron,
Thanks for the quick response.
Unfortunately, I do have backups, but they're also reporting the same
checksum error.
full backup: 20260801-203001F
timestamp start/stop: 2026-08-01 20:30:01-07 / 2026-08-01
21:30:23-07
wal start/stop: 00000001000007F900000055 /
000000010000080800000030
database size: 1403.4GB, database backup size: 1403.4GB
repo1: backup set size: 197.7GB, backup size: 197.7GB
diff backup: 20260801-203001F_20260802-023002D
timestamp start/stop: 2026-08-02 02:30:02-07 / 2026-08-02
02:35:44-07
wal start/stop: 000000010000086A000000B6 /
000000010000086A000000B6
database size: 1407.7GB, database backup size: 221.5GB
repo1: backup set size: 198.8GB, backup size: 28.6GB
backup reference total: 1 full
error(s) detected during backup
Our backup strategy is weekly full backups with daily incremental backups.
The database is hosted on Azure Premium SSD v2, using four striped disks.
How serious does this look to you? Do you have any recommendations on the
fastest way to recover from this? At the moment, I'm concerned that both
the production copy and the backups appear to be affected.
On Thu, Aug 6, 2026 at 7:47 PM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
> On Thu, Aug 6, 2026 at 10:11 AM mahamood hussain <hussain.ieg@gmail.com>
> wrote:
>
>> Hi Team,
>>
>> I need some urgent help. I'm unable to access one of the tables. Even a
>> simple SELECT statement fails with the error below. Could someone please
>> help investigate and fix this issue?
>>
>> prod=# SELECT count(*) FROM schema.tablename;
>>
>> WARNING: page verification failed, calculated checksum 50897 but expected 50048
>> ERROR: invalid page in block 696770 of relation base/16388/447758
>> CONTEXT: parallel worker
>>
>> Any assistance would be greatly appreciated. Thanks!
>>
>
> * Have you tested your backup/restore process lately?
> * How old is the latest backup?
> * Do the system logs show any errors around that time?
> * What kind of disks do you have? One might be dying.
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-06 14:43 Ron Johnson <ronljohnsonjr@gmail.com>
parent: mahamood hussain <hussain.ieg@gmail.com>
1 sibling, 1 reply; 15+ messages in thread
From: Ron Johnson @ 2026-08-06 14:43 UTC (permalink / raw)
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Hmm.
If base/16388/447758 is an index, then you could just drop it and recreate
it, but you're probably not that lucky.
How big is the table? Using a binary search method with ORDER BY and
OFFSET, you can find the records on the offending page. Exclude them when
doing a COPY TO, then recreate the table.
And, of course, upgrade to 17.10.
On Thu, Aug 6, 2026 at 10:27 AM mahamood hussain <hussain.ieg@gmail.com>
wrote:
> Hi Ron,
>
> Thanks for the quick response.
>
> Unfortunately, I do have backups, but they're also reporting the same
> checksum error.
> full backup: 20260801-203001F
> timestamp start/stop: 2026-08-01 20:30:01-07 / 2026-08-01
> 21:30:23-07
> wal start/stop: 00000001000007F900000055 /
> 000000010000080800000030
> database size: 1403.4GB, database backup size: 1403.4GB
> repo1: backup set size: 197.7GB, backup size: 197.7GB
>
> diff backup: 20260801-203001F_20260802-023002D
> timestamp start/stop: 2026-08-02 02:30:02-07 / 2026-08-02
> 02:35:44-07
> wal start/stop: 000000010000086A000000B6 /
> 000000010000086A000000B6
> database size: 1407.7GB, database backup size: 221.5GB
> repo1: backup set size: 198.8GB, backup size: 28.6GB
> backup reference total: 1 full
> error(s) detected during backup
>
> Our backup strategy is weekly full backups with daily incremental backups.
>
> The database is hosted on Azure Premium SSD v2, using four striped disks.
>
> How serious does this look to you? Do you have any recommendations on the
> fastest way to recover from this? At the moment, I'm concerned that both
> the production copy and the backups appear to be affected.
>
> On Thu, Aug 6, 2026 at 7:47 PM Ron Johnson <ronljohnsonjr@gmail.com>
> wrote:
>
>> On Thu, Aug 6, 2026 at 10:11 AM mahamood hussain <hussain.ieg@gmail.com>
>> wrote:
>>
>>> Hi Team,
>>>
>>> I need some urgent help. I'm unable to access one of the tables. Even a
>>> simple SELECT statement fails with the error below. Could someone
>>> please help investigate and fix this issue?
>>>
>>> prod=# SELECT count(*) FROM schema.tablename;
>>>
>>> WARNING: page verification failed, calculated checksum 50897 but expected 50048
>>> ERROR: invalid page in block 696770 of relation base/16388/447758
>>> CONTEXT: parallel worker
>>>
>>> Any assistance would be greatly appreciated. Thanks!
>>>
>>
>> * Have you tested your backup/restore process lately?
>> * How old is the latest backup?
>> * Do the system logs show any errors around that time?
>> * What kind of disks do you have? One might be dying.
>>
>> --
>> Death to <Redacted>, and butter sauce.
>> Don't boil me, I'm still alive.
>> <Redacted> lobster!
>>
>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-06 14:57 mahamood hussain <hussain.ieg@gmail.com>
parent: Ron Johnson <ronljohnsonjr@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: mahamood hussain @ 2026-08-06 14:57 UTC (permalink / raw)
To: Ron Johnson <ronljohnsonjr@gmail.com>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Thanks for the suggestion. I confirmed that base/16388/447758 is the heap
file for table, so unfortunately it isn't an index that can simply be
rebuilt.
heap_size | index_size | total_size
-----------+------------+------------
11 GB | 5694 MB | 17 GB
I'm fairly new to PostgreSQL, so could you provide a bit more context on
the binary search approach you mentioned? I'd appreciate it if you could
explain the steps involved and how it helps identify the records on the
corrupted page.
Regarding your last point, do you think this corruption could be related to
the PostgreSQL version we're currently running? Is this a known issue that
has been fixed in PostgreSQL 17.10, or are you recommending the upgrade
simply because we're not on the latest minor release?
Also, could you help me understand what typically causes page corruption
like this? Are there common root causes, and what best practices or
preventive measures would you recommend to minimize the risk of this
happening in the future?
On Thu, Aug 6, 2026 at 8:14 PM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
> Hmm.
>
> If base/16388/447758 is an index, then you could just drop it and
> recreate it, but you're probably not that lucky.
>
> How big is the table? Using a binary search method with ORDER BY and
> OFFSET, you can find the records on the offending page. Exclude them when
> doing a COPY TO, then recreate the table.
>
> And, of course, upgrade to 17.10.
>
> On Thu, Aug 6, 2026 at 10:27 AM mahamood hussain <hussain.ieg@gmail.com>
> wrote:
>
>> Hi Ron,
>>
>> Thanks for the quick response.
>>
>> Unfortunately, I do have backups, but they're also reporting the same
>> checksum error.
>> full backup: 20260801-203001F
>> timestamp start/stop: 2026-08-01 20:30:01-07 / 2026-08-01
>> 21:30:23-07
>> wal start/stop: 00000001000007F900000055 /
>> 000000010000080800000030
>> database size: 1403.4GB, database backup size: 1403.4GB
>> repo1: backup set size: 197.7GB, backup size: 197.7GB
>>
>> diff backup: 20260801-203001F_20260802-023002D
>> timestamp start/stop: 2026-08-02 02:30:02-07 / 2026-08-02
>> 02:35:44-07
>> wal start/stop: 000000010000086A000000B6 /
>> 000000010000086A000000B6
>> database size: 1407.7GB, database backup size: 221.5GB
>> repo1: backup set size: 198.8GB, backup size: 28.6GB
>> backup reference total: 1 full
>> error(s) detected during backup
>>
>> Our backup strategy is weekly full backups with daily incremental backups.
>>
>> The database is hosted on Azure Premium SSD v2, using four striped disks.
>>
>> How serious does this look to you? Do you have any recommendations on the
>> fastest way to recover from this? At the moment, I'm concerned that both
>> the production copy and the backups appear to be affected.
>>
>> On Thu, Aug 6, 2026 at 7:47 PM Ron Johnson <ronljohnsonjr@gmail.com>
>> wrote:
>>
>>> On Thu, Aug 6, 2026 at 10:11 AM mahamood hussain <hussain.ieg@gmail.com>
>>> wrote:
>>>
>>>> Hi Team,
>>>>
>>>> I need some urgent help. I'm unable to access one of the tables. Even a
>>>> simple SELECT statement fails with the error below. Could someone
>>>> please help investigate and fix this issue?
>>>>
>>>> prod=# SELECT count(*) FROM schema.tablename;
>>>>
>>>> WARNING: page verification failed, calculated checksum 50897 but expected 50048
>>>> ERROR: invalid page in block 696770 of relation base/16388/447758
>>>> CONTEXT: parallel worker
>>>>
>>>> Any assistance would be greatly appreciated. Thanks!
>>>>
>>>
>>> * Have you tested your backup/restore process lately?
>>> * How old is the latest backup?
>>> * Do the system logs show any errors around that time?
>>> * What kind of disks do you have? One might be dying.
>>>
>>> --
>>> Death to <Redacted>, and butter sauce.
>>> Don't boil me, I'm still alive.
>>> <Redacted> lobster!
>>>
>>
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-06 15:11 Ron Johnson <ronljohnsonjr@gmail.com>
parent: mahamood hussain <hussain.ieg@gmail.com>
0 siblings, 2 replies; 15+ messages in thread
From: Ron Johnson @ 2026-08-06 15:11 UTC (permalink / raw)
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
On Thu, Aug 6, 2026 at 10:57 AM mahamood hussain <hussain.ieg@gmail.com>
wrote:
> Thanks for the suggestion. I confirmed that base/16388/447758 is the heap
> file for table, so unfortunately it isn't an index that can simply be
> rebuilt.
>
> heap_size | index_size | total_size
> -----------+------------+------------
> 11 GB | 5694 MB | 17 GB
>
> I'm fairly new to PostgreSQL, so could you provide a bit more context on
> the binary search approach you mentioned? I'd appreciate it if you could
> explain the steps involved and how it helps identify the records on the
> corrupted page.
>
They don't teach the binary search algorithm in Comp Sci anymore? ☹️
Anyway... use ORDER BY, OFFSET, LIMIT and the ROW_NUMBER() function to find
the offending records via "divide and conquer".
> Regarding your last point, do you think this corruption could be related
> to the PostgreSQL version we're currently running? Is this a known issue
> that has been fixed in PostgreSQL 17.10, or are you recommending the
> upgrade simply because we're not on the latest minor release?
>
> Also, could you help me understand what typically causes page corruption
> like this? Are there common root causes, and what best practices or
> preventive measures would you recommend to minimize the risk of this
> happening in the future?
>
> On Thu, Aug 6, 2026 at 8:14 PM Ron Johnson <ronljohnsonjr@gmail.com>
> wrote:
>
>> Hmm.
>>
>> If base/16388/447758 is an index, then you could just drop it and
>> recreate it, but you're probably not that lucky.
>>
>> How big is the table? Using a binary search method with ORDER BY and
>> OFFSET, you can find the records on the offending page. Exclude them when
>> doing a COPY TO, then recreate the table.
>>
>> And, of course, upgrade to 17.10.
>>
>> On Thu, Aug 6, 2026 at 10:27 AM mahamood hussain <hussain.ieg@gmail.com>
>> wrote:
>>
>>> Hi Ron,
>>>
>>> Thanks for the quick response.
>>>
>>> Unfortunately, I do have backups, but they're also reporting the same
>>> checksum error.
>>> full backup: 20260801-203001F
>>> timestamp start/stop: 2026-08-01 20:30:01-07 / 2026-08-01
>>> 21:30:23-07
>>> wal start/stop: 00000001000007F900000055 /
>>> 000000010000080800000030
>>> database size: 1403.4GB, database backup size: 1403.4GB
>>> repo1: backup set size: 197.7GB, backup size: 197.7GB
>>>
>>> diff backup: 20260801-203001F_20260802-023002D
>>> timestamp start/stop: 2026-08-02 02:30:02-07 / 2026-08-02
>>> 02:35:44-07
>>> wal start/stop: 000000010000086A000000B6 /
>>> 000000010000086A000000B6
>>> database size: 1407.7GB, database backup size: 221.5GB
>>> repo1: backup set size: 198.8GB, backup size: 28.6GB
>>> backup reference total: 1 full
>>> error(s) detected during backup
>>>
>>> Our backup strategy is weekly full backups with daily incremental
>>> backups.
>>>
>>> The database is hosted on Azure Premium SSD v2, using four striped disks.
>>>
>>> How serious does this look to you? Do you have any recommendations on
>>> the fastest way to recover from this? At the moment, I'm concerned that
>>> both the production copy and the backups appear to be affected.
>>>
>>> On Thu, Aug 6, 2026 at 7:47 PM Ron Johnson <ronljohnsonjr@gmail.com>
>>> wrote:
>>>
>>>> On Thu, Aug 6, 2026 at 10:11 AM mahamood hussain <hussain.ieg@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Team,
>>>>>
>>>>> I need some urgent help. I'm unable to access one of the tables. Even
>>>>> a simple SELECT statement fails with the error below. Could someone
>>>>> please help investigate and fix this issue?
>>>>>
>>>>> prod=# SELECT count(*) FROM schema.tablename;
>>>>>
>>>>> WARNING: page verification failed, calculated checksum 50897 but expected 50048
>>>>> ERROR: invalid page in block 696770 of relation base/16388/447758
>>>>> CONTEXT: parallel worker
>>>>>
>>>>> Any assistance would be greatly appreciated. Thanks!
>>>>>
>>>>
>>>> * Have you tested your backup/restore process lately?
>>>> * How old is the latest backup?
>>>> * Do the system logs show any errors around that time?
>>>> * What kind of disks do you have? One might be dying.
>>>>
>>>> --
>>>> Death to <Redacted>, and butter sauce.
>>>> Don't boil me, I'm still alive.
>>>> <Redacted> lobster!
>>>>
>>>
>>
>> --
>> Death to <Redacted>, and butter sauce.
>> Don't boil me, I'm still alive.
>> <Redacted> lobster!
>>
>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-06 15:40 Pavan Deolasee <pavan.deolasee@gmail.com>
parent: Ron Johnson <ronljohnsonjr@gmail.com>
1 sibling, 0 replies; 15+ messages in thread
From: Pavan Deolasee @ 2026-08-06 15:40 UTC (permalink / raw)
To: Ron Johnson <ronljohnsonjr@gmail.com>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
On Thu, Aug 6, 2026 at 8:41 PM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
>
>
> On Thu, Aug 6, 2026 at 10:57 AM mahamood hussain <hussain.ieg@gmail.com>
> wrote:
>
>> Thanks for the suggestion. I confirmed that base/16388/447758 is the
>> heap file for table, so unfortunately it isn't an index that can simply
>> be rebuilt.
>>
>> heap_size | index_size | total_size
>> -----------+------------+------------
>> 11 GB | 5694 MB | 17 GB
>>
>> I'm fairly new to PostgreSQL, so could you provide a bit more context on
>> the binary search approach you mentioned? I'd appreciate it if you could
>> explain the steps involved and how it helps identify the records on the
>> corrupted page.
>>
>
You can try a TID scan to skip the corrupted page. Something like this:
SET max_parallel_workers_per_gather = 0; -- avoid parallel worker
SELECT count(*) FROM schema.tablename WHERE ctid < '(696770,0)'::tid;
SELECT count(*) FROM schema.tablename WHERE ctid >= '(696771,0)'::tid;
If this works, you can at least make a copy of all rows except the bad ones.
Thanks,
Pavan
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-06 15:42 mahamood hussain <hussain.ieg@gmail.com>
parent: Ron Johnson <ronljohnsonjr@gmail.com>
1 sibling, 0 replies; 15+ messages in thread
From: mahamood hussain @ 2026-08-06 15:42 UTC (permalink / raw)
To: Ron Johnson <ronljohnsonjr@gmail.com>; +Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Hi Ron,
I asked an AI tool for some guidance, and it recommended the approach
below. To be honest, I don't fully trust AI for something this critical, so
I'd really appreciate an expert review.
Could you please take a look and let me know whether this is technically
correct and whether you'd recommend this approach?
------------------------------
Proposed recovery approach
*1. ignore_checksum_failure — try this before zero_damaged_pages*
The recommendation is to first enable:
SET ignore_checksum_failure = on;
The idea is that if the page header is still valid and only the checksum is
incorrect, PostgreSQL may still be able to read the page and recover most
or all of the tuples. Since this is non-destructive, it seems like a
reasonable first step.
------------------------------
*2. zero_damaged_pages — only as a last resort*
The recommendation is to use this only if all other recovery options fail,
since it permanently zeros the damaged page and destroys all rows on that
page.
------------------------------
*3. pg_surgery*
Use pg_surgery only if the corruption is limited to specific tuples rather
than the page itself.
------------------------------
*4. Binary search + COPY*
Use a binary search approach to identify the corrupted page/range and copy
out all the remaining data, excluding only the damaged page.
------------------------------
*5. Recover from a standby*
If a physical standby exists and doesn't have the same corruption, recover
the missing rows from there.
------------------------------
My situation is slightly different:
-
The corruption appears to have happened *about a week ago*, but we only
discovered it today.
-
The table is still *partially readable*.
-
Restoring the table from backup would mean losing approximately *one
week's worth of data*, which I'd like to avoid if possible.
Given your experience with PostgreSQL corruption, does the above recovery
order make sense? Is there anything you would change or recommend trying
first?
On Thu, Aug 6, 2026 at 8:42 PM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
>
>
> On Thu, Aug 6, 2026 at 10:57 AM mahamood hussain <hussain.ieg@gmail.com>
> wrote:
>
>> Thanks for the suggestion. I confirmed that base/16388/447758 is the
>> heap file for table, so unfortunately it isn't an index that can simply
>> be rebuilt.
>>
>> heap_size | index_size | total_size
>> -----------+------------+------------
>> 11 GB | 5694 MB | 17 GB
>>
>> I'm fairly new to PostgreSQL, so could you provide a bit more context on
>> the binary search approach you mentioned? I'd appreciate it if you could
>> explain the steps involved and how it helps identify the records on the
>> corrupted page.
>>
>
> They don't teach the binary search algorithm in Comp Sci anymore? ☹️
>
> Anyway... use ORDER BY, OFFSET, LIMIT and the ROW_NUMBER() function to
> find the offending records via "divide and conquer".
>
>
>> Regarding your last point, do you think this corruption could be related
>> to the PostgreSQL version we're currently running? Is this a known issue
>> that has been fixed in PostgreSQL 17.10, or are you recommending the
>> upgrade simply because we're not on the latest minor release?
>>
>> Also, could you help me understand what typically causes page corruption
>> like this? Are there common root causes, and what best practices or
>> preventive measures would you recommend to minimize the risk of this
>> happening in the future?
>>
>> On Thu, Aug 6, 2026 at 8:14 PM Ron Johnson <ronljohnsonjr@gmail.com>
>> wrote:
>>
>>> Hmm.
>>>
>>> If base/16388/447758 is an index, then you could just drop it and
>>> recreate it, but you're probably not that lucky.
>>>
>>> How big is the table? Using a binary search method with ORDER BY and
>>> OFFSET, you can find the records on the offending page. Exclude them when
>>> doing a COPY TO, then recreate the table.
>>>
>>> And, of course, upgrade to 17.10.
>>>
>>> On Thu, Aug 6, 2026 at 10:27 AM mahamood hussain <hussain.ieg@gmail.com>
>>> wrote:
>>>
>>>> Hi Ron,
>>>>
>>>> Thanks for the quick response.
>>>>
>>>> Unfortunately, I do have backups, but they're also reporting the same
>>>> checksum error.
>>>> full backup: 20260801-203001F
>>>> timestamp start/stop: 2026-08-01 20:30:01-07 / 2026-08-01
>>>> 21:30:23-07
>>>> wal start/stop: 00000001000007F900000055 /
>>>> 000000010000080800000030
>>>> database size: 1403.4GB, database backup size: 1403.4GB
>>>> repo1: backup set size: 197.7GB, backup size: 197.7GB
>>>>
>>>> diff backup: 20260801-203001F_20260802-023002D
>>>> timestamp start/stop: 2026-08-02 02:30:02-07 / 2026-08-02
>>>> 02:35:44-07
>>>> wal start/stop: 000000010000086A000000B6 /
>>>> 000000010000086A000000B6
>>>> database size: 1407.7GB, database backup size: 221.5GB
>>>> repo1: backup set size: 198.8GB, backup size: 28.6GB
>>>> backup reference total: 1 full
>>>> error(s) detected during backup
>>>>
>>>> Our backup strategy is weekly full backups with daily incremental
>>>> backups.
>>>>
>>>> The database is hosted on Azure Premium SSD v2, using four striped
>>>> disks.
>>>>
>>>> How serious does this look to you? Do you have any recommendations on
>>>> the fastest way to recover from this? At the moment, I'm concerned that
>>>> both the production copy and the backups appear to be affected.
>>>>
>>>> On Thu, Aug 6, 2026 at 7:47 PM Ron Johnson <ronljohnsonjr@gmail.com>
>>>> wrote:
>>>>
>>>>> On Thu, Aug 6, 2026 at 10:11 AM mahamood hussain <
>>>>> hussain.ieg@gmail.com> wrote:
>>>>>
>>>>>> Hi Team,
>>>>>>
>>>>>> I need some urgent help. I'm unable to access one of the tables. Even
>>>>>> a simple SELECT statement fails with the error below. Could someone
>>>>>> please help investigate and fix this issue?
>>>>>>
>>>>>> prod=# SELECT count(*) FROM schema.tablename;
>>>>>>
>>>>>> WARNING: page verification failed, calculated checksum 50897 but expected 50048
>>>>>> ERROR: invalid page in block 696770 of relation base/16388/447758
>>>>>> CONTEXT: parallel worker
>>>>>>
>>>>>> Any assistance would be greatly appreciated. Thanks!
>>>>>>
>>>>>
>>>>> * Have you tested your backup/restore process lately?
>>>>> * How old is the latest backup?
>>>>> * Do the system logs show any errors around that time?
>>>>> * What kind of disks do you have? One might be dying.
>>>>>
>>>>> --
>>>>> Death to <Redacted>, and butter sauce.
>>>>> Don't boil me, I'm still alive.
>>>>> <Redacted> lobster!
>>>>>
>>>>
>>>
>>> --
>>> Death to <Redacted>, and butter sauce.
>>> Don't boil me, I'm still alive.
>>> <Redacted> lobster!
>>>
>>
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-10 04:23 mahamood hussain <hussain.ieg@gmail.com>
parent: mahamood hussain <hussain.ieg@gmail.com>
1 sibling, 1 reply; 15+ messages in thread
From: mahamood hussain @ 2026-08-10 04:23 UTC (permalink / raw)
To: Licio Matos <licio.matos@gmail.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Ron Johnson <ronljohnsonjr@gmail.com>; Pgsql-admin <pgsql-admin@lists.postgresql.org>
Hi,
We were using Premium SSD v2, which Microsoft states provides 99.999999999%
durability. However, given the corruption issue we encountered, I’m not
fully confident in the storage layer.
The corrupted page was a heap/table page, not an index page.
For recovery, I restored the database backup on a temporary server and
performed a roll-forward until it caught up with production. I then
exported the recovered table data, imported it into production, and
replaced the corrupted table with the recovered copy.
I have not dropped the original corrupted table yet. I have kept it renamed
for now so that we can investigate the corruption further and try some of
the other recommended recovery methods before removing it.
On Sat, Aug 8, 2026 at 3:38 AM Licio Matos <licio.matos@gmail.com> wrote:
>
> Have you try to check these blocks are table related or index related?
>
> You are counting, could be a index corrupted.
>
> Try this:
>
> SELECT relname, relkind
> FROM pg_class
> WHERE pg_relation_filepath(oid) LIKE '%447758%';
>
> Licio Matos
>
> Em sex., 7 de ago. de 2026 às 18:56, Laurenz Albe <
> laurenz.albe@cybertec.at> escreveu:
>
>> On Thu, 2026-08-06 at 19:57 +0530, mahamood hussain wrote:
>> > The database is hosted on Azure Premium SSD v2, using four striped
>> disks.
>> >
>> > >
>> > > > prod=# SELECT count(*) FROM schema.tablename;
>> > > >
>> > > > WARNING: page verification failed, calculated checksum 50897 but
>> expected 50048
>> > > > ERROR: invalid page in block 696770 of relation base/16388/447758
>>
>> Looks like Microsoft's storage is not reliable.
>>
>> Yours,
>> Laurenz Albe
>>
>>
>>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-10 12:39 Licio Matos <licio.matos@gmail.com>
parent: mahamood hussain <hussain.ieg@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Licio Matos @ 2026-08-10 12:39 UTC (permalink / raw)
To: mahamood hussain <hussain.ieg@gmail.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Ron Johnson <ronljohnsonjr@gmail.com>; Pgsql-admin <pgsql-admin@lists.postgresql.org>
Mahamood,
Understand, so there some issues regarding ssd v2.
When you stripe 4 Premium SSD v2 disks together with LVM or mdadm, the OS
splits each logical I/O into chunks and distributes them across the 4
physical disks based on offset. A single PostgreSQL page write (8KB) can
end up physically split across 2, 3, or all 4 disks, depending on where it
lands relative to the stripe’s chunk size.
The danger: if even one of those four disks is momentarily throttled —
because it hit its own individually-provisioned IOPS/throughput ceiling —
that disk’s portion of the write lags behind while the other three complete
on time. What was meant to be one atomic 8KB write becomes several
independent physical operations with different completion timing. If a
crash or reset happens in that window, you get a torn write: part of the
page has the new data, part still has old or garbage data. That’s exactly
the signature of a checksum mismatch like the one you hit.
For digging in the problem, can you provide this informations:
Run this with Az CLI:
az disk show -g <rg> -n <disk-name> --query
"diskIOPSReadWrite,diskMBpsReadWrite,networkAccessPolicy"
Check full page writes are ON.
SHOW full_page_writes;
If you have access to the VM. You could look at the journal with dmesg
checking for IO errors:
dmesg -T | grep -iE 'error|reset|i/o'
journalctl -k --since "3 days ago" | grep -iE 'ata|nvme|scsi'
Licio Matos
Em seg., 10 de ago. de 2026 às 01:23, mahamood hussain <
hussain.ieg@gmail.com> escreveu:
> Hi,
>
> We were using Premium SSD v2, which Microsoft states provides
> 99.999999999% durability. However, given the corruption issue we
> encountered, I’m not fully confident in the storage layer.
>
> The corrupted page was a heap/table page, not an index page.
>
> For recovery, I restored the database backup on a temporary server and
> performed a roll-forward until it caught up with production. I then
> exported the recovered table data, imported it into production, and
> replaced the corrupted table with the recovered copy.
>
> I have not dropped the original corrupted table yet. I have kept it
> renamed for now so that we can investigate the corruption further and try
> some of the other recommended recovery methods before removing it.
> On Sat, Aug 8, 2026 at 3:38 AM Licio Matos <licio.matos@gmail.com> wrote:
>
>>
>> Have you try to check these blocks are table related or index related?
>>
>> You are counting, could be a index corrupted.
>>
>> Try this:
>>
>> SELECT relname, relkind
>> FROM pg_class
>> WHERE pg_relation_filepath(oid) LIKE '%447758%';
>>
>> Licio Matos
>>
>> Em sex., 7 de ago. de 2026 às 18:56, Laurenz Albe <
>> laurenz.albe@cybertec.at> escreveu:
>>
>>> On Thu, 2026-08-06 at 19:57 +0530, mahamood hussain wrote:
>>> > The database is hosted on Azure Premium SSD v2, using four striped
>>> disks.
>>> >
>>> > >
>>> > > > prod=# SELECT count(*) FROM schema.tablename;
>>> > > >
>>> > > > WARNING: page verification failed, calculated checksum 50897 but
>>> expected 50048
>>> > > > ERROR: invalid page in block 696770 of relation
>>> base/16388/447758
>>>
>>> Looks like Microsoft's storage is not reliable.
>>>
>>> Yours,
>>> Laurenz Albe
>>>
>>>
>>>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-13 08:55 mahamood hussain <hussain.ieg@gmail.com>
parent: Licio Matos <licio.matos@gmail.com>
0 siblings, 2 replies; 15+ messages in thread
From: mahamood hussain @ 2026-08-13 08:55 UTC (permalink / raw)
To: Licio Matos <licio.matos@gmail.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Ron Johnson <ronljohnsonjr@gmail.com>; Pgsql-admin <pgsql-admin@lists.postgresql.org>
hi Matos,
Quick question regarding disk striping.
The main reason we considered disk striping was to keep the storage cost
reasonable while achieving the required IOPS and throughput. We are using
Azure Premium SSD v2, which provides 99.999999999% durability, and my
understanding is that Azure designed this storage to support configurations
such as RAID 0 when higher IOPS/throughput are required.
Given that our databases are in the TB range—the current database is around
13 TB—are there any known limitations or risks with using RAID 0 even with
the underlying durability provided by Premium SSD v2?
I understand that traditionally we would avoid RAID 0 from a
hardware/database reliability perspective because a failure of a single
disk can impact the entire volume. However, with Azure managed disks and
their durability guarantees, I'm trying to understand whether the same
concern still applies and what the recommended architecture is.
If RAID 0 is not the preferred approach, what is the recommended PostgreSQL
architecture for achieving high IOPS and throughput for large databases?
For context, these databases were recently migrated from DB2 to PostgreSQL.
In DB2, we have the concept of storage groups and storage paths, which
allows us to place tablespaces across multiple disks/storage paths for
performance and I/O distribution.
Since PostgreSQL doesn't have the same storage-group concept, I was
considering implementing a similar architecture at the storage layer using
RAID 0.
I'd appreciate your thoughts on the recommended approach for large
PostgreSQL databases on Azure, particularly around performance, cost, and
reliability.
[postgres@dtprd04-pg01: ~]$ dmesg -T | grep -iE 'error|reset|i/o'
[Fri Jul 31 23:44:38 2026] APIC: Switch to symmetric I/O mode setup
[Fri Jul 31 23:44:39 2026] 00:00: ttyS0 at I/O 0x3f8 (irq = 4, base_baud =
115200) is a 16550A
[Fri Jul 31 23:44:39 2026] 00:01: ttyS1 at I/O 0x2f8 (irq = 3, base_baud =
115200) is a 16550A
[Fri Jul 31 23:44:39 2026] serial8250: ttyS2 at I/O 0x3e8 (irq = 4,
base_baud = 115200) is a 16550A
[postgres@dtprd04-pg01: ~]$ sudo journalctl -k --since "10 days ago" | grep
-iE 'ata|nvme|scsi'
Jul 31 23:44:39 localhost kernel: The list of certified hardware and cloud
instances for Red Hat Enterprise Linux 9 can be viewed at the Red Hat
Ecosystem Catalog, https://catalog.redhat.com.
Jul 31 23:44:39 localhost kernel: Command line:
BOOT_IMAGE=(hd2,gpt3)/vmlinuz-5.14.0-687.26.1.el9_8.x86_64
root=UUID=e8698ddb-90ea-4097-a275-643af6bbabb8 ro loglevel=3 console=tty1
console=ttyS0 earlyprintk=ttyS0 rootdelay=300 no_timer_check
nvme_core.io_timeout=240 biosdevname=0 net.ifnames=0
crashkernel=1G-2G:192M,2G-64G:256M,64G-:512M
Jul 31 23:44:39 localhost kernel: BIOS-e820: [mem
0x000000003ffc9000-0x000000003fffafff] ACPI data
Jul 31 23:44:39 localhost kernel: NODE_DATA(0) allocated [mem
0x60fffd5000-0x60ffffffff]
Jul 31 23:44:39 localhost kernel: Kernel command line:
BOOT_IMAGE=(hd2,gpt3)/vmlinuz-5.14.0-687.26.1.el9_8.x86_64
root=UUID=e8698ddb-90ea-4097-a275-643af6bbabb8 ro loglevel=3 console=tty1
console=ttyS0 earlyprintk=ttyS0 rootdelay=300 no_timer_check
nvme_core.io_timeout=240 biosdevname=0 net.ifnames=0
crashkernel=1G-2G:192M,2G-64G:256M,64G-:512M
Jul 31 23:44:39 localhost kernel: Memory: 395392972K/402647804K available
(16384K kernel code, 5797K rwdata, 13972K rodata, 4208K init, 7184K bss,
7228844K reserved, 0K cma-reserved)
Jul 31 23:44:39 localhost kernel: SCSI subsystem initialized
Jul 31 23:44:39 localhost kernel: Block layer SCSI generic (bsg) driver
version 0.4 loaded (major 246)
Jul 31 23:44:39 localhost kernel: Write protecting the kernel read-only
data: 30720k
Jul 31 23:44:39 localhost kernel: Freeing unused kernel image (rodata/data
gap) memory: 364K
Jul 31 23:44:40 localhost kernel: scsi host0: storvsc_host_t
Jul 31 23:44:40 localhost kernel: nvme nvme0: pci function c05b:00:00.0
Jul 31 23:44:40 localhost kernel: nvme c05b:00:00.0: enabling device (0000
-> 0002)
Jul 31 23:44:40 localhost kernel: nvme nvme1: pci function 8d07:00:00.0
Jul 31 23:44:40 localhost kernel: nvme nvme2: pci function e4d7:00:00.0
Jul 31 23:44:40 localhost kernel: nvme nvme3: pci function 096c:00:00.0
Jul 31 23:44:40 localhost kernel: nvme nvme4: pci function f0bc:00:00.0
Jul 31 23:44:40 localhost kernel: nvme nvme5: pci function 033d:00:00.0
Jul 31 23:44:40 localhost kernel: nvme 8d07:00:00.0: enabling device (0000
-> 0002)
Jul 31 23:44:40 localhost kernel: nvme nvme6: pci function b7bb:00:00.0
Jul 31 23:44:40 localhost kernel: nvme e4d7:00:00.0: enabling device (0000
-> 0002)
Jul 31 23:44:40 localhost kernel: nvme f0bc:00:00.0: enabling device (0000
-> 0002)
Jul 31 23:44:40 localhost kernel: nvme 096c:00:00.0: enabling device (0000
-> 0002)
Jul 31 23:44:40 localhost kernel: nvme 033d:00:00.0: enabling device (0000
-> 0002)
Jul 31 23:44:40 localhost kernel: nvme b7bb:00:00.0: enabling device (0000
-> 0002)
Jul 31 23:44:40 localhost kernel: nvme nvme0: 48/0/0 default/read/poll
queues
Jul 31 23:44:40 localhost kernel: nvme0n1: p1 p2 p3 p4
Jul 31 23:44:40 localhost kernel: nvme nvme6: 6/0/0 default/read/poll queues
Jul 31 23:44:41 localhost kernel: nvme nvme1: 6/0/0 default/read/poll queues
Jul 31 23:44:41 localhost kernel: nvme nvme4: 6/0/0 default/read/poll queues
Jul 31 23:44:41 localhost kernel: nvme nvme2: 6/0/0 default/read/poll queues
Jul 31 23:44:41 localhost kernel: nvme nvme3: 6/0/0 default/read/poll queues
Jul 31 23:44:41 localhost kernel: nvme nvme5: 6/0/0 default/read/poll queues
Jul 31 23:44:42 localhost kernel: XFS (nvme0n1p4): Mounting V5 Filesystem
e8698ddb-90ea-4097-a275-643af6bbabb8
Jul 31 23:44:42 localhost kernel: XFS (nvme0n1p4): Ending clean mount
Jul 31 23:44:44 dtprd04-pg01 kernel: XFS (nvme0n1p3): Mounting V5
Filesystem 050b8d52-f03b-4fbc-87b3-fee63a357e2c
Jul 31 23:44:44 dtprd04-pg01 kernel: XFS (nvme0n1p3): Ending clean mount
Jul 31 23:44:44 dtprd04-pg01 kernel: XFS (nvme0n13): Mounting V5 Filesystem
ff919446-a2bb-459d-a7d2-6a894a5656e1
Jul 31 23:44:45 dtprd04-pg01 kernel: XFS (nvme0n13): Ending clean mount
Jul 31 23:44:46 dtprd04-pg01 kernel: hv_netvsc
f8615163-0000-1000-2000-7c1e52d8883d eth0: Data path switched to VF: eth1
Jul 31 23:44:47 dtprd04-pg01 kernel: hv_netvsc
f8615163-0000-1000-2000-7c1e52d8883d eth0: Data path switched from VF: eth1
Jul 31 23:44:47 dtprd04-pg01 kernel: hv_netvsc
f8615163-0000-1000-2000-7c1e52d8883d eth0: Data path switched to VF: eth1
Jul 31 23:44:51 dtprd04-pg01 kernel: block nvme0n1: No UUID available
providing old NGUID
Jul 31 23:44:51 dtprd04-pg01 kernel: block nvme0n1: the capability
attribute has been deprecated.
Aug 08 06:21:45 dtprd04-pg01 kernel: nvme nvme0: rescanning namespaces.
SHOW full_page_writes;
full_page_writes
------------------
on
(1 row)
On Mon, Aug 10, 2026 at 6:09 PM Licio Matos <licio.matos@gmail.com> wrote:
> Mahamood,
>
> Understand, so there some issues regarding ssd v2.
>
> When you stripe 4 Premium SSD v2 disks together with LVM or mdadm, the OS
> splits each logical I/O into chunks and distributes them across the 4
> physical disks based on offset. A single PostgreSQL page write (8KB) can
> end up physically split across 2, 3, or all 4 disks, depending on where it
> lands relative to the stripe’s chunk size.
>
> The danger: if even one of those four disks is momentarily throttled —
> because it hit its own individually-provisioned IOPS/throughput ceiling —
> that disk’s portion of the write lags behind while the other three complete
> on time. What was meant to be one atomic 8KB write becomes several
> independent physical operations with different completion timing. If a
> crash or reset happens in that window, you get a torn write: part of the
> page has the new data, part still has old or garbage data. That’s exactly
> the signature of a checksum mismatch like the one you hit.
>
> For digging in the problem, can you provide this informations:
>
> Run this with Az CLI:
>
> az disk show -g <rg> -n <disk-name> --query
> "diskIOPSReadWrite,diskMBpsReadWrite,networkAccessPolicy"
>
> Check full page writes are ON.
>
> SHOW full_page_writes;
>
> If you have access to the VM. You could look at the journal with dmesg
> checking for IO errors:
>
> dmesg -T | grep -iE 'error|reset|i/o'
> journalctl -k --since "3 days ago" | grep -iE 'ata|nvme|scsi'
>
>
>
> Licio Matos
>
> Em seg., 10 de ago. de 2026 às 01:23, mahamood hussain <
> hussain.ieg@gmail.com> escreveu:
>
>> Hi,
>>
>> We were using Premium SSD v2, which Microsoft states provides
>> 99.999999999% durability. However, given the corruption issue we
>> encountered, I’m not fully confident in the storage layer.
>>
>> The corrupted page was a heap/table page, not an index page.
>>
>> For recovery, I restored the database backup on a temporary server and
>> performed a roll-forward until it caught up with production. I then
>> exported the recovered table data, imported it into production, and
>> replaced the corrupted table with the recovered copy.
>>
>> I have not dropped the original corrupted table yet. I have kept it
>> renamed for now so that we can investigate the corruption further and try
>> some of the other recommended recovery methods before removing it.
>> On Sat, Aug 8, 2026 at 3:38 AM Licio Matos <licio.matos@gmail.com> wrote:
>>
>>>
>>> Have you try to check these blocks are table related or index related?
>>>
>>> You are counting, could be a index corrupted.
>>>
>>> Try this:
>>>
>>> SELECT relname, relkind
>>> FROM pg_class
>>> WHERE pg_relation_filepath(oid) LIKE '%447758%';
>>>
>>> Licio Matos
>>>
>>> Em sex., 7 de ago. de 2026 às 18:56, Laurenz Albe <
>>> laurenz.albe@cybertec.at> escreveu:
>>>
>>>> On Thu, 2026-08-06 at 19:57 +0530, mahamood hussain wrote:
>>>> > The database is hosted on Azure Premium SSD v2, using four striped
>>>> disks.
>>>> >
>>>> > >
>>>> > > > prod=# SELECT count(*) FROM schema.tablename;
>>>> > > >
>>>> > > > WARNING: page verification failed, calculated checksum 50897 but
>>>> expected 50048
>>>> > > > ERROR: invalid page in block 696770 of relation
>>>> base/16388/447758
>>>>
>>>> Looks like Microsoft's storage is not reliable.
>>>>
>>>> Yours,
>>>> Laurenz Albe
>>>>
>>>>
>>>>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-13 09:58 Ireneusz Pluta <ipluta@wp.pl>
parent: mahamood hussain <hussain.ieg@gmail.com>
1 sibling, 1 reply; 15+ messages in thread
From: Ireneusz Pluta @ 2026-08-13 09:58 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
W dniu 13.08.2026 o 10:55 AM, mahamood hussain pisze:
> are there any known limitations or risks with using RAID 0 even with
> the underlying durability provided by Premium SSD v2?
using RAID 0 is always a risk, regardless how much premium your hardware
is. Use RAID10 if you value your data.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-13 12:19 Licio Matos <licio.matos@gmail.com>
parent: Ireneusz Pluta <ipluta@wp.pl>
0 siblings, 1 reply; 15+ messages in thread
From: Licio Matos @ 2026-08-13 12:19 UTC (permalink / raw)
To: Ireneusz Pluta <ipluta@wp.pl>; +Cc: pgsql-admin@lists.postgresql.org
Hi,
Just to confirm, are you using 4 disks in raid 0 from azure ssd v2? How
they are deployed ,LVM or mdadm? What’s is the page size of the stripe?
About tablespace, you can use tablespaces in PostgreSQL the same way.
https://www.postgresql.org/docs/current/manage-ag-tablespaces.html
Licio Matos
Em qui., 13 de ago. de 2026 às 06:58, Ireneusz Pluta <ipluta@wp.pl>
escreveu:
> W dniu 13.08.2026 o 10:55 AM, mahamood hussain pisze:
> > are there any known limitations or risks with using RAID 0 even with
> > the underlying durability provided by Premium SSD v2?
> using RAID 0 is always a risk, regardless how much premium your hardware
> is. Use RAID10 if you value your data.
>
>
>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-14 09:10 mahamood hussain <hussain.ieg@gmail.com>
parent: Licio Matos <licio.matos@gmail.com>
0 siblings, 0 replies; 15+ messages in thread
From: mahamood hussain @ 2026-08-14 09:10 UTC (permalink / raw)
To: Licio Matos <licio.matos@gmail.com>; +Cc: Ireneusz Pluta <ipluta@wp.pl>; pgsql-admin@lists.postgresql.org
Hi Matos,
Thanks for the response.
The PostgreSQL data volume is deployed using LVM striping, not mdadm. It
uses four Azure NVMe disks, combined into a ~2 TB LVM logical volume. The
LVM stripe size is 128 KiB.
I also looked into PostgreSQL tablespaces. While PostgreSQL supports
tablespaces, they don't provide the same capability as DB2 storage groups
and storage paths.
In DB2, a tablespace can be associated with a storage group, and the
storage group can have multiple storage paths. This allows the tablespace's
I/O to be distributed across multiple disks:
DB2 Database
|
Tablespace
|
Storage Group
|
+-----------+-----------+
| | |
Path 1 Path 2 Path 3
| | |
Disk 1 Disk 2 Disk 3
This is different from PostgreSQL, where a tablespace points to a single
filesystem/location. PostgreSQL itself doesn't provide the same
storage-group concept where one tablespace can directly use multiple
independent storage paths.
Therefore, if we want to distribute the I/O for a PostgreSQL tablespace
across multiple disks, that distribution needs to happen at the OS/storage
layer, for example through LVM striping or RAID.
This was the main reason I considered LVM striping for the PostgreSQL data
volume — to achieve a similar I/O distribution model to what we had with
DB2 storage groups and storage paths.
Please let me know if there is a better PostgreSQL/Azure architecture for
achieving the same level of IOPS and throughput without relying on OS-level
striping.
On Thu, Aug 13, 2026 at 5:49 PM Licio Matos <licio.matos@gmail.com> wrote:
> Hi,
>
> Just to confirm, are you using 4 disks in raid 0 from azure ssd v2? How
> they are deployed ,LVM or mdadm? What’s is the page size of the stripe?
>
> About tablespace, you can use tablespaces in PostgreSQL the same way.
>
> https://www.postgresql.org/docs/current/manage-ag-tablespaces.html
>
>
> Licio Matos
>
> Em qui., 13 de ago. de 2026 às 06:58, Ireneusz Pluta <ipluta@wp.pl>
> escreveu:
>
>> W dniu 13.08.2026 o 10:55 AM, mahamood hussain pisze:
>> > are there any known limitations or risks with using RAID 0 even with
>> > the underlying durability provided by Premium SSD v2?
>> using RAID 0 is always a risk, regardless how much premium your hardware
>> is. Use RAID10 if you value your data.
>>
>>
>>
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Urgent !!!! Tables inaccessible postgres v17.6
@ 2026-08-14 22:09 Laurenz Albe <laurenz.albe@cybertec.at>
parent: mahamood hussain <hussain.ieg@gmail.com>
1 sibling, 0 replies; 15+ messages in thread
From: Laurenz Albe @ 2026-08-14 22:09 UTC (permalink / raw)
To: mahamood hussain <hussain.ieg@gmail.com>; Licio Matos <licio.matos@gmail.com>; +Cc: Ron Johnson <ronljohnsonjr@gmail.com>; Pgsql-admin <pgsql-admin@lists.postgresql.org>
On Thu, 2026-08-13 at 14:25 +0530, mahamood hussain wrote:
> We are using Azure Premium SSD v2, which provides 99.999999999% durability, and my
> understanding is that Azure designed this storage to support configurations such as
> RAID 0 when higher IOPS/throughput are required.
I don't know how "durability" is defined there.
You got corruption, so either that's durable corruption or you are in the 0.000000001%.
> For context, these databases were recently migrated from DB2 to PostgreSQL. In DB2,
> we have the concept of storage groups and storage paths, which allows us to place
> tablespaces across multiple disks/storage paths for performance and I/O distribution.
If you control the storage, nothing keeps you from creating your data directory
in a file system that is striped across multiple devices to achieve the same thing.
But in a virtualized environment, that's pretty moot: it all ends up on the same
storage anyway.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2026-08-14 22:09 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-08-06 14:11 Urgent !!!! Tables inaccessible postgres v17.6 mahamood hussain <hussain.ieg@gmail.com>
2026-08-06 14:16 ` Ron Johnson <ronljohnsonjr@gmail.com>
2026-08-06 14:27 ` mahamood hussain <hussain.ieg@gmail.com>
2026-08-06 14:43 ` Ron Johnson <ronljohnsonjr@gmail.com>
2026-08-06 14:57 ` mahamood hussain <hussain.ieg@gmail.com>
2026-08-06 15:11 ` Ron Johnson <ronljohnsonjr@gmail.com>
2026-08-06 15:40 ` Pavan Deolasee <pavan.deolasee@gmail.com>
2026-08-06 15:42 ` mahamood hussain <hussain.ieg@gmail.com>
2026-08-10 04:23 ` mahamood hussain <hussain.ieg@gmail.com>
2026-08-10 12:39 ` Licio Matos <licio.matos@gmail.com>
2026-08-13 08:55 ` mahamood hussain <hussain.ieg@gmail.com>
2026-08-13 09:58 ` Ireneusz Pluta <ipluta@wp.pl>
2026-08-13 12:19 ` Licio Matos <licio.matos@gmail.com>
2026-08-14 09:10 ` mahamood hussain <hussain.ieg@gmail.com>
2026-08-14 22:09 ` Laurenz Albe <laurenz.albe@cybertec.at>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox