On Wed, 7 May 2014 18:44:13 -0400, "Claudio Valderrama C."
wrote:
>> As the value of RDB$TRANSACTION_STATE is modified, I assume
>> this code (or
>> something very similar) is actually called, but then the `else` branch
>> shown above. What does TRA_prepare2 mean here? Note that the specific
>> s
FB crashes when using row_number()over( PARTITION BY x) in ORDER by clause
---
Key: CORE-4422
URL: http://tracker.firebirdsql.org/browse/CORE-4422
Project: Firebird Core
Hello, All.
If a record is inserted or modified, what will be order of page written:
data page
first then index page or vice versa?
--
WBR, SD.
--
Is your legacy SCM system holding you back? Join Perforce May
Hello, All.
Which data state is supposed to be seen in WHEN block? Before undoing
changes or after it?
Say, we have "update t set f=1" then in begin-end block "update set f=2" is
done and
then exception is thrown. What value should give "select f from t" in WHEN
block? 1 or 2?
--
On Thu, 08 May 2014 16:44:08 +0200, Dimitry Sibiryakov
wrote:
> Hello, All.
>
>Which data state is supposed to be seen in WHEN block? Before undoing
>changes or after it?
>Say, we have "update t set f=1" then in begin-end block "update set
>f=2" is done and
> then exception is thr
That's an impossible problem to solve, which is one of the many reasons
that retrievals consider the index to be potentially noisy.
That said, in the original implementation, at least, a transaction
couldn't commit until everything touched had been written. But what
constituted a write was al
08.05.2014 18:13, Dimitry Sibiryakov wrote:
>
> If a record is inserted or modified, what will be order of page written: data
> page
> first then index page or vice versa?
IIRC, there is no precedence dependency between these two pages, so they
can be written in any order.
Dmitry
---
08.05.2014 18:44, Dimitry Sibiryakov wrote:
>
> Which data state is supposed to be seen in WHEN block? Before undoing changes
> or after it?
> Say, we have "update t set f=1" then in begin-end block "update set f=2" is
> done and
> then exception is thrown. What value should give "select f from t
08.05.2014 19:22, Dmitry Yemanov wrote:
> IIRC, there is no precedence dependency between these two pages, so they
> can be written in any order.
So, with FW=OFF, killing server in-between can produce both orphan nodes and
missing
entries depending on luck and parallel activity.
--
WBR,
> 08.05.2014 19:22, Dmitry Yemanov wrote:
> > IIRC, there is no precedence dependency between these two pages, so
> > they can be written in any order.
>
>So, with FW=OFF, killing server in-between can produce both orphan nodes
> and missing entries depending on luck and parallel activity.
08.05.2014 19:49, Leyne, Sean wrote:
> True, but that is database corruption problem, not an order of precedence
> issue.
Orphan nodes are harmless, missing entries are worse.
--
WBR, SD.
--
Is your legacy SCM sy
08.05.2014 21:49, Leyne, Sean wrote:
>
>>> IIRC, there is no precedence dependency between these two pages, so
>>> they can be written in any order.
>>
>> So, with FW=OFF, killing server in-between can produce both orphan nodes
>> and missing entries depending on luck and parallel activity.
>
> Tru
08.05.2014 20:05, Dmitry Yemanov wrote:
> 2) There's no much difference between FW ON and OFF in this particular
> case. Even with forced writes enabled, the server may die in between
> writing those pages.
In this case transaction won't be marked as committed and record will be
garbage
colle
08.05.2014 22:01, Dimitry Sibiryakov wrote:
>> True, but that is database corruption problem, not an order of precedence
>> issue.
>
> Orphan nodes are harmless, missing entries are worse.
We're talking about [missing] entries that should be pointing to
invisible (garbage) record versions. What
08.05.2014 22:08, Dimitry Sibiryakov wrote:
> In this case transaction won't be marked as committed and record will be
> garbage
> collected sooner or later.
Ah, so you meant the case where both TIP and the data page were written
to disk, but the index page was not? Here I agree that FW=OFF mak
> >> So, with FW=OFF, killing server in-between can produce both orphan
> >> nodes and missing entries depending on luck and parallel activity.
> >
> > True, but that is database corruption problem, not an order of precedence
> issue.
> >
> > That is why using FW=OFF in a production environment (
Failures happen.
No matter how much you spend, how much time you design, failures happen.
You might even have a boss who thinks its fun to randomly shut off machines
to ensure the load balancing and fail over systems work
So, you design with failure in mind.
This is a discussion that is
08.05.2014 23:15, Leyne, Sean wrote:
>
> I was referring to cases where the disk controller has ignored the engine
> careful write order, by "collapsing" disk sector writes and applying them in
> a sequence optimal for the disk but out of order from a FB perspective (Jim's
> comment about micro
18 matches
Mail list logo
