28.08.2018 13:39, Adriano dos Santos Fernandes wrote:
On 28/08/2018 02:20, Dmitry Yemanov wrote:
27.08.2018 20:10, Adriano dos Santos Fernandes wrote:
the whole thing may execute repeated times
Imagine selectable SP/UDR joined to a table. Depending on the plan,
SP/UDR may be executed once or multiple times. You have virtually no
control over this. If that SP/UDR has "side effects", you'll need to
deal with the consequences. I don't see much difference from the
"statement consistency issue" you mention. Of course, repeated
execution may be less/not expected in more straightforward execution
paths, but it doesn't mean it's absolutely impossible.
This is completely different.
For this discussion, let name SQL as (SELECT / UPDATE / INSERT / MERGE /
UPDATE OR INSERT) and PSQL the others statements.
SQL (even when embedded in a PSQL statement) is a declarative language.
Programmer does not tell it each necessary pass to do an action, so
engine is free to produce the result.
We all known that a function used there may be evaluated in an undefined
number of times. So it's clear that one should not call a function with
side effects there.
Some DBMS like Oracle prevents that function called in SQL writes to the
database. We don't but that is still considered as an undefined behavior
if one does.
PSQL on the other hand is an imperative language. Programmer tell it how
to do things and calling functions with side effects is completely ok
and necessary. One does not expect that engine reorder and recalls a
function.
Oracle does not implement statement consistency only delimited to an SQL
(instead PL/SQL) because its loose integration, but because it's
completely nonsense to do the contrary.
Do you have arguments with some sense except of plain "nonsence" ?
Yes, multiple SQL statements may read different data, but that is READ
COMMITTED.
There is a big differense in how that SQL statements relate to each other.
Sequence of SQL statements issued by client is one major case but execution
tree of SQL statement with nested SQL statements is very different case.
And it seems very logical to run whole execution tree within the same snapshot
view of the database. This is consistency.
When UPDATE see some set of rows and call trigger which call stored procedure
and it sees another set of rows - it is not consistency.
What's being done here is equivalent to an CPU processor doing
speculative instruction execution crossing IO boundaries. You don't want
to see in your screen a thing happening that your program don't want to
do but your CPU does, or to see it multiple times.
I don't understand this analogue
This is nonsense
Not agree
and at the same time it documents that the old behavior
is deprecated and could be removed in a future release.
This can be discussed.
None of this was even discussed in details.
Not really so...
There was few attempts to start such discussion, i published current
documentation
a few weeks before merged the patch, the initial code was published few years
ago,
all commits were made at public repository - what else do you need ?
The patch is initially
described by Nikolay in 2014 with Vlad commenting "Comments in code is
good but not enough
to understand idea, rules and correctness of implementation".
You missed previous discission, see thread "Cursor stability in READ COMMITTED
transactions" started by Nickolay at 21.06.2014 and my response at 23.06.2014
where i ask:
----------------
Could you explicitly describe behavior of sub-requests, dynamic request in
the same transaction
(EXECUTE STATEMENT) and requests, running in autonomous transactions ?
----------------
and answer was
----------------
Subrequests and EXECUTE STATEMENT requests share snapshot with top-level
request.
Autonomous transactions establish their own snapshot.
Sub-transaction logic now applies not only to isc_tpb_concurrency, but also to
isc_tpb_read_committed transactions.
----------------
All of this was vaguely explained until I reviewed the final version of
the code. A "statement-level consistency" is a thing, a top-level
request restart is a completely different thing.
Request restart logic was not discussed because it was not present at initial
patch by Nickolay. Everyone, who understand "common snapshot for whole statement
execution tree" might see that request restart in case of update conflicts is
logically consequent with it.
Let discuss it, but keep calm and breath deep, pls.
So, what you are argue with:
- common snapshot for whole statement execution tree,
- top-level request restart,
- both,
- something else ?
Regards,
Vlad
PS my e-mail provider had problems, therefore i answer just now, sorry
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
