[PATCH] Rename pg_switch_xlog to pg_switch_wal

On 12/13/16 12:47 PM, Vladimir Rusinov wrote:

Based on discussion in
/messages/by-id/CAE1wr-w=LE1cK5uG_rmAh-VBxc4_Bnw-gAE3qSqL-=tWwvLvjQ@mail.gmail.com.

Tested via regression tests.
To be applied in master only and to be included in 10.0.

I don't think the idea was to rename just one "xlog" function to "wal".

Personally, I think this is not important, but if you want to do it, I'd
follow the suggestion in the thread to rename all functions and leave
the old names as aliases or wrappers of some kind.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Dec 14, 2016 at 4:07 PM, Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

On 12/13/16 12:47 PM, Vladimir Rusinov wrote:

Based on discussion in
/messages/by-id/CAE1wr-w%25

3DLE1cK5uG_rmAh-VBxc4_Bnw-gAE3qSqL-%3DtWwvLvjQ%40mail.gmail.com.

Tested via regression tests.
To be applied in master only and to be included in 10.0.

I don't think the idea was to rename just one "xlog" function to "wal".

Others will follow later in separate patches. Or is it preferred to have
one huge patch submitted?

Personally, I think this is not important, but if you want to do it, I'd

follow the suggestion in the thread to rename all functions and leave
the old names as aliases or wrappers of some kind.

I think I agree with Michael Paquier: "Better to do breakages in a single
release rather than spreading them across releases.".
There's going to be a lot of broken scripts following pg_xlog rename, so I
think it makes sense to just drop functions as well. We don't maintain
pg_xlog -> pg_wal symlink, do we?

--
Vladimir Rusinov
Storage SRE, Google Ireland

Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047

On Thu, Dec 15, 2016 at 1:20 AM, Vladimir Rusinov <vrusinov@google.com> wrote:

On Wed, Dec 14, 2016 at 4:07 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
Others will follow later in separate patches. Or is it preferred to have one
huge patch submitted?

Please yes. One change makes little sense.

Personally, I think this is not important, but if you want to do it, I'd
follow the suggestion in the thread to rename all functions and leave
the old names as aliases or wrappers of some kind.

I think I agree with Michael Paquier: "Better to do breakages in a single
release rather than spreading them across releases.".
There's going to be a lot of broken scripts following pg_xlog rename, so I
think it makes sense to just drop functions as well.

For consistency that makes sense in my view. But I won't be too noisy
as well if people think that we should keep aliases for compatibility.

We don't maintain pg_xlog -> pg_wal symlink, do we?

This part would be a mess for base backups, that's why we didn't do
it. Symlinks are equivalent to empty directories in the pg_basebackup
world. So by having one you would very likely break your backup *and*
restore tools silently.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Dec 14, 2016 at 11:51 PM, Michael Paquier <michael.paquier@gmail.com

wrote:

On Wed, Dec 14, 2016 at 4:07 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
Others will follow later in separate patches. Or is it preferred to have

one

huge patch submitted?

Please yes. One change makes little sense.

Ack. I was not sure what patch size is preferred here. Will continue with a
patch in original thread later.

Thanks for feedback!

--
Vladimir Rusinov
Storage SRE, Google Ireland

Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047

On Thu, Dec 15, 2016 at 8:51 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:

On Thu, Dec 15, 2016 at 1:20 AM, Vladimir Rusinov <vrusinov@google.com> wrote:

Personally, I think this is not important, but if you want to do it, I'd
follow the suggestion in the thread to rename all functions and leave
the old names as aliases or wrappers of some kind.

I think I agree with Michael Paquier: "Better to do breakages in a single
release rather than spreading them across releases.".
There's going to be a lot of broken scripts following pg_xlog rename, so I
think it makes sense to just drop functions as well.

For consistency that makes sense in my view. But I won't be too noisy
as well if people think that we should keep aliases for compatibility.

Actually, I am changing my mind on this bit, following Peter's
opinion. Maintaining aliases of the past functions is a no-brainer,
and it has no cost in terms of maintenance. That will save much pain
to many monitoring scripts as well.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

1) I agree with Michael that we should make this change backward compatible. It would help PostgreSQL image if we did not break everyone's code. It costs businesses money to rewrite code (e.g. middle tier software, backup tools, etc), test and redeploy to their customers.

2) We decided to rename the pg_xlog directory because people were deleting it when disks were getting full thinking it was just unimportant logging data; I get that. I'm a little unclear why we need to change the functions - it would be less painful to our users and less risky if we just left them as is. Could someone please elaborate why this change is necessary? I'm just trying to understand that.

Thanks,
-Cynthia
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Cynthia,

* Cynthia Shang (cynthia.shang@crunchydata.com) wrote:

1) I agree with Michael that we should make this change backward compatible. It would help PostgreSQL image if we did not break everyone's code. It costs businesses money to rewrite code (e.g. middle tier software, backup tools, etc), test and redeploy to their customers.

While I agree that we don't want to break client code or to make
backwards incompatible changes without good cause, in this case, it's
definitely a good cause and it makes sense to have things be consistent
and that includes changing these functions.

We make backwards-incompatible changes with each major release, which is
part of why we support older versions of PG for as long as we do- to
give PG users time to make any necessary changes for the new version of
PG. One could argue that we shouldn't ever make a backwards
incompatible change because it will break an existing user's code and
cost users time and effort to rewrite that code, but the flip side of
that is that the extra code and complexity results in its own
maintenance burdens for the code and the project moving forward.

Generally speaking, we've also found that backwards compatibility
'features' end up having a much longer life than they should.
Ultimately, the best way forward tends to be either make the backwards
incompatible change or don't make the change at all. We've already
agreed on this particular change, and with good reason, so the way
forward is to make the rest of the changes, not to go half-way or to try
and provide some backwards compatibility complexity.

2) We decided to rename the pg_xlog directory because people were deleting it when disks were getting full thinking it was just unimportant logging data; I get that. I'm a little unclear why we need to change the functions - it would be less painful to our users and less risky if we just left them as is. Could someone please elaborate why this change is necessary? I'm just trying to understand that.

It would be inconsistent to change the directory name without also
changing the documentation, functions, and other user-facing pieces.

Thanks!

Stephen

I have never heard of coding standards where naming conventions required a function/variable name match a directory or file name. It seems that would be restrictive.

I'm not trying to pick a fight, I just think the pros should outweigh the cons when choosing a path forward. In this case I see lots of cons and one partial pro; partial because renaming only user facing functions and documentation will create inconsistency within the Postgres code for all of the following. It sounds as if your minds are already made up, which saddens me but I will say nothing further on the matter.

xlog <https://doxygen.postgresql.org/structlogstreamer__param.html#aa537f3fc7164183c962c58ded88e89f0&gt; - logstreamer_param
xlog.c <https://doxygen.postgresql.org/xlog_8c.html&gt;
xlog.h <https://doxygen.postgresql.org/xlog_8h.html&gt;
XLOG_BACKUP_END <https://doxygen.postgresql.org/pg__control_8h.html#ad9d92339bbf37810f7dfae4b3dbdf2c3&gt; - pg_control.h
XLOG_BACKUP_LABEL <https://doxygen.postgresql.org/pg__standby_8c.html#a9e28a4fd60add05fb281b523dde816d9&gt; - pg_standby.c
xlog_blcksz <https://doxygen.postgresql.org/structControlFileData.html#ae41f5131a8b8add3a9a8896027dcd7eb&gt; - ControlFileData
XLOG_BLCKSZ_K <https://doxygen.postgresql.org/pg__test__fsync_8c.html#afc05fa8d4ff04e3820d70e13e7a8c9f3&gt; - pg_test_fsync.c
XLOG_BRIN_CREATE_INDEX <https://doxygen.postgresql.org/brin__xlog_8h.html#ab56748e29ec0e518dbe6aec2ad9174d2&gt; - brin_xlog.h
XLOG_BRIN_INIT_PAGE <https://doxygen.postgresql.org/brin__xlog_8h.html#ad4da725dab7941c79b95f306f93f0733&gt; - brin_xlog.h
XLOG_BRIN_INSERT <https://doxygen.postgresql.org/brin__xlog_8h.html#af325e689ce6b134004d634e5f4f5fc22&gt; - brin_xlog.h
XLOG_BRIN_OPMASK <https://doxygen.postgresql.org/brin__xlog_8h.html#abda79bb9dc455d307cbe04550b4a75a0&gt; - brin_xlog.h
XLOG_BRIN_REVMAP_EXTEND <https://doxygen.postgresql.org/brin__xlog_8h.html#a3ee32c12f868b6645d522a3cd8697a29&gt; - brin_xlog.h
XLOG_BRIN_REVMAP_VACUUM <https://doxygen.postgresql.org/brin__xlog_8h.html#aebb67fc99f73c1fd6a3408683cd4165a&gt; - brin_xlog.h
XLOG_BRIN_SAMEPAGE_UPDATE <https://doxygen.postgresql.org/brin__xlog_8h.html#a6e8d0c699dbecfa2d1be99b9c68ed529&gt; - brin_xlog.h
XLOG_BRIN_UPDATE <https://doxygen.postgresql.org/brin__xlog_8h.html#adacb7563b0c0d602cdcb22a853834009&gt; - brin_xlog.h
XLOG_BTREE_DELETE <https://doxygen.postgresql.org/nbtree_8h.html#af36ce520ea71dc51d72ee11c637bad71&gt; - nbtree.h
XLOG_BTREE_INSERT_LEAF <https://doxygen.postgresql.org/nbtree_8h.html#a855451db931e66a5536c04967332c353&gt; - nbtree.h
XLOG_BTREE_INSERT_META <https://doxygen.postgresql.org/nbtree_8h.html#ac7c6b3a582fd3d4cd57744f70829d017&gt; - nbtree.h
XLOG_BTREE_INSERT_UPPER <https://doxygen.postgresql.org/nbtree_8h.html#a902a50eeae554560fdfc83947ede0798&gt; - nbtree.h
XLOG_BTREE_MARK_PAGE_HALFDEAD <https://doxygen.postgresql.org/nbtree_8h.html#acb2d5fad8d393b45d5baed66eb963cac&gt; - nbtree.h
XLOG_BTREE_NEWROOT <https://doxygen.postgresql.org/nbtree_8h.html#aeb46a6c11b567f31166bc637871b8940&gt; - nbtree.h
XLOG_BTREE_REUSE_PAGE <https://doxygen.postgresql.org/nbtree_8h.html#adb8efa2ad4e95da9e9a30fa3ba86d66a&gt; - nbtree.h
XLOG_BTREE_SPLIT_L <https://doxygen.postgresql.org/nbtree_8h.html#ae01749da77b228c8bd873557877dbdbb&gt; - nbtree.h
XLOG_BTREE_SPLIT_L_ROOT <https://doxygen.postgresql.org/nbtree_8h.html#a3fc243b315c69170c44d58cfbf9cf1a9&gt; - nbtree.h
XLOG_BTREE_SPLIT_R <https://doxygen.postgresql.org/nbtree_8h.html#a619f011a3d4e02994f10a5c5eca1bbce&gt; - nbtree.h
XLOG_BTREE_SPLIT_R_ROOT <https://doxygen.postgresql.org/nbtree_8h.html#a509d120723af55b9004d2154a9788776&gt; - nbtree.h
XLOG_BTREE_UNLINK_PAGE <https://doxygen.postgresql.org/nbtree_8h.html#aa0f8ea18c61c3c2d1f492e700f63d128&gt; - nbtree.h
XLOG_BTREE_UNLINK_PAGE_META <https://doxygen.postgresql.org/nbtree_8h.html#aa1e90ef7a8ae497f6ba95d9b6544dfaa&gt; - nbtree.h
XLOG_BTREE_VACUUM <https://doxygen.postgresql.org/nbtree_8h.html#a470f820d137d81d227e7d6d9d53835a3&gt; - nbtree.h
XLOG_CHECKPOINT_ONLINE <https://doxygen.postgresql.org/pg__control_8h.html#afc093bf9e7639cfeda0a45ef48c9c77e&gt; - pg_control.h
XLOG_CHECKPOINT_SHUTDOWN <https://doxygen.postgresql.org/pg__control_8h.html#ab5870b9e3586602b5c0cfaad533c9c3c&gt; - pg_control.h
XLOG_CONTROL_FILE <https://doxygen.postgresql.org/xlog__internal_8h.html#a243af5b9b94bfc6356d44053a6f08e13&gt;xlog_internal.h
XLOG_DATA <https://doxygen.postgresql.org/pg__standby_8c.html#a37d04756edf3c23236e1182e9b41f7b8&gt;pg_standby.c
XLOG_DBASE_CREATE <https://doxygen.postgresql.org/dbcommands__xlog_8h.html#ab2eb2d181264280d88da0de6023a5b03&gt; - dbcommands_xlog.h
XLOG_DBASE_DROP <https://doxygen.postgresql.org/dbcommands__xlog_8h.html#a82159f86420a7d740047120d691e078c&gt; - dbcommands_xlog.h
xlog_desc <javascript:searchResults.Toggle(%22SR_xlog_5fdesc%22)>
xlog_dir <javascript:searchResults.Toggle(%22SR_xlog_5fdir%22)>
XLOG_END_OF_RECOVERY <https://doxygen.postgresql.org/pg__control_8h.html#afe9e6ee9f0b19be02e7d802fd7b0dd5d&gt; - pg_control.h
xlog_fn.h <https://doxygen.postgresql.org/xlog__fn_8h.html&gt;
XLOG_FNAME_LEN <https://doxygen.postgresql.org/xlog__internal_8h.html#a806888338de344e3fbb7c91a788149da&gt; - xlog_internal.h
XLOG_FPI <https://doxygen.postgresql.org/pg__control_8h.html#a77c5fe73e060f7759deb421a0b2c4af6&gt; - pg_control.h
XLOG_FPI_FOR_HINT <https://doxygen.postgresql.org/pg__control_8h.html#a7cc48ed8535d7c8321cd096d62bc84da&gt; - pg_control.h
XLOG_FPW_CHANGE <https://doxygen.postgresql.org/pg__control_8h.html#a21c819d8dad919204caf8198d6f29e8a&gt; - pg_control.h
XLOG_FROM_ANY <https://doxygen.postgresql.org/xlog_8c.html#aa4ae6b53287149eeb167868e4a55d714aea9ce17d7eded4324cc8f5416a0163da&gt; - xlog.c
XLOG_FROM_ARCHIVE <https://doxygen.postgresql.org/xlog_8c.html#aa4ae6b53287149eeb167868e4a55d714adffd65e4ec3f1091765ac4438e6beacd&gt; - xlog.c
XLOG_FROM_PG_WAL <https://doxygen.postgresql.org/xlog_8c.html#aa4ae6b53287149eeb167868e4a55d714a6953cfa8a50e9a0cca70e93713b673f2&gt; - xlog.c
XLOG_FROM_STREAM <https://doxygen.postgresql.org/xlog_8c.html#aa4ae6b53287149eeb167868e4a55d714abb692a2dd46cbbf9d2b4f346a8ef5ff9&gt; - xlog.c
XLOG_GIN_CREATE_INDEX <https://doxygen.postgresql.org/gin__private_8h.html#aaecaef66228a8f431493e643bcbc3cf8&gt; - gin_private.h
XLOG_GIN_CREATE_PTREE <https://doxygen.postgresql.org/gin__private_8h.html#aa0136e6761a3c5a3c5d33e4c135be255&gt; - gin_private.h
XLOG_GIN_DELETE_LISTPAGE <https://doxygen.postgresql.org/gin__private_8h.html#af5de469705afaa58f3991be80091c1e1&gt; - gin_private.h
XLOG_GIN_DELETE_PAGE <https://doxygen.postgresql.org/gin__private_8h.html#aaa85fe6ca88d3b567ebf8f58454b2602&gt; - gin_private.h
XLOG_GIN_INSERT <https://doxygen.postgresql.org/gin__private_8h.html#a847d779049f75dff8be5b1c99400505f&gt; - gin_private.h
XLOG_GIN_INSERT_LISTPAGE <https://doxygen.postgresql.org/gin__private_8h.html#ab697c4aab9b2da31177a87c5b46cca05&gt; - gin_private.h
XLOG_GIN_SPLIT <https://doxygen.postgresql.org/gin__private_8h.html#ae601d320a2ed9b4dd95bab6967e7dd24&gt; - gin_private.h
XLOG_GIN_UPDATE_META_PAGE <https://doxygen.postgresql.org/gin__private_8h.html#a19e96aa1f1af8c8917a7aea7f4238f0b&gt; - gin_private.h
XLOG_GIN_VACUUM_DATA_LEAF_PAGE <https://doxygen.postgresql.org/gin__private_8h.html#ac1638e8f4fc822004e1cb66fd37ba48f&gt; - gin_private.h
XLOG_GIN_VACUUM_PAGE <https://doxygen.postgresql.org/gin__private_8h.html#aa15459bf08d3806311e789b4e6de102c&gt; - gin_private.h
XLOG_GIST_CREATE_INDEX <https://doxygen.postgresql.org/gist__private_8h.html#a5a8e2e98e31d45df90d39057e704ef73&gt; - gist_private.h
XLOG_GIST_PAGE_SPLIT <https://doxygen.postgresql.org/gist__private_8h.html#ad8fe365920af63ec3592f5045d1d5f7c&gt; - gist_private.h
XLOG_GIST_PAGE_UPDATE <https://doxygen.postgresql.org/gist__private_8h.html#ae1dfd9314093a34bd1559be465fa7a46&gt; - gist_private.h
XLOG_HEAP2_CLEAN <https://doxygen.postgresql.org/heapam__xlog_8h.html#afd43c607f260d10d107b82ec56b46457&gt; - heapam_xlog.h
XLOG_HEAP2_CLEANUP_INFO <https://doxygen.postgresql.org/heapam__xlog_8h.html#a287947ce9e8640c834c965da8e68ec31&gt; - heapam_xlog.h
XLOG_HEAP2_FREEZE_PAGE <https://doxygen.postgresql.org/heapam__xlog_8h.html#a99228d35e6c15389dc6c0c932f8f2084&gt; - heapam_xlog.h
XLOG_HEAP2_LOCK_UPDATED <https://doxygen.postgresql.org/heapam__xlog_8h.html#a953ee78dad4f0c83640fb5b58d450064&gt; - heapam_xlog.h
XLOG_HEAP2_MULTI_INSERT <https://doxygen.postgresql.org/heapam__xlog_8h.html#a09d28a8ec766e208ef3f14c941a9dceb&gt; - heapam_xlog.h
XLOG_HEAP2_NEW_CID <https://doxygen.postgresql.org/heapam__xlog_8h.html#aa6dce017eba7e3f59439352fac58a2c6&gt; - heapam_xlog.h
XLOG_HEAP2_REWRITE <https://doxygen.postgresql.org/heapam__xlog_8h.html#a1d79b0ce034201fdb685f9023c73a496&gt; - heapam_xlog.h
XLOG_HEAP2_VISIBLE <https://doxygen.postgresql.org/heapam__xlog_8h.html#ae2fb90fa2889e34ddbf1a9eb36ca0d58&gt; - heapam_xlog.h
XLOG_HEAP_CONFIRM <https://doxygen.postgresql.org/heapam__xlog_8h.html#afb6ec95decce57c1fc5833050b687480&gt; - heapam_xlog.h
XLOG_HEAP_DELETE <https://doxygen.postgresql.org/heapam__xlog_8h.html#a1699edb7efa9b08de135ca89a9d1e23c&gt; - heapam_xlog.h
XLOG_HEAP_HOT_UPDATE <https://doxygen.postgresql.org/heapam__xlog_8h.html#a124f8f7c6207e8d372efa0b3b16bd60a&gt; - heapam_xlog.h
XLOG_HEAP_INIT_PAGE <https://doxygen.postgresql.org/heapam__xlog_8h.html#ae969c2b1184a09f88380015d0e4130fe&gt; - heapam_xlog.h
XLOG_HEAP_INPLACE <https://doxygen.postgresql.org/heapam__xlog_8h.html#a94a3532f2f214b304f3098919748edec&gt; - heapam_xlog.h
XLOG_HEAP_INSERT <https://doxygen.postgresql.org/heapam__xlog_8h.html#acc254c522710da2616bae261202b9696&gt; - heapam_xlog.h
XLOG_HEAP_LOCK <https://doxygen.postgresql.org/heapam__xlog_8h.html#ab9ac57018bc8ff9c82f6d44a8d3c1f57&gt; - heapam_xlog.h
XLOG_HEAP_OPMASK <https://doxygen.postgresql.org/heapam__xlog_8h.html#a47385bef217a3dc92c3e9b99d69c70a3&gt; - heapam_xlog.h
XLOG_HEAP_UPDATE <https://doxygen.postgresql.org/heapam__xlog_8h.html#a514352c407ee9f18f5056bd4d800e4c1&gt; - heapam_xlog.h
XLOG_HISTORY <https://doxygen.postgresql.org/pg__standby_8c.html#a4da8f71093d15f8ddf825e8f14e6aacd&gt; - pg_standby.c
xlog_identify <javascript:searchResults.Toggle(%22SR_xlog_5fidentify%22)>
XLOG_INCLUDE_ORIGIN <https://doxygen.postgresql.org/xlog_8h.html#a68159f3b34be48904cf9fcb06b58b36f&gt; - xlog.h
xlog_internal.h <https://doxygen.postgresql.org/xlog__internal_8h.html&gt;
XLOG_INVALIDATIONS <https://doxygen.postgresql.org/standbydefs_8h.html#a16cd2e19ee4c0d0ce2eb22167e0a5c38&gt; - standbydefs.h
XLOG_LOGICAL_MESSAGE <https://doxygen.postgresql.org/message_8h.html#a83dd85b27791b757d7b1f9ee36faa5c4&gt; - message.h
XLOG_MARK_UNIMPORTANT <https://doxygen.postgresql.org/xlog_8h.html#a150a45ddc593edecef4c8ba2f286e0fa&gt; - xlog.h
XLOG_MULTIXACT_CREATE_ID <https://doxygen.postgresql.org/multixact_8h.html#a8e47af7b2edbf0ed8860fcdb68e59b77&gt; - multixact.h
XLOG_MULTIXACT_TRUNCATE_ID <https://doxygen.postgresql.org/multixact_8h.html#a7e837595a280f12025a41fb023f6975d&gt; - multixact.h
XLOG_MULTIXACT_ZERO_MEM_PAGE <https://doxygen.postgresql.org/multixact_8h.html#a15b1dd070fbcabfbaeadad4c61e9fe75&gt; - multixact.h
XLOG_MULTIXACT_ZERO_OFF_PAGE <https://doxygen.postgresql.org/multixact_8h.html#a2977df1a4118452b0a0e5566fce294c8&gt; - multixact.h
XLOG_NEXTOID <https://doxygen.postgresql.org/pg__control_8h.html#a8b15845655cddbc8ceff021e18b6bd5b&gt; - pg_control.h
XLOG_NOOP <https://doxygen.postgresql.org/pg__control_8h.html#aa8d44e6e58023f97028a8d7774e3ae86&gt; - pg_control.h
xlog_outdesc <https://doxygen.postgresql.org/xlog_8c.html#a28b0b87f29ac8c681ec55538c7a0d04b&gt; - xlog.c
XLOG_PAGE_MAGIC <https://doxygen.postgresql.org/xlog__internal_8h.html#a8e4c79b6eca34bb621882f23adede48a&gt; - xlog_internal.h
XLOG_PARAMETER_CHANGE <https://doxygen.postgresql.org/pg__control_8h.html#adc354269b79e6a53ea84bda5ca2e2b23&gt; - pg_control.h
xlog_redo <javascript:searchResults.Toggle(%22SR_xlog_5fredo%22)>
XLOG_RELMAP_UPDATE <https://doxygen.postgresql.org/relmapper_8h.html#a0bb2f002d83ea93ea184515fcb12c487&gt; - relmapper.h
XLOG_REPLORIGIN_DROP <https://doxygen.postgresql.org/origin_8h.html#aa1f479555c70bf34a53f288eb4fa9d57&gt; - origin.h
XLOG_REPLORIGIN_SET <https://doxygen.postgresql.org/origin_8h.html#ae090bab365094adb43942a941a860089&gt; - origin.h
XLOG_RESTORE_POINT <https://doxygen.postgresql.org/pg__control_8h.html#a0bc4e125e73e57add7c1a2b7555f483d&gt; - pg_control.h
XLOG_RUNNING_XACTS <https://doxygen.postgresql.org/standbydefs_8h.html#ab12fbc0105f85b9584eb7abdf4be9c8f&gt; - standbydefs.h
xlog_seg_size <https://doxygen.postgresql.org/structControlFileData.html#a23cf13e46c79d5ce43e944851bc3174b&gt; - ControlFileData
XLOG_SEQ_LOG <https://doxygen.postgresql.org/sequence_8h.html#ae204442ea6ae0d63ec9dd9ecf6214b4c&gt; - sequence.h
XLOG_SMGR_CREATE <https://doxygen.postgresql.org/storage__xlog_8h.html#a40d32269b4e6f811ff573b8ad8d2a7d1&gt; - storage_xlog.h
XLOG_SMGR_TRUNCATE <https://doxygen.postgresql.org/storage__xlog_8h.html#a499478a7c38a8cc140996a22a71562d5&gt; - storage_xlog.h
XLOG_SPGIST_ADD_LEAF <https://doxygen.postgresql.org/spgist__private_8h.html#a996b243b8c3c467525c5fdf491e2bc6a&gt; - spgist_private.h
XLOG_SPGIST_ADD_NODE <https://doxygen.postgresql.org/spgist__private_8h.html#a991c366ac0b700ea6cf97859a52fd521&gt; - spgist_private.h
XLOG_SPGIST_CREATE_INDEX <https://doxygen.postgresql.org/spgist__private_8h.html#a513a49635d4eab4620fa4a9cd0a66725&gt; - spgist_private.h
XLOG_SPGIST_MOVE_LEAFS <https://doxygen.postgresql.org/spgist__private_8h.html#aaa895e0a5137b26cdee5793bdeee78d0&gt; - spgist_private.h
XLOG_SPGIST_PICKSPLIT <https://doxygen.postgresql.org/spgist__private_8h.html#abdebd43c7d8301a686a9d9b2e88a03c0&gt; - spgist_private.h
XLOG_SPGIST_SPLIT_TUPLE <https://doxygen.postgresql.org/spgist__private_8h.html#a1bb43c5b6f08956332f2b50fbfeac404&gt; - spgist_private.h
XLOG_SPGIST_VACUUM_LEAF <https://doxygen.postgresql.org/spgist__private_8h.html#a4c695d55d965513172367a54dfb3cdd1&gt; - spgist_private.h
XLOG_SPGIST_VACUUM_REDIRECT <https://doxygen.postgresql.org/spgist__private_8h.html#aed51a1b70c04d574444e535448bf35f6&gt; - spgist_private.h
XLOG_SPGIST_VACUUM_ROOT <https://doxygen.postgresql.org/spgist__private_8h.html#a27c83b2efb3f0be9f543689cecaa5767&gt; - spgist_private.h
XLOG_STANDBY_LOCK <https://doxygen.postgresql.org/standbydefs_8h.html#a5fd8850a1cbb0fb49ea85661db7a60a2&gt; - standbydefs.h
XLOG_SWITCH <https://doxygen.postgresql.org/pg__control_8h.html#ad048df99b35282ec30f163c1957de9d3&gt; - pg_control.h
XLOG_TBLSPC_CREATE <https://doxygen.postgresql.org/tablespace_8h.html#a2e90aef5768f29c831df3725ffa1afcc&gt; - tablespace.h
XLOG_TBLSPC_DROP <https://doxygen.postgresql.org/tablespace_8h.html#a2b346ec30d305ad34a70419a14298a9a&gt; - tablespace.h
XLOG_XACT_ABORT <https://doxygen.postgresql.org/xact_8h.html#a825804340e245b3d4c60e72cbd7a3b91&gt; - xact.h
XLOG_XACT_ABORT_PREPARED <https://doxygen.postgresql.org/xact_8h.html#acf1fdec439e01d3c36aec08566f6af1f&gt; - xact.h
XLOG_XACT_ASSIGNMENT <https://doxygen.postgresql.org/xact_8h.html#aca8845707c6dad5ad3afe07d5882eca4&gt; - xact.h
XLOG_XACT_COMMIT <https://doxygen.postgresql.org/xact_8h.html#a6b0dd66a4a28c9923855a8834318ca09&gt; - xact.h
XLOG_XACT_COMMIT_PREPARED <https://doxygen.postgresql.org/xact_8h.html#a1b3730bd05f35ffa696212d6589d0ce3&gt; - xact.h
XLOG_XACT_HAS_INFO <https://doxygen.postgresql.org/xact_8h.html#adbbeafa721c6cd308c11022c965926ae&gt; - xact.h
XLOG_XACT_OPMASK <https://doxygen.postgresql.org/xact_8h.html#a6b97d131ba561ba540b35f1990e8c669&gt; - xact.h
XLOG_XACT_PREPARE <https://doxygen.postgresql.org/xact_8h.html#a544c5a98d349d6c27bb35ab636d029ed&gt; - xact.h
xlogarchive.c <https://doxygen.postgresql.org/xlogarchive_8c.html&gt;
XLogArchiveCheckDone <javascript:searchResults.Toggle(%22SR_xlogarchivecheckdone%22)>
XLogArchiveCleanup <javascript:searchResults.Toggle(%22SR_xlogarchivecleanup%22)>
XLogArchiveCommand <javascript:searchResults.Toggle(%22SR_xlogarchivecommand%22)>
XLogArchiveCommandSet <https://doxygen.postgresql.org/xlog_8h.html#a04faf4a0d4aa1cea61846b93f2afde94&gt; - xlog.h
XLogArchiveForceDone <javascript:searchResults.Toggle(%22SR_xlogarchiveforcedone%22)>
XLogArchiveIsBusy <javascript:searchResults.Toggle(%22SR_xlogarchiveisbusy%22)>
XLogArchiveIsReady <javascript:searchResults.Toggle(%22SR_xlogarchiveisready%22)>
XLogArchiveIsReadyOrDone <javascript:searchResults.Toggle(%22SR_xlogarchiveisreadyordone%22)>
XLogArchiveMode <javascript:searchResults.Toggle(%22SR_xlogarchivemode%22)>
XLogArchiveNotify <javascript:searchResults.Toggle(%22SR_xlogarchivenotify%22)>
XLogArchiveNotifySeg <javascript:searchResults.Toggle(%22SR_xlogarchivenotifyseg%22)>
XLogArchiveTimeout <javascript:searchResults.Toggle(%22SR_xlogarchivetimeout%22)>
XLogArchivingActive <https://doxygen.postgresql.org/xlog_8h.html#a0722d9ca53151b7bc56ab5309dd29105&gt; - xlog.h
XLogArchivingAlways <https://doxygen.postgresql.org/xlog_8h.html#ad0bef96195ee515f84087bc418251ae5&gt; - xlog.h
XLogBackgroundFlush <javascript:searchResults.Toggle(%22SR_xlogbackgroundflush%22)>
XLogBeginInsert <javascript:searchResults.Toggle(%22SR_xlogbegininsert%22)>
XLOGbuffers <javascript:searchResults.Toggle(%22SR_xlogbuffers%22)>
XLogBytePosToEndRecPtr <https://doxygen.postgresql.org/xlog_8c.html#a63e9218c8da4f289d7fabafaf099c70d&gt; - xlog.c
XLogBytePosToRecPtr <https://doxygen.postgresql.org/xlog_8c.html#a22948211fffe860cc7e711417fd2b88a&gt; - xlog.c
XLogCacheBlck <https://doxygen.postgresql.org/structXLogCtlData.html#a7efa18acfc83b86b7e0bb39c5a1d6180&gt; - XLogCtlData
XLogCheckBufferNeedsBackup <javascript:searchResults.Toggle(%22SR_xlogcheckbufferneedsbackup%22)>
XLogCheckInvalidPages <javascript:searchResults.Toggle(%22SR_xlogcheckinvalidpages%22)>
XLogCheckpointNeeded <https://doxygen.postgresql.org/xlog_8c.html#ac7fcdcaf3c30bfff91ba34a95f5b241f&gt; - xlog.c
XLOGChooseNumBuffers <https://doxygen.postgresql.org/xlog_8c.html#a62eba629a392548a2ea30e4d301e68bf&gt; - xlog.c
XLogCompressBackupBlock <https://doxygen.postgresql.org/xloginsert_8c.html#ae22ca35d456e30a52e7588ad53c578e5&gt; - xloginsert.c
XLogCtl <https://doxygen.postgresql.org/xlog_8c.html#a08295a9c52c91e205eabca6c53dcbdbe&gt; - xlog.c
XLogCtlData <javascript:searchResults.Toggle(%22SR_xlogctldata%22)>
XLogCtlInsert <javascript:searchResults.Toggle(%22SR_xlogctlinsert%22)>
xlogdefs.h <https://doxygen.postgresql.org/xlogdefs_8h.html&gt;
xlogdesc.c <https://doxygen.postgresql.org/xlogdesc_8c.html&gt;
XLOGDIR <https://doxygen.postgresql.org/xlog__internal_8h.html#a77e39e7339e0131203fbbf1da5faa873&gt; - xlog_internal.h
XLogDropDatabase <javascript:searchResults.Toggle(%22SR_xlogdropdatabase%22)>
XLogDropRelation <javascript:searchResults.Toggle(%22SR_xlogdroprelation%22)>
XLogDumpConfig <javascript:searchResults.Toggle(%22SR_xlogdumpconfig%22)>
XLogDumpCountRecord <https://doxygen.postgresql.org/pg__xlogdump_8c.html#aff82bbaf0480cad26c82637fa0762056&gt; - pg_xlogdump.c
XLogDumpDisplayRecord <https://doxygen.postgresql.org/pg__xlogdump_8c.html#aa022c354036b3f1d1989720730345f34&gt; - pg_xlogdump.c
XLogDumpDisplayStats <https://doxygen.postgresql.org/pg__xlogdump_8c.html#a54882baadad1d6a5fcbdc7bdfe7bc5f8&gt; - pg_xlogdump.c
XLogDumpPrivate <javascript:searchResults.Toggle(%22SR_xlogdumpprivate%22)>
XLogDumpReadPage <https://doxygen.postgresql.org/pg__xlogdump_8c.html#a20618c188fe79ca5007b4e77d2df205f&gt; - pg_xlogdump.c
XLogDumpStats <javascript:searchResults.Toggle(%22SR_xlogdumpstats%22)>
XLogDumpStatsRow <https://doxygen.postgresql.org/pg__xlogdump_8c.html#aada1baa0d1f491b8d215dbceaf9a0daf&gt; - pg_xlogdump.c
XLogDumpXLogRead <https://doxygen.postgresql.org/pg__xlogdump_8c.html#a4b36fa810a7810236008bb22c25f5ec3&gt; - pg_xlogdump.c
xlogendptr <https://doxygen.postgresql.org/pg__basebackup_8c.html#af3c480069d8ad046ff341a6297d66b27&gt; - pg_basebackup.c
XLogEnsureRecordSpace <javascript:searchResults.Toggle(%22SR_xlogensurerecordspace%22)>
XLogFileClose <https://doxygen.postgresql.org/xlog_8c.html#aa2986727c67ea03d40a1dbd566427822&gt; - xlog.c
XLogFileCopy <https://doxygen.postgresql.org/xlog_8c.html#a48c561d496c6f6c127f5d3c7584edabc&gt; - xlog.c
XLogFileInit <javascript:searchResults.Toggle(%22SR_xlogfileinit%22)>
XLogFileName <https://doxygen.postgresql.org/xlog__internal_8h.html#afc1a7b6a24ef166178cbe21014abe8a2&gt; - xlog_internal.h
XLogFileNameById <https://doxygen.postgresql.org/xlog__internal_8h.html#ab81e30c6e569e65b5d8f04bbb48f021c&gt; - xlog_internal.h
XLogFileNameP <javascript:searchResults.Toggle(%22SR_xlogfilenamep%22)>
XLogFileOpen <javascript:searchResults.Toggle(%22SR_xlogfileopen%22)>
xlogFilePath <javascript:searchResults.Toggle(%22SR_xlogfilepath%22)>
XLogFileRead <https://doxygen.postgresql.org/xlog_8c.html#a3b8c9c7dfdc4d28fb3071152bfe7017d&gt; - xlog.c
XLogFileReadAnyTLI <https://doxygen.postgresql.org/xlog_8c.html#a7b23db980fb02113f4314e8132fe4d52&gt; - xlog.c
XLOGfileslop <https://doxygen.postgresql.org/xlog_8c.html#a2f56b9336f820514ceecfece76228a7b&gt; - xlog.c
XLogFlush <javascript:searchResults.Toggle(%22SR_xlogflush%22)>
xlogfpath <https://doxygen.postgresql.org/parsexlog_8c.html#afa3dcf4e435a4ed1b5f9a45f92d739e9&gt; - parsexlog.c
XLogFromFileName <https://doxygen.postgresql.org/xlog__internal_8h.html#ab2ded6f67666f0069571b0e0c4ee556a&gt; - xlog_internal.h
xlogfuncs.c <https://doxygen.postgresql.org/xlogfuncs_8c.html&gt;
XLogGetLastRemovedSegno <javascript:searchResults.Toggle(%22SR_xloggetlastremovedsegno%22)>
XLogGetReplicationSlotMinimumLSN <https://doxygen.postgresql.org/xlog_8c.html#a459b5855b0f32fc4042a27193a8632d4&gt; - xlog.c
XLogHaveInvalidPages <javascript:searchResults.Toggle(%22SR_xloghaveinvalidpages%22)>
XLogHintBitIsNeeded <https://doxygen.postgresql.org/xlog_8h.html#afba8efbfce50e33c2c306e79c7d7f853&gt; - xlog.h
xlogid <https://doxygen.postgresql.org/structPageXLogRecPtr.html#ae1e0b292b5ec19588ed021069f200c44&gt; - PageXLogRecPtr
XLogInitBufferForRedo <javascript:searchResults.Toggle(%22SR_xloginitbufferforredo%22)>
XLogInsert <javascript:searchResults.Toggle(%22SR_xloginsert%22)>
xloginsert.c <https://doxygen.postgresql.org/xloginsert_8c.html&gt;
xloginsert.h <https://doxygen.postgresql.org/xloginsert_8h.html&gt;
xloginsert_cxt <https://doxygen.postgresql.org/xloginsert_8c.html#a8b6566189db35d25132cc5498796531a&gt; - xloginsert.c
XLogInsertAllowed <javascript:searchResults.Toggle(%22SR_xloginsertallowed%22)>
XLogInsertRecord <javascript:searchResults.Toggle(%22SR_xloginsertrecord%22)>
XLogIsNeeded <https://doxygen.postgresql.org/xlog_8h.html#af4225b3b8fcad6601cb5bde514838976&gt; - xlog.h
XLogLogicalInfoActive <https://doxygen.postgresql.org/xlog_8h.html#a3565c399ee3d40ed4afa140478f7933e&gt; - xlog.h
XLogLongPageHeader <https://doxygen.postgresql.org/xlog__internal_8h.html#a1b2b37485b2502f4c3b8e13caeb46eef&gt; - xlog_internal.h
XLogLongPageHeaderData <javascript:searchResults.Toggle(%22SR_xloglongpageheaderdata%22)>
XLogNeedsFlush <javascript:searchResults.Toggle(%22SR_xlogneedsflush%22)>
XLogPageHeader <https://doxygen.postgresql.org/xlog__internal_8h.html#a6bf328cd65b03f2b2998ef4918464cf2&gt; - xlog_internal.h
XLogPageHeaderData <javascript:searchResults.Toggle(%22SR_xlogpageheaderdata%22)>
XLogPageHeaderSize <https://doxygen.postgresql.org/xlog__internal_8h.html#ad4624af98c03ce138ba37961def4eb0c&gt; - xlog_internal.h
XLogPageRead <https://doxygen.postgresql.org/xlog_8c.html#a0d4418cd82148abf0d5d163334851d85&gt; - xlog.c
XLogPageReadCB <https://doxygen.postgresql.org/xlogreader_8h.html#a3a3a749f86bb5799646ba7a6af8b1821&gt; - xlogreader.h
XLogPageReadPrivate <javascript:searchResults.Toggle(%22SR_xlogpagereadprivate%22)>
XLogPutNextOid <javascript:searchResults.Toggle(%22SR_xlogputnextoid%22)>
XLogRead <javascript:searchResults.Toggle(%22SR_xlogread%22)>
XLogReadBufferExtended <javascript:searchResults.Toggle(%22SR_xlogreadbufferextended%22)>
XLogReadBufferForRedo <javascript:searchResults.Toggle(%22SR_xlogreadbufferforredo%22)>
XLogReadBufferForRedoExtended <javascript:searchResults.Toggle(%22SR_xlogreadbufferforredoextended%22)>
xlogreader.c <https://doxygen.postgresql.org/xlogreader_8c.html&gt;
xlogreader.h <https://doxygen.postgresql.org/xlogreader_8h.html&gt;
XLogReaderAllocate <javascript:searchResults.Toggle(%22SR_xlogreaderallocate%22)>
XLogReaderFree <javascript:searchResults.Toggle(%22SR_xlogreaderfree%22)>
XLogReaderInvalReadState <javascript:searchResults.Toggle(%22SR_xlogreaderinvalreadstate%22)>
XLogReaderState <javascript:searchResults.Toggle(%22SR_xlogreaderstate%22)>
xlogreadfd <https://doxygen.postgresql.org/parsexlog_8c.html#a9c2a5beb275c3e24a51da84e5b31f17d&gt; - parsexlog.c
XLogReadRecord <javascript:searchResults.Toggle(%22SR_xlogreadrecord%22)>
xlogreadsegno <https://doxygen.postgresql.org/parsexlog_8c.html#a5dae7dfe7aa758e9ff0521a133961c76&gt; - parsexlog.c
XlogReadTwoPhaseData <https://doxygen.postgresql.org/twophase_8c.html#a044e6f482ece6c76aa19c2439e299469&gt; - twophase.c
XLogRecData <javascript:searchResults.Toggle(%22SR_xlogrecdata%22)>
XLogReceiptSource <https://doxygen.postgresql.org/xlog_8c.html#a3f0d82893675c7792adcd4f92e52bf3c&gt; - xlog.c
XLogReceiptTime <https://doxygen.postgresql.org/xlog_8c.html#ab42473e36af5d4090c276ed76948c244&gt; - xlog.c
XLogRecGetBlockData <javascript:searchResults.Toggle(%22SR_xlogrecgetblockdata%22)>
XLogRecGetBlockTag <javascript:searchResults.Toggle(%22SR_xlogrecgetblocktag%22)>
XLogRecGetData <https://doxygen.postgresql.org/xlogreader_8h.html#a50063610bc5acb8bbf040147d6cdd7a7&gt; - xlogreader.h
XLogRecGetDataLen <https://doxygen.postgresql.org/xlogreader_8h.html#a185e655425468ba0f002727139e954e3&gt; - xlogreader.h
XLogRecGetInfo <https://doxygen.postgresql.org/xlogreader_8h.html#a20fc706271c4119b87defc34526016cb&gt; - xlogreader.h
XLogRecGetOrigin <https://doxygen.postgresql.org/xlogreader_8h.html#a00b3b7a225a7f7a1bfb9ec7117dea1fd&gt; - xlogreader.h
XLogRecGetPrev <https://doxygen.postgresql.org/xlogreader_8h.html#acaae032e576cc6b3d635469332c6597a&gt; - xlogreader.h
XLogRecGetRmid <https://doxygen.postgresql.org/xlogreader_8h.html#a48a8f2bac4018d6753b09805a1546043&gt; - xlogreader.h
XLogRecGetTotalLen <https://doxygen.postgresql.org/xlogreader_8h.html#a6518506bbdc4870638bf908b8ef647af&gt; - xlogreader.h
XLogRecGetXid <https://doxygen.postgresql.org/xlogreader_8h.html#a845e6dce9851c668fd79907d0965d177&gt; - xlogreader.h
XLogRecHasAnyBlockRefs <https://doxygen.postgresql.org/xlogreader_8h.html#ae5c8b95fa208a8eabf13b954311c30a5&gt; - xlogreader.h
XLogRecHasBlockImage <https://doxygen.postgresql.org/xlogreader_8h.html#ac1a4a85adc4e0c19962be566a90a5633&gt; - xlogreader.h
XLogRecHasBlockRef <https://doxygen.postgresql.org/xlogreader_8h.html#ac7ad516d66ff06aca1a2910b51823b4c&gt; - xlogreader.h
XLogRecord <javascript:searchResults.Toggle(%22SR_xlogrecord%22)>
xlogrecord.h <https://doxygen.postgresql.org/xlogrecord_8h.html&gt;
XLogRecordAssemble <https://doxygen.postgresql.org/xloginsert_8c.html#a46d746c6c6f2af9a494749982bb7e226&gt; - xloginsert.c
XLogRecordBlockCompressHeader <javascript:searchResults.Toggle(%22SR_xlogrecordblockcompressheader%22)>
XLogRecordBlockHeader <javascript:searchResults.Toggle(%22SR_xlogrecordblockheader%22)>
XLogRecordBlockImageHeader <javascript:searchResults.Toggle(%22SR_xlogrecordblockimageheader%22)>
XLogRecordBuffer <javascript:searchResults.Toggle(%22SR_xlogrecordbuffer%22)>
XLogRecordDataHeaderLong <javascript:searchResults.Toggle(%22SR_xlogrecorddataheaderlong%22)>
XLogRecordDataHeaderShort <javascript:searchResults.Toggle(%22SR_xlogrecorddataheadershort%22)>
XLogRecordPageWithFreeSpace <javascript:searchResults.Toggle(%22SR_xlogrecordpagewithfreespace%22)>
XLogRecPtr <https://doxygen.postgresql.org/xlogdefs_8h.html#a9f798cf05369dc78cd7688060d2c5993&gt; - xlogdefs.h
XLogRecPtrIsInvalid <https://doxygen.postgresql.org/xlogdefs_8h.html#a318e8305e570ecfb15130e6febed0e4e&gt; - xlogdefs.h
XLogRecPtrToBufIdx <https://doxygen.postgresql.org/xlog_8c.html#a7724df206772409331239f2d400098cb&gt; - xlog.c
XLogRecPtrToBytePos <https://doxygen.postgresql.org/xlog_8c.html#a71b7afa1e52f3cbbaf13713927de6c5a&gt; - xlog.c
XLogRedoAction <https://doxygen.postgresql.org/xlogutils_8h.html#aed615cdfe11ef9fe82f892664c157d01&gt; - xlogutils.h
XLogRegisterBlock <javascript:searchResults.Toggle(%22SR_xlogregisterblock%22)>
XLogRegisterBufData <javascript:searchResults.Toggle(%22SR_xlogregisterbufdata%22)>
XLogRegisterBuffer <javascript:searchResults.Toggle(%22SR_xlogregisterbuffer%22)>
XLogRegisterData <javascript:searchResults.Toggle(%22SR_xlogregisterdata%22)>
XLogReportParameters <https://doxygen.postgresql.org/xlog_8c.html#a4247736f85ad96f33cc37a290bbb1bf7&gt; - xlog.c
XLogRequestWalReceiverReply <javascript:searchResults.Toggle(%22SR_xlogrequestwalreceiverreply%22)>
XLogResetInsertion <javascript:searchResults.Toggle(%22SR_xlogresetinsertion%22)>
XLogRestorePoint <javascript:searchResults.Toggle(%22SR_xlogrestorepoint%22)>
XLogSaveBufferForHint <javascript:searchResults.Toggle(%22SR_xlogsavebufferforhint%22)>
XLogSegmentsPerXLogId <https://doxygen.postgresql.org/xlog__internal_8h.html#a8ddde6138f591b4282127df0b62b17f5&gt; - xlog_internal.h
XLogSegNo <https://doxygen.postgresql.org/xlogdefs_8h.html#afa9db36d4b92482e150dea8f2b079760&gt; - xlogdefs.h
XLogSegNoOffsetToRecPtr <https://doxygen.postgresql.org/xlog__internal_8h.html#ab02a343a9314a29ab9f94fc96e0c9ffb&gt; - xlog_internal.h
XLogSegSize <https://doxygen.postgresql.org/xlog__internal_8h.html#a223aba5b5efcaa6f9465cdf6b0e236e0&gt; - xlog_internal.h
XLogSendLogical <https://doxygen.postgresql.org/walsender_8c.html#a4fe0e7ef70e1bf17e92708c09e0f5984&gt; - walsender.c
XLogSendPhysical <https://doxygen.postgresql.org/walsender_8c.html#a1b69b9b9f5373335c6dc28671d20c3eb&gt; - walsender.c
XLogSetAsyncXactLSN <javascript:searchResults.Toggle(%22SR_xlogsetasyncxactlsn%22)>
XLogSetRecordFlags <javascript:searchResults.Toggle(%22SR_xlogsetrecordflags%22)>
XLogSetReplicationSlotMinimumLSN <javascript:searchResults.Toggle(%22SR_xlogsetreplicationslotminimumlsn%22)>
XLOGShmemInit <javascript:searchResults.Toggle(%22SR_xlogshmeminit%22)>
XLOGShmemSize <javascript:searchResults.Toggle(%22SR_xlogshmemsize%22)>
XLogSource <https://doxygen.postgresql.org/xlog_8c.html#aa4ae6b53287149eeb167868e4a55d714&gt; - xlog.c
xlogSourceNames <https://doxygen.postgresql.org/xlog_8c.html#a2bc71ea31ed3e005d6c67c444ace160e&gt; - xlog.c
XLogStandbyInfoActive <https://doxygen.postgresql.org/xlog_8h.html#afc72a658a332edc7df1e62a52795fb03&gt; - xlog.h
XLogTruncateRelation <javascript:searchResults.Toggle(%22SR_xlogtruncaterelation%22)>
xlogutils.c <https://doxygen.postgresql.org/xlogutils_8c.html&gt;
xlogutils.h <https://doxygen.postgresql.org/xlogutils_8h.html&gt;
xlogVacuumPage <https://doxygen.postgresql.org/ginvacuum_8c.html#a50c6cda171adcec5b3aabb90f46cd86e&gt; - ginvacuum.c
XLogWalRcvFlush <https://doxygen.postgresql.org/walreceiver_8c.html#ae807ab6c61cc901281f1c4f79c4353d4&gt; - walreceiver.c
XLogWalRcvProcessMsg <https://doxygen.postgresql.org/walreceiver_8c.html#abea9da4cdfbaff6e1b67394abe9fa01e&gt; - walreceiver.c
XLogWalRcvSendHSFeedback <https://doxygen.postgresql.org/walreceiver_8c.html#ab160b7b903131c79de34f3ebc6236e52&gt; - walreceiver.c
XLogWalRcvSendReply <https://doxygen.postgresql.org/walreceiver_8c.html#ad2122e96cbfb1c04533ead161720c455&gt; - walreceiver.c
XLogWalRcvWrite <https://doxygen.postgresql.org/walreceiver_8c.html#aba5a7785f0fa8b96f70bd378df95aab2&gt; - walreceiver.c
XLogWrite <https://doxygen.postgresql.org/xlog_8c.html#a2e2fc1a5e9a6536b067ce943d87f5b7c&gt; - xlog.c
XLogwrtResult <javascript:searchResults.Toggle(%22SR_xlogwrtresult%22)>
XLogwrtRqst <javascript:searchResults.Toggle(%22SR_xlogwrtrqst%22)>

Cynthia,

Please don't top-post on the PG mailing lists but rather write responses
in-line.

* Cynthia Shang (cynthia.shang@crunchydata.com) wrote:

I have never heard of coding standards where naming conventions required a function/variable name match a directory or file name. It seems that would be restrictive.

We aren't discussing a coding standard, we're talking about changing the
references from 'xlog' to 'wal' to match the change we did to the
directory, to be consistent.

I'm not trying to pick a fight, I just think the pros should outweigh the cons when choosing a path forward. In this case I see lots of cons and one partial pro; partial because renaming only user facing functions and documentation will create inconsistency within the Postgres code for all of the following. It sounds as if your minds are already made up, which saddens me but I will say nothing further on the matter.

All backwards incompatible changes are judgement calls and people are
certainly welcome to have different opinions. I have a pretty strong
feeling about this particular change being worthwhile and also pretty
long overdue.

[... list of references to xlog in the code ...]

No need to include a list, I can find them myself. :)

Nearly all of the references listed are internal functions or references
in the code. Those don't need to be changed, just the user-facing
pieces, which is quite a bit less.

The doxygen website is generated directly off of the code and isn't
user-facing documentation.

Thanks!

Stephen

On Thu, Dec 29, 2016 at 5:48 PM, Cynthia Shang <
cynthia.shang@crunchydata.com> wrote:

I have never heard of coding standards where naming conventions required a
function/variable name match a directory or file name. It seems that would
be restrictive.

This is not about coding standard, this is about terminology and common
sense.

I'm not trying to pick a fight, I just think the pros should outweigh the
cons when choosing a path forward. In this case I see lots of cons and one
partial pro; partial because renaming only user facing functions and
documentation will create inconsistency within the Postgres code for all of
the following. It sounds as if your minds are already made up, which
saddens me but I will say nothing further on the matter.

Ultimately, from user/dba perspective code does not matter. Consistency
does. I found out firsthand that the fact pg_swicth_xlog() does something
in pg_wal directory is rather confusing.

The way I see it decision has been made to rename 'pg_xlog' to 'pg_wal'.
Since this directory name is effectively part of API (e.g. for setups with
xlog on different disk, backup scripts, etc), rest of API either needs to
follow or this decision needs to be revised (but that ship has probably
sailed).
I think small inconvenience of a small group of people (PostgreSQL
developers) is worth the improvement for much larger group of people
(PostgreSQL users).

Now, I'm not sure whether it is worth maintaining function aliases.
Assuming these are indeed trivial (can somebody point me to example?) I see
roughly the same amount of downsides both ways.
Having aliases raises additional questions:
- do we keep them documented (probably not?)
- do we keep them forever or kill in some future version?

--
Vladimir Rusinov
Storage SRE, Google Ireland

Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047

On Thu, Dec 29, 2016 at 5:59 PM, Stephen Frost <sfrost@snowman.net> wrote:

I have a pretty strong
feeling about this particular change being worthwhile and also pretty
long overdue.

Yeah, sorry for that. I should be able to make some progress early January.

--
Vladimir Rusinov
Storage SRE, Google Ireland

Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047

On Fri, Dec 30, 2016 at 2:59 AM, Stephen Frost <sfrost@snowman.net> wrote:

All backwards incompatible changes are judgement calls and people are
certainly welcome to have different opinions. I have a pretty strong
feeling about this particular change being worthwhile and also pretty
long overdue.

The renaming is definitely worth it to be consistent with the new
pg_wal/. Now as in the case of those functions we have ways a simple
way to avoid useless pain to users we should really take it easy. So
introducing a set of aliases and deprecating them after a couple of
years is a fine plan IMO.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Dec 30, 2016 at 8:08 PM, Vladimir Rusinov <vrusinov@google.com> wrote:

Now, I'm not sure whether it is worth maintaining function aliases. Assuming
these are indeed trivial (can somebody point me to example?) I see roughly
the same amount of downsides both ways.
Having aliases raises additional questions:
- do we keep them documented (probably not?)
- do we keep them forever or kill in some future version?

The idea here is to keep documented only the new function names, but
mention in the release notes that aliases are kept, and that those
will be dropped in a couple of years (see for example 5d58c07a for
initdb). This will give plenty of time to monitoring script
maintainers to adapt to the new world order.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Michael Paquier (michael.paquier@gmail.com) wrote:

On Fri, Dec 30, 2016 at 8:08 PM, Vladimir Rusinov <vrusinov@google.com> wrote:

Now, I'm not sure whether it is worth maintaining function aliases. Assuming
these are indeed trivial (can somebody point me to example?) I see roughly
the same amount of downsides both ways.
Having aliases raises additional questions:
- do we keep them documented (probably not?)
- do we keep them forever or kill in some future version?

The idea here is to keep documented only the new function names, but
mention in the release notes that aliases are kept, and that those
will be dropped in a couple of years (see for example 5d58c07a for
initdb). This will give plenty of time to monitoring script
maintainers to adapt to the new world order.

I don't particularly like this. Undocumented aliases that make things
keep working are bound to just confuse people who are looking at what's
happening (eg: logging queries) and wondering "what the heck is that
function?!" and then if they're unable to find it in the docs then they
might think it's some local function that they can remove or similar.

Worse, those function aliases will probably continue to persist for
forever because no one can agree on removing them.

We maintain back-branches for years to provide people time to adjust
their code and whatever else they need to, no one is going to be forced
to move to 10 for quite a few years yet.

Additionally, people who are actually using these bits of the system are
almost certainly going to have to adjust things for the directory
change, having to change other bits of related code nearby at the same
time is much better than someone changing just the directory now and
then having to remmeber/realize that they have to change the function
calls in a few years or "whenever the PG people decide to remove the
function aliases."

Let's make this a clean break/change. Perhaps it will also encourage
people who have their own hacked together scripts to consider using a
well maintained alternative solution.

Thanks!

Stephen

On Fri, Dec 30, 2016 at 09:57:25AM -0500, Stephen Frost wrote:

Let's make this a clean break/change.

+1

If there are known management gizmos to notify, it'd be nice to try to
give them some sort of warning, but even for them, the release notes
should spell it out clearly.

That business where people would delete files with "log" in the path,
not infrequently on a system running at capacity, isn't just
theoretical. I've seen people lose data permanently that way, and I
know I'm not the only one who's seen this in the real world.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 12/30/2016 06:46 PM, David Fetter wrote:

On Fri, Dec 30, 2016 at 09:57:25AM -0500, Stephen Frost wrote:

Let's make this a clean break/change.

+1

+1
-- 
Vik Fearing                                          +33 6 46 75 15 36
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 12/30/16 9:57 AM, Stephen Frost wrote:

Additionally, people who are actually using these bits of the system are
almost certainly going to have to adjust things for the directory
change,

Some *xlog* functions are commonly used to measure replay lag. That
usage would not be affected by the directory renaming. Renaming those
functions would only serve to annoy users and have them delay their
upgrades.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 1/1/17 9:48 AM, Peter Eisentraut wrote:

On 12/30/16 9:57 AM, Stephen Frost wrote:

Additionally, people who are actually using these bits of the system are
almost certainly going to have to adjust things for the directory
change,

Some *xlog* functions are commonly used to measure replay lag. That
usage would not be affected by the directory renaming. Renaming those
functions would only serve to annoy users and have them delay their
upgrades.

Perhaps we should split the difference and do what we did for XML:
provide a contrib module with alias functions using the old (xlog) names.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 1/2/17 12:30 PM, Jim Nasby wrote:

On 1/1/17 9:48 AM, Peter Eisentraut wrote:

On 12/30/16 9:57 AM, Stephen Frost wrote:

Additionally, people who are actually using these bits of the system are
almost certainly going to have to adjust things for the directory
change,

Some *xlog* functions are commonly used to measure replay lag. That
usage would not be affected by the directory renaming. Renaming those
functions would only serve to annoy users and have them delay their
upgrades.

Perhaps we should split the difference and do what we did for XML:
provide a contrib module with alias functions using the old (xlog) names.

-1

Since these functions are normally used by admins and not generally used
in SQL and functions, I'm not convinced the maintenance of the extension
would be worth it. Admins are free to create whatever aliases they need
to get their work done.

--
-David
david@pgmasters.net

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers