Hi,
I'm a bit puzzled by the results I get
I made test on Fedora 16 with Kernel 3.1.1-1.fc16.x86_64 on LVM2 Logical
Volume of 10G
Firebird 2.5.1 Classic
hdparm /dev/vg_tests/testfb
/dev/vg_tests/testfb:
multcount = 0 (off)
IO_support= 1 (32-bit)
readonly = 0 (off)
readahead
17.11.2011 4:39, Frank Ingermann wrote:
a) [ ] file it as a bug - this _should_ work!
This would get my vote, as it works fine (and returns rows in the
expected order) in PGSQL.
Dmitry
--
All the data continuously
17.11.2011 12:59, Philippe Makowski wrote:
I really wonder if we can't get MaxUnflushedWrites or something like
that under Linux too
I would be curious to do same test with this parameter under Linux
It works for all platforms, you just need to uncomment and set it up in
firebird.conf.
Dmitry Yemanov [2011-10-25 17:55] :
25.10.2011 14:39, Philippe Makowski wrote:
in fact with theses settings, FW=OFF is safer than before
safe enough to be the default ?
Even in the paranoid mode (MaxUnflushedWrites = 1) they still don't
guarantee the write order. So, if the crash
On 11/17/11 11:37, Dmitry Yemanov wrote:
17.11.2011 11:26, Alex Peshkoff wrote:
And one more interesting line:
open(./fb_init, O_RDWR|O_CREAT|O_LARGEFILE, 0600) = 7
Why is _SHARED_ file opened in CWD? It should go to /tmp/firebird.
Because he explicitly sets FIREBIRD_LOCK to CWD before
17.11.2011 13:49, Thomas Steinmaurer wrote:
the previously reported bug in the Trace API is a bit nasty for
customers how are extensively using the Trace stuff.
I wonder if there is some kind of time frame for releasing 2.5.2
available, because for people coming from 2.1, they can't download
Dmitry Yemanov [2011-11-17 10:52] :
The only way to guarantee ordered writes is to flush individual pages
and this is what FW=ON does.
and that's what cost a lot
so without WAL, no clear guarantied solution
but WAL is another problem
I see
Adriano dos Santos Fernandes [2011-11-17 11:14] :
On 17/11/2011 07:52, Dmitry Yemanov wrote:
The only way to guarantee ordered writes is to flush individual pages
and this is what FW=ON does.
Or to flush group of independent pages at once, like I proposed. I think
this can be a great
17.11.2011 14:14, Adriano dos Santos Fernandes wrote:
Or to flush group of independent pages at once, like I proposed.
Sure. I was speaking about the current code only.
Dmitry
--
All the data continuously generated
Dmitry Yemanov [2011-10-25 17:55] :
25.10.2011 14:39, Philippe Makowski wrote:
in fact with theses settings, FW=OFF is safer than before
safe enough to be the default ?
Even in the paranoid mode (MaxUnflushedWrites = 1) they still don't
guarantee the write order. So, if the crash
On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
On 17/11/2011 07:52, Dmitry Yemanov wrote:
The only way to guarantee ordered writes is to flush individual pages
and this is what FW=ON does.
Or to flush group of independent pages at once, like I proposed. I think
this can be a great
On 17/11/2011 09:19, Alex Peshkoff wrote:
On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
On 17/11/2011 07:52, Dmitry Yemanov wrote:
The only way to guarantee ordered writes is to flush individual pages
and this is what FW=ON does.
Or to flush group of independent pages at once, like
On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
On 17/11/2011 07:52, Dmitry Yemanov wrote:
The only way to guarantee ordered writes is to flush individual pages
and this is what FW=ON does.
Or to flush group of independent pages at once, like I proposed. I think
this can be a great
On 11/17/11 15:37, Vlad Khorsun wrote:
On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
On 17/11/2011 07:52, Dmitry Yemanov wrote:
The only way to guarantee ordered writes is to flush individual pages
and this is what FW=ON does.
Or to flush group of independent pages at once, like I
On 11/17/11 15:23, Adriano dos Santos Fernandes wrote:
On 17/11/2011 09:19, Alex Peshkoff wrote:
On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
On 17/11/2011 07:52, Dmitry Yemanov wrote:
The only way to guarantee ordered writes is to flush individual pages
and this is what FW=ON
17.11.2011 15:37, Vlad Khorsun wrote:
And, note, most heavy case (flush on commit) is already optimized.
With FW=ON, it's optimized only for better write order (less HDD head
movements). But AFAIU we're talking here about batched writes instead of
singleton writes.
Dmitry
On 16-11-2011 22:39, Frank Ingermann wrote:
...but it leads to an endless loop/recursion (using latest Fb3 beta)
:-(
Before decide what to do, I'd like to hear Vlad about the error
isc_dsql_cte_wrong_clause, which, for example, happens if a recursive
query has a GROUP BY.
Why is it
17 matches
Mail list logo
