| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | mahamood hussain <hussain(dot)ieg(at)gmail(dot)com>, Licio Matos <licio(dot)matos(at)gmail(dot)com> |
| Cc: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Urgent !!!! Tables inaccessible postgres v17.6 |
| Date: | 2026-08-14 22:09:11 |
| Message-ID: | 927e28d9d875aa9f1812c54d12fdffa6ba41f68a.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | SASIKUMAR Devaraj | 2026-08-18 12:58:02 | Unused Indexes |
| Previous Message | mahamood hussain | 2026-08-14 09:10:18 | Re: Urgent !!!! Tables inaccessible postgres v17.6 |