On 05/26/2016 08:30 AM, Dmitry Yemanov wrote:
> 25.05.2016 18:21, Roman Simakov wrote:
>
>> Am I the only who run tests in developer build sometimes?
> Me too, but rarely.
>
I run sometimes fbtcs on DEV builds, but typically after making some
non-trivial changes before commit.
-
Losing a comment to the view
Key: CORE-5253
URL: http://tracker.firebirdsql.org/browse/CORE-5253
Project: Firebird Core
Issue Type: Bug
Affects Versions: 3.0.0
Environment: Firebird-3.0.1.32525-0_x64
isc_que_events callback function randomly return invalid Update Buffer
--
Key: CORE-5254
URL: http://tracker.firebirdsql.org/browse/CORE-5254
Project: Firebird Core
Issue Ty
25.05.2016 18:52, Dmitry Yemanov wrote:
> Here is sequence of savepoints generated in this test:
>>
>> >>Request to rollback to 11. Stack is 14->11->5->10->1->
>> >>Request to rollback to 10. Stack is 5->10->1->
I tried to fix that by reusing savepoints started by looper. For that I
added
req
26.05.2016 15:19, Dimitry Sibiryakov wrote:
> I tried to fix that by reusing savepoints started by looper. For that I
> added
> req_savepoints to request and in looper I store savepoint there after merging
> it the same
> way as SP savepoints are stored in req_proc_sav_point.
> So far so
26.05.2016 15:19, Dimitry Sibiryakov wrote:
>
> Why releasing of savepoints from SP don't crash?
Because procedure/function/trigger invocation always ends with
EXE_unwind. This is not so for DSQL requests.
Dmitry
26.05.2016 14:39, Dmitry Yemanov wrote:
> Where req_active is cleared. IIRC, one place is in the looper, second
> one is inside EXE_unwind.
It would be too early, AFAIU. The main idea behind is to keep looper
savepoints in sync
with SP savepoints, so ideally, they should be destroyed together
Em 26/05/2016 05:18, Alex Peshkoff escreveu:
> On 05/26/2016 08:30 AM, Dmitry Yemanov wrote:
>> 25.05.2016 18:21, Roman Simakov wrote:
>>
>>> Am I the only who run tests in developer build sometimes?
>> Me too, but rarely.
>>
>
> I run sometimes fbtcs on DEV builds, but typically after making some
