You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
C:\TEMP>C:\MIX\firebird\fb30\gfix -online normal localhost/3333:C:\TEMP\TMP1610012108_FB30.FDB --------------- [ 1 ] PASSED! NO ERRORS!
C:\TEMP>C:\MIX\firebird\fb30\gstat -h localhost/3333:C:\TEMP\TMP1610012108_FB30.FDB | findstr /i /c:attrib
Attributes force write --------------------------------------------------------------------------------------------------------------- NO "single-user maintenance" here
C:\TEMP>C:\MIX\firebird\fb30\isql localhost/3333:C:\TEMP\TMP1610012108_FB30.FDB
Database: localhost/3333:C:\TEMP\TMP1610012108_FB30.FDB, User: SYSDBA
SQL> select d.mon$shutdown_mode, a.mon$attachment_id, a.mon$user from mon$database d, mon$attachments a where a.mon
$attachment_id<>current_connection and a.mon$remote_protocol is not null;
FB 2.5.7 will issue error "database C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\BUGS.CORE_4742.FDB shutdown" at point marked as [1] and not new attachment to database is allowed.
It seems to me that new behaviour (in FB 3.0) is dangerous: SYSDBA-1 that is doing something in Window-1 will not even alerted that database is online and ANY other users can make attachments because of action that just did SYSDBA-2 in Window-2.
PPS.
Problem is more general: 2.5.7 SuperServer is also affected (checked on WI-V2.5.7.27026).
So, we have different behaviour on SuperServer vs [Super]Classic architectures, both in 2.5 & 3.0.
summary: Regression(?) in 3.0: gstat -online normal <db> (being issued in window #1) does not produce error when there is sysdba attachment in window #2 => Regression(?) in 3.0: gfix -online normal <db> (being issued in window #1) does not produce error when there is sysdba attachment in window #2
summary: Regression(?) in 3.0: gfix -online normal <db> (being issued in window #1) does not produce error when there is sysdba attachment in window #2 => gfix -online normal <db> (being issued in window #1) does not produce error when there is sysdba attachment in window #2
Submitted by: @pavel-zotov
I'm not sure is this regression or no, but:
Window 1
C:\MIX\firebird\fb30\isql -q -z
ISQL Version: WI-V3.0.1.32609 Firebird 3.0
SQL> create database 'localhost/3333:c:\temp\tmp1610012108_fb30.fdb';
Server version:
WI-V3.0.1.32609 Firebird 3.0
WI-V3.0.1.32609 Firebird 3.0/tcp (csprog)/P14
WI-V3.0.1.32609 Firebird 3.0/tcp (csprog)/P14
SQL> quit;
Window 2
C:\TEMP>C:\MIX\firebird\fb30\gfix -shut single -force 0 localhost/3333:C:\TEMP\TMP1610012108_FB30.FDB
C:\TEMP>C:\MIX\firebird\fb30\gstat -h localhost/3333:C:\TEMP\TMP1610012108_FB30.FDB | findstr /i /c:attrib
Attributes force write, single-user maintenance
Window 1
C:\MIX\firebird\QA\fbt-repo\tmp>C:\MIX\firebird\fb30\isql -q
SQL> connect 'localhost/3333:c:\temp\tmp1610012108_fb30.fdb' ;
Database: 'localhost/3333:c:\temp\tmp1610012108_fb30.fdb', User: SYSDBA
SQL>
Window 2
C:\TEMP>C:\MIX\firebird\fb30\gfix -online normal localhost/3333:C:\TEMP\TMP1610012108_FB30.FDB --------------- [ 1 ] PASSED! NO ERRORS!
C:\TEMP>C:\MIX\firebird\fb30\gstat -h localhost/3333:C:\TEMP\TMP1610012108_FB30.FDB | findstr /i /c:attrib
Attributes force write --------------------------------------------------------------------------------------------------------------- NO "single-user maintenance" here
C:\TEMP>C:\MIX\firebird\fb30\isql localhost/3333:C:\TEMP\TMP1610012108_FB30.FDB
Database: localhost/3333:C:\TEMP\TMP1610012108_FB30.FDB, User: SYSDBA
SQL> select d.mon$shutdown_mode, a.mon$attachment_id, a.mon$user from mon$database d, mon$attachments a where a.mon
$attachment_id<>current_connection and a.mon$remote_protocol is not null;
MON$SHUTDOWN_MODE 0
MON$ATTACHMENT_ID 11
MON$USER SYSDBA
SQL> quit;
FB 2.5.7 will issue error "database C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\BUGS.CORE_4742.FDB shutdown" at point marked as [1] and not new attachment to database is allowed.
It seems to me that new behaviour (in FB 3.0) is dangerous: SYSDBA-1 that is doing something in Window-1 will not even alerted that database is online and ANY other users can make attachments because of action that just did SYSDBA-2 in Window-2.
Commits: 95f0135 c94e45b
The text was updated successfully, but these errors were encountered: