[Firebird-devel] nbackup: CORE-3521 and CORE-2648
Hello, currently investigating nbackup reliability/bugs. CORE-2648 is marked as fixed in 2.1.4 and CORE-3521, which is currently open, seems to like similar (forced writes vs. flushing to disc). How do they differ? Thanks. Regards, Thomas -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] nbackup: CORE-3521 and CORE-2648
> Hello, > > currently investigating nbackup reliability/bugs. CORE-2648 is marked as > fixed in 2.1.4 and CORE-3521, which is currently open, seems to like > similar (forced writes vs. flushing to disc). > > How do they differ? CORE-2648 set FW mode for delta file in the same value as of main database file. CORE-3521 flushed delta file buffers when main database files buffers are flushed. This is different things. FW mode defines how OS file cache will handle writes. When FW is OFF then file system free to accumulate writes in file cache and do actual writes when OS think it is necessary\feasible. When FW is ON then file system still cached data pages but not delayed physical writes to disk. Flushing is different thing. It instructs OS to write all dirty cached buffers of given file immediately. Firebird calls flush every time some transaction is finished and on disconnect (look also at MaxUnflushedWrites and MaxUnflushedWriteTime settings at firebird.conf). Note, when FW is ON then OS shouldn't have dirty buffers and Firebird do not flushed its files. So, before CORE-2648 was fixed, delta file was always opened in FW=OFF mode despite of database settings. Before CORE-3521 was fixed delta file contents was not flushed to disk when transactions finished. Hope it is clear, Vlad PS CORE-3521 is not marked as fixed because it is not backported into 2.1.5 still. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] nbackup: CORE-3521 and CORE-2648
Hello Vlad, >> currently investigating nbackup reliability/bugs. CORE-2648 is marked as >> fixed in 2.1.4 and CORE-3521, which is currently open, seems to like >> similar (forced writes vs. flushing to disc). >> >> How do they differ? > > CORE-2648 set FW mode for delta file in the same value as of main > database file. > > CORE-3521 flushed delta file buffers when main database files buffers > are flushed. > > This is different things. FW mode defines how OS file cache will handle > writes. > When FW is OFF then file system free to accumulate writes in file cache and do > actual writes when OS think it is necessary\feasible. When FW is ON then file > system still cached data pages but not delayed physical writes to disk. > > Flushing is different thing. It instructs OS to write all dirty cached > buffers of given file > immediately. Firebird calls flush every time some transaction is finished and > on disconnect > (look also at MaxUnflushedWrites and MaxUnflushedWriteTime settings at > firebird.conf). > Note, when FW is ON then OS shouldn't have dirty buffers and Firebird do not > flushed its files. > > So, before CORE-2648 was fixed, delta file was always opened in FW=OFF > mode > despite of database settings. So, if the server crashes, we have a problem here? Or does writing the delta file also take both config options mentioned above into account? Before CORE-3521 was fixed delta file contents was not > flushed to disk when transactions finished. So, without a fix for CORE-3521, cached dirty pages aren't written to disk while nbackup is running at all? Do both issues relate to corrupting the database in any way? Thanks for your feedback! > Hope it is clear, > Vlad > > PS CORE-3521 is not marked as fixed because it is not backported into 2.1.5 > still. Ok. Thanks. Regards, Thomas -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] nbackup: CORE-3521 and CORE-2648
>> So, before CORE-2648 was fixed, delta file was always opened in FW=OFF >> mode >> despite of database settings. > > So, if the server crashes, we have a problem here? If database setting is FW = ON but (before the fix) delta file is opens with FW = OFF then Firebird crash in stalled (or merge) mode could corrupt delta file contents. Note, it *could be* corrupted but it is not necessary since OS still have dirty pages in its file cache and will write it on disk sooner or later. But if OS is crashed then corruption is very possible. > Or does writing the > delta file also take both config options mentioned above into account? Of course. >> Before CORE-3521 was fixed delta file contents was not >> flushed to disk when transactions finished. > > So, without a fix for CORE-3521, cached dirty pages aren't written to > disk while nbackup is running at all? If FW = ON, then this bug should have no impact. If FW=OFF then *on disk* contents of delta file fully depends on OS and its policy of delayed writes. I.e. it is OS decides when to write dirty pages on disk. Since bug is fixed we have equal safety in any nbackup mode. > Do both issues relate to corrupting the database in any way? Probably. Regards, Vlad -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] nbackup: CORE-3521 and CORE-2648
>>> So, before CORE-2648 was fixed, delta file was always opened in >>> FW=OFF mode >>> despite of database settings. >> >> So, if the server crashes, we have a problem here? > > If database setting is FW = ON but (before the fix) delta file is opens > with FW = OFF > then Firebird crash in stalled (or merge) mode could corrupt delta file > contents. Note, it > *could be* corrupted but it is not necessary since OS still have dirty pages > in its file cache > and will write it on disk sooner or later. > > But if OS is crashed then corruption is very possible. > >> Or does writing the >> delta file also take both config options mentioned above into account? > > Of course. > >>> Before CORE-3521 was fixed delta file contents was not >>> flushed to disk when transactions finished. >> >> So, without a fix for CORE-3521, cached dirty pages aren't written to >> disk while nbackup is running at all? > > If FW = ON, then this bug should have no impact. FW = ON for the database or the delta file? If it is the delta file, then I have to use an engine version with CORE-2648 fixed as well. If FW=OFF then *on disk* contents of delta > file fully depends on OS and its policy of delayed writes. I.e. it is OS > decides when to write dirty > pages on disk. Since bug is fixed we have equal safety in any nbackup mode. > >> Do both issues relate to corrupting the database in any way? > > Probably. Thanks! Regards, Thomas -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] build problem - gpre - firebird3
On Wednesday 13 July 2011 14:07:14 Treeve Jelbert wrote: > I tried building firebird3 on linux - amd64, in order to test boolean > support using svn revision #53289 > > It appears that the makefile tries to link both gpre_meta_boot.o and > gpre/gpre_meta.o when building gpre_boot problem resolved. there were some extraneous files in the source tree left over from building firebird25 Regards -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-3556) Numeric may be set to more that specidied precision
Numeric may be set to more that specidied precision --- Key: CORE-3556 URL: http://tracker.firebirdsql.org/browse/CORE-3556 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.1.3 Environment: Firebird 2.1 64bit Windows 7 sp1 dialect 3 (!) Reporter: Roman Krivykh CREATE TABLE TEST ( B NUMERIC(18,5) DEFAULT 0 NOT NULL ); insert into test values1.199) select iif(b = 1.10002, 'true', 'false') from test returns true Is that how it must work? Do I missed something? Similar issues claims that this behavior is impossible with dialect 3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] nbackup during TPC-H database generation (scale: 1GB)
Hello, I ran a quick test of nbackup with Firebird 2.1.4 Classic 32-bit during a TPC-H database generation with scale 1GB. So, a simulated load (insert into statements by the TPC-H generation thingy) in combination with executing nbackup. A first full backup of the database after ~ 30 sec. after the database generation/fill has started worked fine. Then I did a first level 1 backup. Went fine. Another level 1 backup. Went fine again. The next level 1 backup hangs now, the delta file fills up and any other database attachments to the database hang as well, so no additional database attachments possible. I'm gonna wait now if everything goes back to normal => merging a rather largish delta file with additional attachments possible. Anyway, have there been any nbackup related tests under load? Should the above work differently, e.g. additional attachments should be possible (there is no exception, simply the CONNECT statement hangs) Thanks! Regards, Thomas -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] nbackup during TPC-H database generation (scale: 1GB)
Hello, Thomas! Thursday, July 14, 2011, 6:03:10 PM, you wrote: TS> I ran a quick test of nbackup with Firebird 2.1.4 Classic 32-bit during TS> The next TS> level 1 backup hangs now, the delta file fills up and any other database TS> attachments to the database hang as well, so no additional database TS> attachments possible. 2.1.4 is old, use higher version. And, you may also look at tracker for the keyword "nbackup". Have fun. -- Dmitry Kuzmenko, www.ibase.ru, (495) 953-13-34 -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] nbackup during TPC-H database generation(scale: 1GB)
TS> I ran a quick test of nbackup with Firebird 2.1.4 Classic 32-bit during TS> The next TS> level 1 backup hangs now, the delta file fills up and any other database TS> attachments to the database hang as well, so no additional database TS> attachments possible. > 2.1.4 is old, use higher version. > And, you may also look at tracker for the keyword "nbackup". > Have fun. And use a 2.5.x snapshot - a number of fixes re. hangs, performance etc regarding nbackup have been this. I suspect his is what Dimitry is alluding to. Paul -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Comments for function parameters
All,
I've faced problems while adding into trunk.
For procedure parameters, the syntax is:
COMMENT ON PARAMETER . IS
However, procedures and functions have different namespaces, so there
may be a function and its input parameter with exactly the same names.
Thus this syntax doesn't look suitable for functions. Other options, as
I see them, are underneath.
1) Extend the syntax but preserve backward compatibility via default:
COMMENT ON [{PROCEDURE | FUNCTION}] PARAMETER ...
if the keyword is omitted, procedure parameter is implied. But user
mistakes are possible in this case.
2) Introduce a separate keyword:
COMMENT ON ARGUMENT .
This matches the system table name (RDB$FUNCTION_ARGUMENTS) but we
already use the keyword PARAMETER in the syntax RETURNS PARAMETER in
the UDF declaration, so having the same thing named differently doesn't
look nice.
Any other ideas?
Dmitry
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Comments for function parameters
I'm now convincing myself to the third option:
> Extend the syntax but preserve backward compatibility via default:
>
> COMMENT ON [{PROCEDURE | FUNCTION}] PARAMETER ...
but if the object type specifier is omitted, then the engine tries to be
smart and determine whether it's a procedure or a function at runtime
(by searching in both tables). In the case both exist with the same
names, an ambiguity error is thrown.
Dmitry
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Comments for function parameters
14.07.2011 18:33, Dmitry Yemanov wrote: > I'm now convincing myself to the third option: For me this option looks better than previous two. -- SY, SD. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] nbackup during TPC-H database generation (scale: 1GB)
> Thursday, July 14, 2011, 6:03:10 PM, you wrote: > > TS> I ran a quick test of nbackup with Firebird 2.1.4 Classic 32-bit during > TS> The next > TS> level 1 backup hangs now, the delta file fills up and any other database > TS> attachments to the database hang as well, so no additional database > TS> attachments possible. > > 2.1.4 is old, use higher version. Na, 2.1.4 isn't old for production systems. It's the most recent stable 2.1 release. ;-) > And, you may also look at tracker for the keyword "nbackup". I'm getting an expert in using the Jira client, so usually I lookup stuff in the tracker. ;-) But, right, I will take Paul's comment into account, to get some comparison figures in respect to 2.1 and 2.5, thus being able to argue with German speaking people who reported nbackup problems to me. Regards, Thomas -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Comments for function parameters
Dmitry wrote:
> > Extend the syntax but preserve backward compatibility via default:
> >
> > COMMENT ON [{PROCEDURE | FUNCTION}] PARAMETER ...
>
> but if the object type specifier is omitted, then the engine tries to be
> smart and determine whether it's a procedure or a function at runtime
> (by searching in both tables). In the case both exist with the same
> names, an ambiguity error is thrown.
This would definitely be my preference, rather than creating an arbitrary
difference between a procedure PARAMETER and a function ARGUMENT.
It's analogous to selecting unqualified column names from a JOIN: you can do
it, but if the column exists in more then one participant, an error is thrown.
My 2 cts.
Paul Vinkenoog
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] nbackup: CORE-3521 and CORE-2648
Before CORE-3521 was fixed delta file contents was not flushed to disk when transactions finished. >>> >>> So, without a fix for CORE-3521, cached dirty pages aren't written to >>> disk while nbackup is running at all? >> >> If FW = ON, then this bug should have no impact. > > FW = ON for the database or the delta file? If it is the delta file, > then I have to use an engine version with CORE-2648 fixed as well. For database of course. We have no way to set FW for delta separately :) Regards, Vlad -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
