PR_Service. Sync database only on clean stop?

PR_Service. Sync database only on clean stop?

[Ricardo Ribalda Delgado]

Hello

I have been running happily with pr_service for two months.
Unfortunately, due to a power down the computer running the pr server
has stopped.
When I have started the server I have discovered that all the
information about PR was lost :S. I assumed this was due to a db
corruption, but I have later discovered that the database is not
synced after every insert.

I guess this is to improve the performance, but I don't think that
everybody prefer this behaviour, right now I have to remake and
distribute only 10 flashes, something reasonable, but it would have a
disaster later in our development cycle.

Is somebody working on a parameter for the db to be persistent? Would
a patch to implement this be considered?

Regards

-- 
Ricardo Ribalda

Re: PR_Service. Sync database only on clean stop?

[Richard Purdie]

On Wed, 2014-06-04 at 22:52 +0200, Ricardo Ribalda Delgado wrote:
> Hello
> 
> I have been running happily with pr_service for two months.
> Unfortunately, due to a power down the computer running the pr server
> has stopped.
> When I have started the server I have discovered that all the
> information about PR was lost :S. I assumed this was due to a db
> corruption, but I have later discovered that the database is not
> synced after every insert.
> 
> I guess this is to improve the performance, but I don't think that
> everybody prefer this behaviour, right now I have to remake and
> distribute only 10 flashes, something reasonable, but it would have a
> disaster later in our development cycle.
> 
> Is somebody working on a parameter for the db to be persistent? Would
> a patch to implement this be considered?

The trouble if I remember rightly is that the way the queries work in
there, you can't tell if an update was made the database during the read
or not. The older code therefore synced on *every* read and this was a
significant bottleneck.

So patches would be considered and I agree the current behaviour is bad
but we need to be mindful of performance too. Some kind of idle sync on
a timer might be better than specific numbers for example, particularly
if we can query whether the data is "dirty" before running the sync
commands.

Cheers,

Richard