Re: Urgent !!!! Tables inaccessible postgres v17.6

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(dot)ieg(at)gmail(dot)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(dot)matos(at)gmail(dot)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(dot)albe(at)cybertec(dot)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
>>>
>>>
>>>