|
639 | 639 | </para>
|
640 | 640 |
|
641 | 641 | <para>
|
642 |
| - As a rule of thumb, <structfield>queryid</structfield> values can be assumed to be |
643 |
| - stable and comparable only so long as the underlying server version and |
644 |
| - catalog metadata details stay exactly the same. Two servers |
645 |
| - participating in replication based on physical WAL replay can be expected |
646 |
| - to have identical <structfield>queryid</structfield> values for the same query. |
647 |
| - However, logical replication schemes do not promise to keep replicas |
648 |
| - identical in all relevant details, so <structfield>queryid</structfield> will |
649 |
| - not be a useful identifier for accumulating costs across a set of logical |
650 |
| - replicas. If in doubt, direct testing is recommended. |
| 642 | + Two servers participating in replication based on physical WAL replay can |
| 643 | + be expected to have identical <structfield>queryid</structfield> values for |
| 644 | + the same query. However, logical replication schemes do not promise to |
| 645 | + keep replicas identical in all relevant details, so |
| 646 | + <structfield>queryid</structfield> will not be a useful identifier for |
| 647 | + accumulating costs across a set of logical replicas. |
| 648 | + If in doubt, direct testing is recommended. |
| 649 | + </para> |
| 650 | + |
| 651 | + <para> |
| 652 | + Generally, it can be assumed that <structfield>queryid</structfield> values |
| 653 | + are stable between minor version releases of <productname>PostgreSQL</productname>, |
| 654 | + providing that instances are running on the same machine architecture and |
| 655 | + the catalog metadata details match. Compatibility will only be broken |
| 656 | + between minor versions as a last resort. |
651 | 657 | </para>
|
652 | 658 |
|
653 | 659 | <para>
|
|
0 commit comments