|
134 | 134 | #include"replication/logical.h" |
135 | 135 | #include"replication/reorderbuffer.h" |
136 | 136 | #include"replication/snapbuild.h" |
| 137 | +#include"replication/snapbuild_internal.h" |
137 | 138 | #include"storage/fd.h" |
138 | 139 | #include"storage/lmgr.h" |
139 | 140 | #include"storage/proc.h" |
|
143 | 144 | #include"utils/memutils.h" |
144 | 145 | #include"utils/snapmgr.h" |
145 | 146 | #include"utils/snapshot.h" |
146 | | - |
147 | | -/* |
148 | | - * This struct contains the current state of the snapshot building |
149 | | - * machinery. Besides a forward declaration in the header, it is not exposed |
150 | | - * to the public, so we can easily change its contents. |
151 | | - */ |
152 | | -structSnapBuild |
153 | | -{ |
154 | | -/* how far are we along building our first full snapshot */ |
155 | | -SnapBuildStatestate; |
156 | | - |
157 | | -/* private memory context used to allocate memory for this module. */ |
158 | | -MemoryContextcontext; |
159 | | - |
160 | | -/* all transactions < than this have committed/aborted */ |
161 | | -TransactionIdxmin; |
162 | | - |
163 | | -/* all transactions >= than this are uncommitted */ |
164 | | -TransactionIdxmax; |
165 | | - |
166 | | -/* |
167 | | - * Don't replay commits from an LSN < this LSN. This can be set externally |
168 | | - * but it will also be advanced (never retreat) from within snapbuild.c. |
169 | | - */ |
170 | | -XLogRecPtrstart_decoding_at; |
171 | | - |
172 | | -/* |
173 | | - * LSN at which two-phase decoding was enabled or LSN at which we found a |
174 | | - * consistent point at the time of slot creation. |
175 | | - * |
176 | | - * The prepared transactions, that were skipped because previously |
177 | | - * two-phase was not enabled or are not covered by initial snapshot, need |
178 | | - * to be sent later along with commit prepared and they must be before |
179 | | - * this point. |
180 | | - */ |
181 | | -XLogRecPtrtwo_phase_at; |
182 | | - |
183 | | -/* |
184 | | - * Don't start decoding WAL until the "xl_running_xacts" information |
185 | | - * indicates there are no running xids with an xid smaller than this. |
186 | | - */ |
187 | | -TransactionIdinitial_xmin_horizon; |
188 | | - |
189 | | -/* Indicates if we are building full snapshot or just catalog one. */ |
190 | | -boolbuilding_full_snapshot; |
191 | | - |
192 | | -/* |
193 | | - * Indicates if we are using the snapshot builder for the creation of a |
194 | | - * logical replication slot. If it's true, the start point for decoding |
195 | | - * changes is not determined yet. So we skip snapshot restores to properly |
196 | | - * find the start point. See SnapBuildFindSnapshot() for details. |
197 | | - */ |
198 | | -boolin_slot_creation; |
199 | | - |
200 | | -/* |
201 | | - * Snapshot that's valid to see the catalog state seen at this moment. |
202 | | - */ |
203 | | -Snapshotsnapshot; |
204 | | - |
205 | | -/* |
206 | | - * LSN of the last location we are sure a snapshot has been serialized to. |
207 | | - */ |
208 | | -XLogRecPtrlast_serialized_snapshot; |
209 | | - |
210 | | -/* |
211 | | - * The reorderbuffer we need to update with usable snapshots et al. |
212 | | - */ |
213 | | -ReorderBuffer*reorder; |
214 | | - |
215 | | -/* |
216 | | - * TransactionId at which the next phase of initial snapshot building will |
217 | | - * happen. InvalidTransactionId if not known (i.e. SNAPBUILD_START), or |
218 | | - * when no next phase necessary (SNAPBUILD_CONSISTENT). |
219 | | - */ |
220 | | -TransactionIdnext_phase_at; |
221 | | - |
222 | | -/* |
223 | | - * Array of transactions which could have catalog changes that committed |
224 | | - * between xmin and xmax. |
225 | | - */ |
226 | | -struct |
227 | | -{ |
228 | | -/* number of committed transactions */ |
229 | | -size_txcnt; |
230 | | - |
231 | | -/* available space for committed transactions */ |
232 | | -size_txcnt_space; |
233 | | - |
234 | | -/* |
235 | | - * Until we reach a CONSISTENT state, we record commits of all |
236 | | - * transactions, not just the catalog changing ones. Record when that |
237 | | - * changes so we know we cannot export a snapshot safely anymore. |
238 | | - */ |
239 | | -boolincludes_all_transactions; |
240 | | - |
241 | | -/* |
242 | | - * Array of committed transactions that have modified the catalog. |
243 | | - * |
244 | | - * As this array is frequently modified we do *not* keep it in |
245 | | - * xidComparator order. Instead we sort the array when building & |
246 | | - * distributing a snapshot. |
247 | | - * |
248 | | - * TODO: It's unclear whether that reasoning has much merit. Every |
249 | | - * time we add something here after becoming consistent will also |
250 | | - * require distributing a snapshot. Storing them sorted would |
251 | | - * potentially also make it easier to purge (but more complicated wrt |
252 | | - * wraparound?). Should be improved if sorting while building the |
253 | | - * snapshot shows up in profiles. |
254 | | - */ |
255 | | -TransactionId*xip; |
256 | | -}committed; |
257 | | - |
258 | | -/* |
259 | | - * Array of transactions and subtransactions that had modified catalogs |
260 | | - * and were running when the snapshot was serialized. |
261 | | - * |
262 | | - * We normally rely on some WAL record types such as HEAP2_NEW_CID to know |
263 | | - * if the transaction has changed the catalog. But it could happen that |
264 | | - * the logical decoding decodes only the commit record of the transaction |
265 | | - * after restoring the previously serialized snapshot in which case we |
266 | | - * will miss adding the xid to the snapshot and end up looking at the |
267 | | - * catalogs with the wrong snapshot. |
268 | | - * |
269 | | - * Now to avoid the above problem, we serialize the transactions that had |
270 | | - * modified the catalogs and are still running at the time of snapshot |
271 | | - * serialization. We fill this array while restoring the snapshot and then |
272 | | - * refer it while decoding commit to ensure if the xact has modified the |
273 | | - * catalog. We discard this array when all the xids in the list become old |
274 | | - * enough to matter. See SnapBuildPurgeOlderTxn for details. |
275 | | - */ |
276 | | -struct |
277 | | -{ |
278 | | -/* number of transactions */ |
279 | | -size_txcnt; |
280 | | - |
281 | | -/* This array must be sorted in xidComparator order */ |
282 | | -TransactionId*xip; |
283 | | -}catchange; |
284 | | -}; |
285 | | - |
286 | 147 | /* |
287 | 148 | * Starting a transaction -- which we need to do while exporting a snapshot -- |
288 | 149 | * removes knowledge about the previously used resowner, so we save it here. |
@@ -1557,40 +1418,6 @@ SnapBuildWaitSnapshot(xl_running_xacts *running, TransactionId cutoff) |
1557 | 1418 | } |
1558 | 1419 | } |
1559 | 1420 |
|
1560 | | -/* ----------------------------------- |
1561 | | - * Snapshot serialization support |
1562 | | - * ----------------------------------- |
1563 | | - */ |
1564 | | - |
1565 | | -/* |
1566 | | - * We store current state of struct SnapBuild on disk in the following manner: |
1567 | | - * |
1568 | | - * struct SnapBuildOnDisk; |
1569 | | - * TransactionId * committed.xcnt; (*not xcnt_space*) |
1570 | | - * TransactionId * catchange.xcnt; |
1571 | | - * |
1572 | | - */ |
1573 | | -typedefstructSnapBuildOnDisk |
1574 | | -{ |
1575 | | -/* first part of this struct needs to be version independent */ |
1576 | | - |
1577 | | -/* data not covered by checksum */ |
1578 | | -uint32magic; |
1579 | | -pg_crc32cchecksum; |
1580 | | - |
1581 | | -/* data covered by checksum */ |
1582 | | - |
1583 | | -/* version, in case we want to support pg_upgrade */ |
1584 | | -uint32version; |
1585 | | -/* how large is the on disk data, excluding the constant sized part */ |
1586 | | -uint32length; |
1587 | | - |
1588 | | -/* version dependent part */ |
1589 | | -SnapBuildbuilder; |
1590 | | - |
1591 | | -/* variable amount of TransactionIds follows */ |
1592 | | -}SnapBuildOnDisk; |
1593 | | - |
1594 | 1421 | #defineSnapBuildOnDiskConstantSize \ |
1595 | 1422 | offsetof(SnapBuildOnDisk, builder) |
1596 | 1423 | #defineSnapBuildOnDiskNotChecksummedSize \ |
|