Comment by KirinDave
7 years ago
The box turning off, the disk interface failing, and/or the link to the database failing in mid instruction.
Same as SQS.
7 years ago
The box turning off, the disk interface failing, and/or the link to the database failing in mid instruction.
Same as SQS.
All of those would result in a write failure from the application's perspective, which is fine, and must be accounted for regardless (e.g. retry, two phase commit, log an error, whatever).
But you have to explicitly delete the message from SQS, right? You'd only delete after confirming you processed the message, right? So if you die mid-instruction in processing a message, the message just re-appears in the SQS queue after the visibility timeout.
That's a feature, and one your have to replicate in your postgres queue.
Also the FS might report the data as written but its actually in a write cache and will be lost if the plug is pulled.
Not an issue if you follow th e recommendations in the PostgeSQL documentation. The way to comfigure write caches is described there.