News for hackers. Stuff that matters.
Re:Unfinished Business with Postgres by retcon on Wednesday May 18, 2022 @02:45PM (#31426233)
>near miss when a disk was lost that caused a rather horrific amount of effort and some nailbiting in restoring from pgbackups.”

I hope that eliminating a single drive fault failure mode isn't part of the unfinished business.

Twelve years ago RAID 6 and 60 definitely existed. Battery backed FC arrays of considerable sophistication have existed for far longer. I'm thinking HDS arrays circa 2002 for peak redundancy complexity (before integration reduced parts and physical runtime concerns making the installation environment as important as the technology.)

Re:Unfinished Business with Postgres by djbusby on Wednesday May 18, 2022 @04:27PM (#31427221)
One time, me, a noob, accidentally deleted files in the PG data directory. No noe! But PG had open handles to them so they aren't reclaimed by the FS and I was able to pg_dump. Not a production system but the loss would've been "big". Just saying, PG itself is very resilient.
Re:Unfinished Business with Postgres by lelanthran on Wednesday May 18, 2022 @04:59PM (#31427587)
> One time, me, a noob, accidentally deleted files in the PG data directory. No noe! But PG had open handles to them so they aren't reclaimed by the FS and I was able to pg_dump. Not a production system but the loss would've been "big". Just saying, PG itself is very resilient.

That isn't a PG thing; Linux[1] ext3/4 does not actually delete files (or directories) that are still in use. Only the name is removed. The file itself remains until the last open handle to it is closed.

[1] Amongst other OSes

Re:Unfinished Business with Postgres by gjvc on Wednesday May 18, 2022 @05:17PM (#31427802)
if you'd read the previous post carefully, you'd have seen they said that
Re:Unfinished Business with Postgres by lelanthran on Thursday May 19, 2022 @03:32AM (#31431780)
> if you'd read the previous post carefully, you'd have seen they said that

I did read it carefully (and quoted the whole thing for context), but that final line made it seem that it was PG that was responsible for that particular instance of resilience.

Someone who isn't familiar with how ext3/4 handles deletes might, from the comment alone, assume that the same sort of thing would happen on other filesystems.

Re:Unfinished Business with Postgres by factcheckdec on Wednesday May 18, 2022 @09:07PM (#31429517)
Did their clarification truly merit such a snarky response?
Re:Unfinished Business with Postgres by gjvc on Thursday May 19, 2022 @02:35AM (#31431415)
it wasn't clarification; it was repetition
Re:Unfinished Business with Postgres by hombre_fatal on Thursday May 19, 2022 @03:10AM (#31431613)
No, the comment did make it sound like it was PG’s resilience that saved the data. In fact that seems to be the whole point of the comment.

So the snark does seem out of place and the clarification useful.

Re:Unfinished Business with Postgres by gjvc on Thursday May 19, 2022 @03:32AM (#31431785)
nice bit of white-knighting there
Re:Unfinished Business with Postgres by lelanthran on Thursday May 19, 2022 @04:23AM (#31432060)
> nice bit of white-knighting there

Is it really constructive to throw insults[1]? I explained myself above, after all.

[1] I had to look it up to see what it means: https://en.wikipedia.org/wiki/White_knight. Since we aren't in a business context, I can only assume that you think I am female :-)

Re:Unfinished Business with Postgres by fdr on Wednesday May 18, 2022 @05:21PM (#31427844)
EBS has always been RAID. You need more.
Re:Unfinished Business with Postgres by sroussey on Wednesday May 18, 2022 @08:08PM (#31429149)
I definitely had battery backed RAID installed in my servers the year 2000. RAID 10 for me.
Re:Unfinished Business with Postgres by glenngillen on Thursday May 19, 2022 @03:20AM (#31431687)
What were you using for your RAID solution on AWS in 2009?