t make sure you shut them down cleanly - it can up to
>> 30 minutes per card to recover from a crash/plug pull test.
>
> Yeah...I got into an argument with Kenny Gorman over my concerns with how
> they were handling durability issues on his blog, the reading I did about
> th
33:54 frutestdb002 postgres[5667]: [10-1] 2009-11-18
14:33:54 PSTLOG: database system is ready
Thanks
Kenny
On Nov 13, 2009, at 1:35 PM, Kenny Gorman wrote:
The FusionIO products are a little different. They are card based
vs trying to emulate a traditional disk. In terms of volatility,
The FusionIO products are a little different. They are card based vs trying to
emulate a traditional disk. In terms of volatility, they have an on-board
capacitor that allows power to be supplied until all writes drain. They do not
have a cache in front of them like a disk-type SSD might. I
Perhaps these guys know: http://www.recurrent.com/
-kg
On Jul 20, 2009, at 7:29 AM, Craig James wrote:
Apologies for a slightly off-topic question ... a friend is
overseeing the demise of a company and has several computers that
they need to get rid of. She's an attorney and knows little
Well for one thing on the IODrive. Be sure to use a FS that supports direct IO
so you don't cache it on the FS level and thus take room an object not on SSD
could use. We use vxfs with mincache=direct as our filesystem for just this
reason. Also, there is an IO drive tuning manual that discus
We have a box outfitted with two of them we are testing. We are testing with
VxFS and ext3, but not quite ready to publish. I will reply when we are done.
-Original Message-
From: pgsql-performance-ow...@postgresql.org on behalf of Dave Cramer
Sent: Thu 3/26/2009 5:47 AM
To: pgsql-pe
The technique Jeff is speaking of below is exactly how we do it,
except we use file-system snapshots vs rsync.
The problem is how slow log application is when recovering since it's
a single process, and very slow at that.
-kg
On Jan 26, 2009, at 11:58 AM, Jeff wrote:
On Jan 26, 2009, at
