1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
|
#+OPTIONS: ^:{}
2.2.11
- Add support for PG 15
- Remove standard_conforming_strings autoconf check
- Fix typo in admin guide
2.2.10
- Remove unsupported warning on PG13
2.2.9
- Compile with -fno-common by default. Fix
compile errors caused by defining variables in headers
- Adjust slonik_build_env.pl so it works with PG11+
- Remove unsupported warning on PG12
2.2.8
- Fix pg 8.4 messagaging in slonik
- Fix documnted default config values for slon
- Add PG12 support
- Makefile changes to enable vpath builds
- The win32 makefiles no longer define HAVE_PGPORT. win32
users of slonik should set the SLONY_SHARE_DIR environment variable
2.2.7
- Fix warning with flex 2.6+
- Fix compile errors with PG11
- Fix bug in with regex in 'set add sequence' when
specifying the sequence as a regular expression.
It was not being escaped properly
- Add support to Slonik to specify the share direcotry
using the environment variable SLONY_SHARE_DIR
- Add slon config setting remote_listen_serializable_transactions
to use read committed instead of read-only-serializable deferable
transactions(default true)
- Add slon config setting enable_version_check to disable
the slony version check that ensures all nodes run the
same slony version (default true, version check enabled)
*2.2.6
- slonik_build_env can now accept multiple -schema options on the command line
- Support for PG10. This involved changes to PG version detection
- Disallow createEvent and data changes in the same transaction.
This also fixes some issues when the logApply trigger invokes the
data change trigger by inserting into a table with a trigger that
in turns inserts into another replicated table.
- Fix some failover issues when doing a multi-node failover
with a cascaded node.
- Bug 341 - suppress log trigger/deny when running in 'local' mode
- Fix issue when receiving DDL from non origin nodes
* 2.2.5
- PG 9.5 makefile fix for win32
- PG 9.6 header file fix
- Bug 359 :: Additional parameter to GetConfigOptionByName() in HEAD
* 2.2.4
- Bug 352 :: Handle changes from PG HEAD ("9.5")
- Bug 349 :: Issue with quoting of cluster name - only hit when processing DDL
- Bug 350 :: Make cleanup_interval config parameter work as expected
- Include alloca.h in slonik(fix for solaris)
- Bug :: 345 Fix bug when dropping multiple nodes at once
- Bug 354 :: Fix race condition in FAILOVER
- Bug 356 :: Perform TRUNCATE ONLY on replicas (when replicating a truncate)
* 2.2.3
- Bug 338 - Have ddlScript return a bigint instead of a integer
- fixing Deadlock with application during minor version slony upgrade
- Bug 342 FAILOVER fixes for some multi-node configurations
- Remove HAVE_POSIX_SIGNALS from config.h
- Bug 344 Do not abort reading slon config values when an unrecognized one is encountered
* 2.2.2
- Include server include paths on --with-pgport builds for slonik
- Bug 327 - Fix invalid free() in the logApply trigger
* 2.2.1
- Bug 315 :: Fixes to compile time include directories
- Bug 318 :: Fix to FAILOVER logic to avoid slon restart loop
- Bug 319 :: Fix dereferencing of NULL pointer on a lost connection
- Bug 320 :: Fix UPDATE FUNCTIONS so it adds sl_node.no_failed on a upgrade
from slony version before 2.2.0
- Bug 321 :: Fixing frequent slon connect and disconnects to providers
- Bug 322 :: Allow CLONE PREPARE processing to deal with an earlier STORE PATH
- No Bug :: remove warning unsupported warning for PG 9.3
* Slony-I 2.2 Release Notes
** Significant Changes
- Shared Libraries are now named so as to allow having multiple
versions of Slony installed simultaneously on a database cluster
- Bug 287 :: Fix UPDATE FUNCTIONS so it works when the old shared
library is no longer around
- Bug 290 :: Make the symbols in the shared library unique
- The slony1_funcs.so and .sql files that get installed are also
versioned, which allows multiple versions of slony to be
installed in the same postgresql lib directory.
- Allow linking with pgport on 9.3+ by including pgcommon
- Let DDL for EXECUTE SCRIPT to be specified inline - bug 151
- Numerous revisions to documentation
- altperl tool improvements including ::
- better support for running multiple slons on the same server
- let start_slon invoke slon with a config file
- fix node_is_subscribing
- $LOGDIR directory behaviours
- use PGPASSWORDFILE when querying state
- Add correct 'ps' arguments to the altperl tools for Darwin.
- SYNC GROUP sizes are now dynamically grow from 1 to a maximum
size set in the config file. The old logic based on time it took
to complete the last SYNC has been removed. - bug #235
- Added a RESUBSCRIBE NODE command to reshape clusters. This must
be used instead of SUBSCRIBE SET to reshape subscriptions when an
origin has more than one set.
- Bug #178 :: The FAILOVER process has been reworked to be more
reliable. Some nodes can no longer be used as
failover targets.
- SET ID is no longer an option to EXECUTE SCRIPT.
- Major "protocol" change; rather than constructing cursors to
query logged updates, version 2.2 now uses the COPY protocol to
stream data into log tables on subscribers. This is discussed in
greater detail in the following section.
** Major 2.2 change: COPY protocol
In versions before 2.2, Slony-I log triggers would capture logged
data into tables ~sl_log_1~ and ~sl_log_2~ in the form of
nearly-"cooked" queries, omitting just the INSERT/UPDATE/DELETE
statement, and the slon that processes the data would transform
the data into INSERT/UPDATE/DELETE statements to be individually
parsed and executed by the subscriber node.
In version 2.2, this is changed fairly massively.
- Log triggers
- Log triggers used to capture the text of the SQL statement to
perform the INSERT/UPDATE/DELETE, missing only the literal
INSERT (or UPDATE or DELETE) and the name of the table.
- As of version 2.2, the log triggers now capture an array of
text values indicating the criteria and the data to be loaded.
- Query against data provider
- The old query process used to involve declaring a cursor
called LOG, which would pull in all the tuples where the data
attribute was not "too terribly large." Tuples would be
pulled in a few hundred at a time, the unusually large ones
being handled via a special side process in order to avoid
excessive memory consumption.
- In version 2.2, the query instead runs a COPY to standard
output, leaving a pipe open to capture that output for
transmission to the subscriber.
- Loading data into subscriber
- The old query process involved explicitly running each INSERT,
UPDATE, DELETE, and TRUNCATE against the subscriber. This
required that the backend parse, plan, and process each query
individually.
- In version 2.2, the stream of data captured from the COPY
request is, in turn, passed to a COPY statement that loads the
data into sl_log_1 or sl_log_2 on the subscriber node.
A trigger on sl_log_1 and sl_log_2 reads the incoming data
and, inside the backend, transforms the array into
INSERT/UPDATE/DELETE statements.
This is still an oversimplification; there is a statement
cache so that if there is request to ~INSERT INTO some_table
(c1,c2) values ('b','c');~ followed (perhaps, but not
necessarily immediately) by ~INSERT INTO some_table (c1,c2)
values ('d','e');~, then the second request re-uses the plan
from the first query, and may instead execute ~EXECUTE
some_table_insert('d','e');~
- DDL handling
- The old behaviour was that DDL was treated as a special Slony
event, and it never was clear whether that should be executed
before or after other replication activity that might have
taken place during that Slony event. This was fine in Slony
1.2 and earlier, when the processing of DDL forcibly required
that Slony take out locks on the origin on ALL replicated
tables; those locks would prevent there from being any other
activity going on during the processing of DDL. But when much
of that locking disappeared, in version 2.0, it became
possible for there to be replication activity on tables not
being modified by DDL, and timing anomalies could occur.
- In version 2.2, a third log table, sl_log_script, is added to
capture script queries which would notably include DDL. This
table uses the same sequence value that controls order of
application for replicated data, so DDL will be applied at
exactly the appropriate point in the transaction stream on
subscribers.
- Note that this rectifies bug #137, *execute script does not
get applied in the correct order*
- Sequence handling changes somewhat (see Bug 304).
Previously, when DDL was processed as "an event," this would
naturally mean that sequence values would have values based on
the previous SYNC, and, at the end, capture values at the end
of the DDL SYNC, and the "DDL Sync" could make use of those
values.
Now, with DDL being processed along with ordinary replicated
DML within a SYNC, sequence usage by DML needs to be captured
and mixed into the updates. Now, each time a DDL statement is
applied, sequences need to be updated, which can now take
place in the middle of a SYNC.
- Expected effects
- Lower processing overhead in slon process :: By using COPY,
all that need be done is for slon to "stream" data from the
provider to the subscriber. There is no longer a need to
generate or process individual queries.
- Lower memory consumption in slon process :: Again, from using
COPY, memory consumption is based solely on how much data
is buffered in memory as part of the streaming. A query
that is larger than the buffer is simply handled by letting
data stream through the buffer; the large query does not
need to be instantiated in memory, as was the case in older
versions of Slony.
- Less query processing work on subscriber database :: The use
of prepared statements should dramatically reduce the
amount of computational effort required for query parsing
and planning.
- Correct ordering of DDL within processing :: Bug #137
described a problem persisting from version 2.0 to 2.1
where DDL could be performed in the wrong order with
respect to logged data changes. The shift of "script" data
from ~sl_event~ to ~sl_log_script~ resolves this issue.
** Bugs fixed in the course of the release
These are expected to represent bugs that were previously present,
not a consequence of problems introduced and subsequently fixed in
the 2.2 branch.
- No bug :: Make log_truncate() SECURITY DEFINER
- Bug 250 :: Log shipper does not report application name - add in setting of GUC
- Bug 252 :: cloneNodePrepare() store a valid conninfo in sl_path
- Bug 273 :: Slon can try to pull data from a behind provider. Fix is
to not force the event provider to be part of the
providers unless we don't find any provider at all
otherwise.
- Bug 286 :: Support to compile against PG 9.3
- Bug 297 :: Make test_slony_state-dbi.pl work with PG 9.2
- Bug 299 :: Fix a bug in MOVE SET where slon might pull data from the old origin using
SYNC values for the new origin
|
