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
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
[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
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 subj into trunk.
For procedure parameters, the syntax is:
COMMENT ON PARAMETER proc name.param name IS text
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 func name.param name
This matches the system table name (RDB$FUNCTION_ARGUMENTS) but we
already use the keyword PARAMETER in the syntax RETURNS PARAMETER n 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] 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
