> If it's just storing the logs, I doubt it's the cause of the problem. You can
> ignore my message. I had too much fun fighting with Gluster recently.
Hehe, hope you came through on top ;). Anyways, I added an md5sum calculation
in the archiving script just to be able to verify that the files d
On Wednesday, April 06, 2016 10:33:16 AM Lars Arvidson wrote:
> > I'd guess it's probably more like option 3 - Glusterfs ate my database.
>
> Hi, thanks for your reply!
> We do archive logs on a distributed Glusterfs volume in case the streaming
> replication gets too far behind and the transactio
> I'd guess it's probably more like option 3 - Glusterfs ate my database.
Hi, thanks for your reply!
We do archive logs on a distributed Glusterfs volume in case the streaming
replication gets too far behind and the transaction logs have been removed.
Would a restore of a corrupt archived log fil
On Tuesday, April 05, 2016 12:55:04 PM Lars Arvidson wrote:
> Is there something I missed in the switchover or could this be a bug?
>
I'd guess it's probably more like option 3 - Glusterfs ate my database.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes t
Hi, I hope I'm mailing this to the correct mailing list.
We get errors inserting into a table:
2016-04-04 07:27:51 CEST [43342-2] @ ERROR: could not read
block 28991 in file "base/16390/572026": read only 0 of 8192 bytes
2016-04-04 07:27:51 CEST [43342-3] @ STATEMENT: INSERT INTO
(...) VALUES
