It seems that it was the Postgres bug on replica, after upgrading minor
version to 9.1.21 on replica1, the corruption goes away.
Thanks everyone for the help
On Tue, Apr 5, 2016 at 1:32 AM, Soni M wrote:
> Hello Adrian, thanks for the response.
>
> master data also located on SAN
>
> Yes, each
Hello Adrian, thanks for the response.
master data also located on SAN
Yes, each replica is it own VM with its own virtual disk/volume as served
up from the same SAN
Raw disk mappings are a way for ESX to present a SAN volume directly to a
VM instead of creating a virtual disk.
no unexpected me
On 04/02/2016 08:38 PM, Soni M wrote:
Hello Everyone,
We face TOAST table corruption.
One master and two streaming replicas. The corruption happen only on
both streaming replicas.
We did found the corrupted rows. Selecting on this row, return (on both
replica) : unexpected chunk number 0 (expe
On 04/02/2016 08:38 PM, Soni M wrote:
Hello Everyone,
We face TOAST table corruption.
One master and two streaming replicas. The corruption happen only on
both streaming replicas.
We did found the corrupted rows. Selecting on this row, return (on both
replica) : unexpected chunk number 0 (expe
Sorry, miss that info. Master 9.1.13, replica1 9.1.13, replica2 9.1.19.
Master Red Hat Enterprise Linux Server release 6.5 (Santiago),
replica1 Red Hat Enterprise Linux Server release 6.5 (Santiago),
replica2 Red Hat Enterprise Linux Server release 6.7 (Santiago).
On Sun, Apr 3, 2016 at 10:43 AM,
What version of PostgreSQL and which OS?
On 04/02/2016 08:38 PM, Soni M wrote:
How can the corruption occurs ? and how can I resolve them ?
Thank so much for the help.
Cheers \o/
--
Regards,
Soni Maula Harriz
--
Command Prompt, Inc. http://the.postgres.company/
Hello Everyone,
We face TOAST table corruption.
One master and two streaming replicas. The corruption happen only on both
streaming replicas.
We did found the corrupted rows. Selecting on this row, return (on both
replica) : unexpected chunk number 0 (expected 1) for toast value
1100613112 in pg
