here is build log
http://firebird.1100200.n4.nabble.com/file/n3513424/build.log build.log
--
View this message in context:
http://firebird.1100200.n4.nabble.com/ERROR-firebird-msg-not-found-when-build-Firebird-2-1-3-or-2-1-4-tp3510915p3513424.html
Sent from the firebird-devel mailing list archiv
I have merged the following patches
sparc-no-m32.patch
powerpc-no-mcpu.patch
I review now the follwing that was needed for sh port
atomic_ops_require_cas.patch
>From the list of patches
http://git.debian.org/?p=pkg-firebird/2.5.git;a=tree;f=debian/patches;h=edad9438a0d331ca98e1c5fab9d5eaeae37223
On 05/10/11 11:40, Vlad Khorsun wrote:
>> Do we really need the SharedCache option in production?
> It was implicitly introduced by Alex and i just add it to the config
> file. I see no problem
> if we remove it - less options is less headache for us and for users :)
>
That means that we dr
On 05/10/11 07:36, wuu wrote:
> hi, all. I need help, when build Firebird 2.1.3 or 2.1.4.
>
> CPU info : freescale P2020 QorIQ, powerpc e500v2 core
..
> Any ideas how to fix it?
First of all provide full build log.
---
On 05/09/11 14:06, Vlad Khorsun wrote:
> To run SuperClassic you should use switch -m in command line of
> firebird.exe
> (on Windows) or run fb_smp_server (on Posix, here i'm not sure and Alex will
> correct me)
Small correction. There is no more fb_smp_server on posix. There is also
single
On 05/09/11 21:15, Dimitry Sibiryakov wrote:
> 09.05.2011 18:48, Leyne, Sean wrote:
>>> I disagree. Shadow is the only method for synchronous replication in
>>> Firebird now.
>> Synchronous replication on a single server is not replication.
>Don't forget about NFS and iSCSI(?).
Why _only_
>>> Are there any database-level ASTs known to implicitly access the
>>> attachments? When should they lock the appropriate mutex?
>>
>> Database-level ASTs not need to access attachment internals usually.
>
> "Usually" differs from "always" :-) I seem to remember cases when the
> AST saves lck_a
10.05.2011 10:11, Vlad Khorsun wrote:
>>In this case may I suggest to use separate memory pool for the cache's
>> elements?..
>
> It is already separate
>
>> Someday someone could implement shared memory pool...
>
> It is already shared ;)
Shared between processes, I mean.
--
10.05.2011 11:40, Vlad Khorsun wrote:
>> Are there any database-level ASTs known to implicitly access the
>> attachments? When should they lock the appropriate mutex?
>
> Database-level ASTs not need to access attachment internals usually.
"Usually" differs from "always" :-) I seem to remember ca
> In this case may I suggest to use separate memory pool for the cache's
> elements?..
It is already separate
> Someday someone could implement shared memory pool...
It is already shared ;)
Regards,
Vlad
--
10.05.2011 9:53, Vlad Khorsun wrote:
As long as it
keeps launching one process per connection, there's no difference
between SharedCache being true or false, as there will always be only
one Database/Attachment pair per process.
>>>
>>> Sure
>>
>>Isn't the cache shared
10.05.2011 11:46, Dimitry Sibiryakov wrote:
> Isn't the cache shared between processes?
In your dreams, perhaps. There was never such a goal.
Dmitry
--
Achieve unprecedented app performance and reliability
What every C
>>> As long as it
>>> keeps launching one process per connection, there's no difference
>>> between SharedCache being true or false, as there will always be only
>>> one Database/Attachment pair per process.
>>
>> Sure
>
> Isn't the cache shared between processes?
No. There was never s
10.05.2011 9:40, Vlad Khorsun wrote:
>> As long as it
>> keeps launching one process per connection, there's no difference
>> between SharedCache being true or false, as there will always be only
>> one Database/Attachment pair per process.
>
> Sure
Isn't the cache shared between processes
>> All metadata objects moved into Attachment. Metadata syncronization is
>> guarded
>> by attachment's mutex now. Database::SyncGuard and company are replaced by
>> corresponding Attachment::XXX classes.
>>
>> To make AST's work we need to release attachment mutex sometimes. This is
>> very
>> i
15 matches
Mail list logo
