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
Copy file name to clipboardExpand all lines: doc/README.replication.md
+2-1
Original file line number
Diff line number
Diff line change
@@ -47,7 +47,8 @@ ALTER DATABASE EXCLUDE ALL FROM PUBLICATION
47
47
-- to disable replication of specific tables:
48
48
ALTER DATABASE EXCLUDE TABLE T1, T2, T3 FROM PUBLICATION
49
49
50
-
Tables enabled for replicated can be additionally filtered using two settings in the configuration file: include\_filter and exclude\_filter. They are regular expressions that are applied to table names and define rules for inclusion table\(s\) into the replication set or excluding them from the replication set.
50
+
Tables enabled for replicated can be additionally filtered using four settings in the configuration file: include\_schema\_filter, exclude\_schema\_filter, include\_filter and exclude\_filter.
51
+
They are regular expressions that are applied to schema and table names and define rules for inclusion table\(s\) into the replication set or excluding them from the replication set.
51
52
52
53
Synchronous replication can be turned on using the sync\_replica setting \(multiple entries are allowed\). It must specify a connection string to the replica database, prefixed with username/password. In SuperServer and SuperClassic architectures, replica database is being internally attached when the first user gets connected to the master database and detached when the last user disconnects from the master database. In Classic Server architecture, every server process keeps an active connection to the replica database.
Snapshot tables (as well views and sequence) are automatically created in the first usage of the profiler. They are owned by the database owner, with read/write permissions for `PUBLIC`.
248
+
The profiler schema, snapshot tables, views and sequence are automatically created in the first usage of the profiler.
249
+
250
+
They are owned by the database owner, with usage/read/write permissions for the RDB$PROFILER role, granted by default to `PUBLIC`.
247
251
248
252
When a session is deleted, the related data in other profiler snapshot tables are automatically deleted too through foreign keys with `DELETE CASCADE` option.
249
253
@@ -265,6 +269,7 @@ Below is the list of tables that stores profile data.
265
269
-`STATEMENT_ID` type `BIGINT` - Statement ID
266
270
-`PARENT_STATEMENT_ID` type `BIGINT` - Parent statement ID - related to sub routines
267
271
-`STATEMENT_TYPE` type `VARCHAR(20) CHARACTER SET UTF8` - BLOCK, FUNCTION, PROCEDURE or TRIGGER
272
+
-`SCHEMA_NAME` type `CHAR(63) CHARACTER SET UTF8` - Schema name of FUNCTION, PROCEDURE or TRIGGER
268
273
-`PACKAGE_NAME` type `CHAR(63) CHARACTER SET UTF8` - Package of FUNCTION or PROCEDURE
269
274
-`ROUTINE_NAME` type `CHAR(63) CHARACTER SET UTF8` - Routine name of FUNCTION, PROCEDURE or TRIGGER
270
275
-`SQL_TEXT` type `BLOB subtype TEXT CHARACTER SET UTF8` - SQL text for BLOCK
@@ -346,6 +351,7 @@ After hotspots are found, one can drill down in the data at the request level th
0 commit comments