public inbox for [email protected]help / color / mirror / Atom feed
[PATCH] cfe-12-gist_over_cfe-11-persistent squash commit 11+ messages / 4 participants [nested] [flat]
* [PATCH] cfe-12-gist_over_cfe-11-persistent squash commit @ 2021-03-15 14:20 Bruce Momjian <[email protected]> 0 siblings, 0 replies; 11+ messages in thread From: Bruce Momjian @ 2021-03-15 14:20 UTC (permalink / raw) --- src/backend/access/gist/README | 10 ++++++++++ src/backend/access/gist/gist.c | 21 +++++++++++++++------ src/backend/access/gist/gistbuild.c | 9 ++++++--- src/backend/access/gist/gistvacuum.c | 18 ++++++++++++------ 4 files changed, 43 insertions(+), 15 deletions(-) diff --git a/src/backend/access/gist/README b/src/backend/access/gist/README index 25cab0047b..6b1f84634f 100644 --- a/src/backend/access/gist/README +++ b/src/backend/access/gist/README @@ -461,6 +461,16 @@ value. The page is not recycled, until that XID is no longer visible to anyone. That's much more conservative than necessary, but let's keep it simple. +GiST and Encryption +------------------- + +GiST uses LSNs and NSNs for concurrency. This means that unlogged and +temporary relations also need LSNs. GiST has a mechanism to assign LSNs +to such relations, but sometimes uses fixed LSNs and or calls +gistGetFakeLSN(), which can cause duplicate LSNs to be used. Therefore, +when encryption is enabled and fake LSNs are needed, the GiST code calls +LSNForEncryption(). See src/backend/crypto/README for more details. + Authors: Teodor Sigaev <[email protected]> diff --git a/src/backend/access/gist/gist.c b/src/backend/access/gist/gist.c index 0683f42c25..5ca5f17db3 100644 --- a/src/backend/access/gist/gist.c +++ b/src/backend/access/gist/gist.c @@ -501,13 +501,16 @@ gistplacetopage(Relation rel, Size freespace, GISTSTATE *giststate, * we don't need to be able to detect concurrent splits yet.) */ if (is_build) - recptr = GistBuildLSN; + recptr = !FileEncryptionEnabled ? GistBuildLSN : + LSNForEncryption(RelationIsPermanent(rel)); else { if (RelationNeedsWAL(rel)) recptr = gistXLogSplit(is_leaf, dist, oldrlink, oldnsn, leftchildbuf, markfollowright); + else if (FileEncryptionEnabled) + recptr = LSNForEncryption(RelationIsPermanent(rel)); else recptr = gistGetFakeLSN(rel); } @@ -568,7 +571,8 @@ gistplacetopage(Relation rel, Size freespace, GISTSTATE *giststate, MarkBufferDirty(leftchildbuf); if (is_build) - recptr = GistBuildLSN; + recptr = !FileEncryptionEnabled ? GistBuildLSN : + LSNForEncryption(RelationIsPermanent(rel)); else { if (RelationNeedsWAL(rel)) @@ -586,6 +590,8 @@ gistplacetopage(Relation rel, Size freespace, GISTSTATE *giststate, deloffs, ndeloffs, itup, ntup, leftchildbuf); } + else if (FileEncryptionEnabled) + recptr = LSNForEncryption(RelationIsPermanent(rel)); else recptr = gistGetFakeLSN(rel); } @@ -1665,6 +1671,8 @@ gistprunepage(Relation rel, Page page, Buffer buffer, Relation heapRel) if (ndeletable > 0) { + XLogRecPtr recptr; + TransactionId latestRemovedXid = InvalidTransactionId; if (XLogStandbyInfoActive() && RelationNeedsWAL(rel)) @@ -1690,16 +1698,17 @@ gistprunepage(Relation rel, Page page, Buffer buffer, Relation heapRel) /* XLOG stuff */ if (RelationNeedsWAL(rel)) { - XLogRecPtr recptr; - recptr = gistXLogDelete(buffer, deletable, ndeletable, latestRemovedXid); - PageSetLSN(page, recptr); } + else if (FileEncryptionEnabled) + recptr = LSNForEncryption(RelationIsPermanent(rel)); else - PageSetLSN(page, gistGetFakeLSN(rel)); + recptr = gistGetFakeLSN(rel); + + PageSetLSN(page, recptr); END_CRIT_SECTION(); } diff --git a/src/backend/access/gist/gistbuild.c b/src/backend/access/gist/gistbuild.c index 1054f6f1f2..a8b82483e8 100644 --- a/src/backend/access/gist/gistbuild.c +++ b/src/backend/access/gist/gistbuild.c @@ -299,7 +299,8 @@ gistbuild(Relation heap, Relation index, IndexInfo *indexInfo) GISTInitBuffer(buffer, F_LEAF); MarkBufferDirty(buffer); - PageSetLSN(page, GistBuildLSN); + PageSetLSN(page, !FileEncryptionEnabled ? GistBuildLSN : + LSNForEncryption(RelationIsPermanent(index))); UnlockReleaseBuffer(buffer); @@ -451,7 +452,8 @@ gist_indexsortbuild(GISTBuildState *state) /* Write out the root */ RelationOpenSmgr(state->indexrel); - PageSetLSN(pagestate->page, GistBuildLSN); + PageSetLSN(pagestate->page, !FileEncryptionEnabled ? GistBuildLSN : + LSNForEncryption(RelationIsPermanent(state->indexrel))); PageSetChecksumInplace(pagestate->page, GIST_ROOT_BLKNO); smgrwrite(state->indexrel->rd_smgr, MAIN_FORKNUM, GIST_ROOT_BLKNO, pagestate->page, true); @@ -573,7 +575,8 @@ gist_indexsortbuild_flush_ready_pages(GISTBuildState *state) if (blkno != state->pages_written) elog(ERROR, "unexpected block number to flush GiST sorting build"); - PageSetLSN(page, GistBuildLSN); + PageSetLSN(page, !FileEncryptionEnabled ? GistBuildLSN : + LSNForEncryption(RelationIsPermanent(state->indexrel))); PageSetChecksumInplace(page, blkno); smgrextend(state->indexrel->rd_smgr, MAIN_FORKNUM, blkno, page, true); diff --git a/src/backend/access/gist/gistvacuum.c b/src/backend/access/gist/gistvacuum.c index 0663193531..f783edd627 100644 --- a/src/backend/access/gist/gistvacuum.c +++ b/src/backend/access/gist/gistvacuum.c @@ -174,6 +174,8 @@ gistvacuumscan(IndexVacuumInfo *info, IndexBulkDeleteResult *stats, vstate.callback_state = callback_state; if (RelationNeedsWAL(rel)) vstate.startNSN = GetInsertRecPtr(); + else if (FileEncryptionEnabled) + vstate.startNSN = LSNForEncryption(RelationIsPermanent(rel)); else vstate.startNSN = gistGetFakeLSN(rel); @@ -353,6 +355,8 @@ restart: */ if (ntodelete > 0) { + XLogRecPtr recptr; + START_CRIT_SECTION(); MarkBufferDirty(buffer); @@ -361,16 +365,15 @@ restart: GistMarkTuplesDeleted(page); if (RelationNeedsWAL(rel)) - { - XLogRecPtr recptr; - recptr = gistXLogUpdate(buffer, todelete, ntodelete, NULL, 0, InvalidBuffer); - PageSetLSN(page, recptr); - } + else if (FileEncryptionEnabled) + recptr = LSNForEncryption(RelationIsPermanent(rel)); else - PageSetLSN(page, gistGetFakeLSN(rel)); + recptr = gistGetFakeLSN(rel); + + PageSetLSN(page, recptr); END_CRIT_SECTION(); @@ -657,8 +660,11 @@ gistdeletepage(IndexVacuumInfo *info, IndexBulkDeleteResult *stats, if (RelationNeedsWAL(info->index)) recptr = gistXLogPageDelete(leafBuffer, txid, parentBuffer, downlink); + else if (FileEncryptionEnabled) + recptr = LSNForEncryption(RelationIsPermanent(info->index)); else recptr = gistGetFakeLSN(info->index); + PageSetLSN(parentPage, recptr); PageSetLSN(leafPage, recptr); -- 2.20.1 --AhhlLboLdkugWU4S Content-Type: application/gzip Content-Disposition: attachment; filename="cfe-13-rel_over_cfe-12-gist.diff.gz" Content-Transfer-Encoding: base64 H4sICDZtT2AAA2NmZS0xMy1yZWxfb3Zlcl9jZmUtMTItZ2lzdC5kaWZmAOQ8aXfbRpKfpV/R 9mw8pHiBh0jKWTvRQckc61pROXayeXgNoEkiAgEGAC0rcfa3b1V1A8RJUk6yk33LZ/MAqqu7 jq6rCzr3vQXrWgNr2Dd6vb7QjE672+VHHbPbEYOpMNrDYWfQFkOrIyx25blsIpasPWCa9pr+ sY6mtffPAc1rduKvTAFAi59s7rJ/N/Dn1wv5s7kK3u6f8VC8Rix11j5kV9yH0Z02a2uvO9rr 7pA1tJ6m7U9Wxk/CDF+zH26P70/f/cjMqWi0uw1fOLr3Qfg6/e40ZnYQsuDnFQ/mzPQWCzvc 3280Gvvwww1922gZjuct4N12A+GHTZOlXp/gf5fV9lngmy2Dmw/CtVrcNEUQtBA1va0HAfhh m9Xg1aBJNo0yVrZj0VAY1e7AqEL4Oayc3pZ8JuRMuKh2yaLmgi9bvnj07VDgdxiB4IMy9K4R +kKojzX6MprX4IGnuIXgPVYrpjZYEr34EfEX4fsl6EOfuwFftD463kxxFcE7WXDD88IAgJfr bwnwHG9MHnLA2ApCz4+5GIMPcos3/adl6LWu+IOY2o7I6EMevQQ3VlPhmoC84orHqgJvD3qk D8WvNJ6lF4QLHoTCT3yNeZxjgqIG553CEPhYzGLwDipUlq7MCMczuQPflVCGOT5E8MiElukt nyzbj3WkM9gwA43whe3aYVqOJfBLtayUkqutlJ8lhLUQi2a+CFJbNsUo2zWdlSWSO685z23v w3hREXxanvOUPFlnyBKii4YkOEskzJNTtHFIo3hAxNV5lgSA7/QY8jFg5py7M2HVWfeow+RG sj03qNSqddYbMEs4Ql5oVPf3LXs6ZQ0wfCHjrVIrZ5Te2rddS3xkVndgCjEdHHabTdPQepyb R/0umGGt3+uhCd2AfR/4s2mGr79mjfZgUAcNwo+2xuCK4ZBFFItl+FS5Ew5HkhgtprrP9tgB +/7y5kI/OzmejPTTu9Hx/Yh5vrx4f3I5uT2NrvrC9Hyrydj9XPhi6vmizh4Fc4WwJKJwbgdM fBAue5zjG3d0B346bxagsAvuNAmstV/buwUZjVxSiLG7dLgpKgsRcpRxnY2vx/f6+c3d++tv ruosWvI4uBX+grvCDSty9XVAhC8Q7Mnlzc2VfjW6P749vhjpJ5fvr2+qX8J0ONFEhKdzYT4E q0V+spKRoId7Aex7MvhyvsZb39LxWnaFRSjqMB5XVgEd89lBla1nDP2VoLWB6dRhC+DVyqv0 FI23+K77rmeJJr5l5kxr4xYnamwBUJp5aPLDaXtgGaCZhxZ81Y60w8O0Zm5BJPVzCxBq6aHW rUMgU6PPHqop3iTZhB4xJNZUiDzqbGL/ItgUXGSwBJA6uxhP7if3qJQHODAIIbghlttTVrED nVS+SjIArV2GPnvDXpzDpldKB4hHLjcciKu+YheA4QQHXE6u2WsaBC/4ce75a/hKkSLC4qqo LXt7wgkEw9kjsGvYFsF3x5cShlQ1Xgqu+ftLbzZZOnaI63UEn0bqLDXaApA68xzLh/39QN/c AGI3R0xDcw6LBZOYHrHg/sPUcxwPdHY2DzPLKiQ+s6znkMwk7v3G3t6v+La3gXa8vZX4xt6z qU8NyZOPt7fRn17acxgQYS+g7kKE5xDjADYCJtjf8hqQA2PIVbCrrCKBkAtfMvhOb3AB3htv XfExlKqtjBsioDvSvsg5AB1ttEG3jq71cKDVO/3/8xutoXi+w4ZjOyqmBNq7mU4DEV6vFobw GdhDx4MLQIy2VjN18Yf2j7S1Ng2p5UcwiQdXkxw4Dr7ljm1VQMMB1F0tov2i1hXj0H4E1DHU l+puYtq2uvbbfqNkx32ztEB8FRmmJrdPNEk9JqPO7HC1hN/4noRM7kBpYnYiqUYU1TYRVMvT wyQ5f5l9XCs24xm+1nZla62Mq0zZiz/NetfW+2grySxtaNI2hkW2AAIZw3lwveruoUmUqW+O GBSUClL40Bh2esOuGDabhtW1IHgWxtHuQUqEbXukEkGiFe0d9uqQW+NHuxMZUZ1WhPk6gVbQ VJJ1m6CRZAdkK9EORXK4WQp3AmFdhe403tJ4ZfmzLFYgktvPMajgCXdShOwapFa0Dhhm5yxY +QLxBIzDlw8cpqgz7lqojCJGXKe7rhdi1QcQumFThvfHAWYklRe4Oe6EeRuCTRi7H8gqIKEX hYRWq+zVK1RJoKFSQvOnT6SzG5CwF29SfJGEFSQcOTZfHY+vN+cdWaYlMhCUvn53c3O/PfnI TVw0dp18ZCZNpCHpBWewRBlIbjaVf8joYIB6fTjsluu1PnVWwVz3BbeedEJWqumFpuJZ0cDv 094/Sn2fo7+x0u6gtVm1LdHVMmX9HRoKa5PW+cuEjIr0sp6EQy2DYBOs485KSKPrLJ3pbnUJ 2WJsoWXOACmH0DviR8P+YDAcNJuCC/g11Xp8q0PIIiv1B1lAqrFonUPcN/Q5wH2jI4TOIfsw ISQGBGGQCaxP4NaDihWntg/+BS/U2cp2w26HufQzqKqgOOZcgfdQfvn3aAlpBnO4WsU2Y5UF TejFJl2IB9XZL8L3sCIKcRKvsymH2GM3xciX3YullINT6gHBQtvgw2m33Wz2ukZv2hH8qLtd PfL4yjUkD4tK0pU6gh9HqCIwQsfbugIF/aBPaUPjYCEl/r3S2MEPsHSkR3ljsdFYw6rQNC2g KP4E47DBlCRmSo5I4EYRbzEt+ZUUji82OusVlKpaDludZNAfHqEM+kcdVQz1+aMUgqyZFsig zt7B/fvV0hEMgnQpEnQL+Lm7NNAVff/99+zMi0qkLPQi38M4w/o086YsnAsylgxLql8p97Pj 1o7zh60ChCwrLcANEtxsCErF9lly27r/s8dohRswA6R2vql1zJ4YDNoa7PyOafZ6Wtvsb935 WWSl2z4LSI6h36Hiez/SNyP8/1B8v78bjeL6945l9+yYZxXcU4P/1aX23NntFnWRUEpLQUet wbQvOofNZt8yzLbRn3a2F91z2HZQUwVJdvFwUG93wTDi5yEFMEYIO5qYT0w6uf9ubRgPHpVp RLGq2C4Zz6jEn+39GlUDXjwqG2CEj4GO3p/iXZJU4S32hlFkXQX0GEVplZPL0/eTf8oCDRhT y3P/HrJAQLCulIphpRSAG4hDGlFpPouhAXgd+hePTXufx2TMW2rBorQlRRWlSTpyEzDVamuo WEcLmbCGixX3N3InvyPUS1GR3LXrOH+3dAAAWwdbN0NBY0KhWubh1IbQTN7vtHuHmmg2hxYf dPvcaptbN0QBvtItUQArjfeQgnr4GOKWgPvbjLd04DZo1kfAaLszan8BtksbjM4drLYvgqXn WnQb0mjYUNKYU3YqEfkCeP4krI1G+rMN9OSWagO7H4/KmcqH7WqoCzHk7HWuLNGWZYn24Gg3 ScCGv7QfxKMdCNrYyHffg7yecja5sydLTLTHrh0izWkKL0fH5ypw+xPYvntRqF4y5JnszteA NrB62CdWH2mfz2p3BYY0xIg5eDbb2afo1/U3l5eTP08KiP6ZUsgMeaYU1qM3S2GbRc30bhVa tDSMsqTdQ25oHYh6exBaHGrDvtU1xPbUN4Or1Ipm4GSZXFbJqSayz/6mmnLYS+wQ9FzZuAK5 CA+5vgptJ2jOX6bAZIPQA/Zbpe+Ij8JchZ7fAosNfFuApBGilhsbNRelRi/swOQWxMGZ68uZ DlSYIncZfSZepBppr92lImmv3ZPFnhPQ8Qn2xmGYXvng2XQASvHSqaQQq4AV5TRj6PeYMFLl BreDzR37F3FC2XCi2KkGYQwVgk7bLoTxUwvrhI22jLBK9aW4ec/YDhN53oHRbQujMwB90bTu Ubt72NOMcn0pxpXXl2I4ZG2HHC685/RFNRaCgEzPkZs8qytrkPBpmRWhUjhsHmiY3OX+0zPU xbGN5c+t5c+BPQP276hLmDkErQW2Nq5ckzS7VFL5vklj8/0opTX4gB9xi0NKO5i2h1pHM46m 5RLK48lLJw9DO7nXBX9Qww8qXkWW9tRbPk0kZGVyNfNjBwEowfIlr1hBWF9XdPD4oEJA4DUw b4hLxVFZsKqOyCl9QPM8Dr4Vvj21hTWigFxYyZA0eSh9O/5Wx4z5u+O76/H1BfgUvHI3ur25 u9exe0EeQG/HHK0tcTLrC2cp/ACcGCgKpClv2N3o8nZ0NwEbP7o+Henw/er4enR9nxylaNtl YegbIKNfQnZWGd3d3dypLGCvInzfBK3Cq6c3ZyP97Pj+WD+9ubv75vZ+dFaN4BjALYJZ5aUt TyhkOmO7jCo07IsVhql+JJYvgpeyNtbrt8la9zvS83+2iCVjV4HQH7kj6Uml2wBVkGNn1UAJ IK4MbzoGyYoJvPwzxPT8kxCE3JT7ZPuajU13o73cgdSmo3WOLMhzjoaHvN8fDjYk/lksBTs5 A0HhHbkueCfHFXpL2bBj2Xje32y26N8+i6zYv1WSIFVCH+FrzhzP4A5y4+bkHxMY/1/Af2VA PfjB9shxewiRRghoYnTxaslCNxcPW9ka938Xkhvd3Qd9o7ZetgD9ivioPFv8As9mDjSzDY6u TUxuWeJDCwPYcobGMyBDtboG/Kxj+zm4rFrroPFHvfZr7AD/s3i+6ALuSOppgwiyik9taGBZ ZJf25D8u2QXJhZ1hsc9bYmjELnxvtYzGE47xGaj++Hx8enw/vrnGS7BrNhGrBv6h5LWwgSYR Z0Wd5uiakzdSPraWcszgp3xIpG136uWGpfrRXxbcoVB1SxyQuJdrPi+8O7XUQlqS098JBrZw Xdi/nFxL6wZ5ElbL5EH0MkpYGgbofehhhmWbWBsAY8rBDj4IwoZn4488QJR0gqAKCJy5Hto5 TMEEN+cy5VI8/psFG9YV7OSbczB9Onicyfifo729dh+XibGtbbKVi+ENIKWkBEjU19Ux3f7w Q3rwj9T7dDs7tZdz4Z+GH9kBhK5gnPHrG4a5zpf5+2cifT+eHGNmrM6p06D01JVNVcakk2UQ TzqxZ9PtQI+5Knu1cJr92oZoW8buNWxMoxYAdkrq8F48sYMH8SQbvihsKG/A8kW48l0JCmOA Wgz0L0QIWCrvry7u9Pej/9THZ+D2L1ULWZJ1GOIS03Qz/KhL8VZuL/TT8e270Z1+PJrop/d3 KbIradlBQgnzNt7CWxpMXnWEW42TTUVNvICq7ATzZir0wLjaxY4I21U8SxZNqbj1MXy5JiOW 8P8SGVF8sKZDrmAHOixRSMdvcusyJVzatzMbj1Fozz7a4VzWk6KgB2WMu0wqlxpGxY2E3pZr ZmHlnDQwww7Zk5dnEi2rxhLBkey9RKbgtBCOBTr18SCk7vl6YC9sh/tKm90QA06wYkIprWp2 WSvlC7lhlZTRrGGJMi6xyI4iNucfsLUGA07stJFmDaxSY5kBXAUr7jhPNECiigLVCkoIll4l DE3GKjdgtsRHU0g5YXvOhT25J3OoZgkExFcg6cdmVSJ75z2C5/Pj0zC1Js+FqRGH46h1TFMn ANFJGk0Sep5EBgt/YhQDBiB1Lo8QkqacsGQpBLtseQQW8IWiEeEKuAEE0InwT6tAIgfrj8to 0ig59NgJICB+nGMwsx4eaVPAZjAMox1qcELan1hoLxIuxw4UNZ5FWU69YDVrdLB0kENqYStq aCWEMIlERswy6OQRF42HjZKZWLVeL57kRWEXiR7epNyAHHBTyGzYwh5D7wmygizlGplqC8cC IGSkCIUZSlxETICPCQS5g088JXqkFdKMmCjhcB7gdlG9X6CQj0oc8kBIPvCFoxYJrreUnidU fM2dYO6tHAumowa4rNY/v9+xWmWfPrEXG7xWvOMoK8F4YN0kAJEAB44IE4waC9CsQaaD5Uac 5WbJf16JM2qx4XKRSiZYj6QC/PisDsKON6DcXA6fMYhCZLMc6KTcynxNJjE/UioQPDqT6ARN 4lC6rSKbOV/iOqego2qD4FZSzXZSkhKX54JdsLxHsHEgPkhTZyuI0/Cg5NH34N1WQ0HeCwqA 0WCklRPXIZEF3kKUKLnknpS+WmYYaRMARfHa+Nu6RCWVFUzNAugw0Ryhv4+1pczCsjfohiKJ T6SY8IkK1e0Hsro6/v74cnxxXUHhedNKXnbrLlisnCtc8rZE03i7nhvkoxQgkm80uFI6GuUd sFfsv2nY+eXxhX4yvr86nrynFWoRht20uZoIkgqVGtCxFyUMq0ZpfqpjNNcBWrxZ1MylYWSy WFQeJcrihevYD8J5qrxYxzEK2dovQtK1KZ6pyAgy769Dv47GxXaXq5BFHT7yhbpxM024cuxK TdyPxoKvnkEckhr7Svpwug9J1Mqh88ciyFxwL9fzIQ2VDviTq8BgoM60arU0yor6mmibfbF6 ua6dJAIMuV5UsSKyk7HYmfisWEwN+4vEYpsCLRU2pwOtP0uRVeC7nvdfqMjeKsTBf1lFVrz6 oxT51KPjKjPERUbHpQmNxnUnUmL48bty4k0JcbFeg1bnmCppvRILMMqVPMuZVs9UFuKwRRLl BC6rDJnxFILLI8ksxMJcPlWWdfaqQpS8g1hK+HL/gEdaWrqDT3cqn4gQa98je+KXrPam5H48 u6x3yyoLq/RKVqD2kcKVYGZ+ouTNdGh2xf0HKvNAzBInJxjNjr/FOFrFbBAyOhRsRCAQpq4g 9fRVKIV/UMXhsCgZfICBc1B8Cw6IVq4NPhuCJewiHQcyXoGgyhAhIMDYbCW+Wgckpe6XVP1g Wavhg4kfh1qaDojEIOf5aC9WC5j455WNQblaJCks2IcG2AeMxDpabxjF8VMMF23qcJGIsNcb fvmYnQHbgzhW+q28vlv2dzmMXaBUadfodHtGd9g3u82m6JhWp2twbUO7UBm2fPW3DFI+AKDJ /n+t7KgbK9EkhOKDSXtZfF1WN593VtmyHVXxzJ1h8lU4L7xB79EJd7vblZ1P3e6RPCi4jQm+ Al2sgCuD6H1m1pXZgO8ffvhRPtq2ACW+nd2LxRJLZEF0gL0uuv0hx957puMFInlvU+dE2V9w MXaBis5nDrlhicN2u99sDru9fg+UrL/hQcMybHnFKoOkhwao8ak7yKlVpoJdcBCuPkvuRse7 u2tWSctFRvcMGw/X6bGHDefkSNpRFzdL7ajbjo6UuSX1QJfKnzltpM4a0rf02V6dncvjP0Oa KHkSKJ8Ulp3o4Aqo65MM2Iz7BnolPGJGgxQ9EV52EKy6UIElJ/LRFUM5AellnzW04Dj5M8+T 99arYOuLux4v/yoH4drpcAwnPbnS/zm6u9FvrnWKgbAqgX2ousUXQIYle1irqk+jreEDgjX4 0q136O91nONTgVJ+FflxJgKTHeAfZkifEgPFblX1NbK9iDvgjmDYOwsr5XShoh59Vt6stOD+ q2zxpRQVHJgw565tUoERSIqZh07MsdanKhx72MBQoEiw5yCkwsLfA4XGe+BP4PXVkQoymj2q ug+481CAX14FVH1IPMURIyRvpzwxEnjvUTMQkJgIDfEUr0C7VtPG25DPmgW6QqEZte9Ctp4k LjEs0gv54GBu7sTZdmZ+BVeGCh8/j54QfwbWLFVJnLKBmNpd5QPzUVVGNWiD1C0RYAQCUc+E ZPEoZMGN6kQB2AKITkh5PBl6ELLoiSIPQyS29D20lCJQFaP/qe5ae9tGruhn+1ewXrgrxZIs 6q0ku4Udy4lQ5wE/NigQgCBFMlbXFlVRStZo8997X8MZPiXHWaBdZG2ZHA7nPWfuPefKC9hg hGeKW9zIPIEu88Tkeb+J15wVqXISaxt09XI1/8LSIFo+sYzwgB8lpb7H7VoGd/MHtVSyE65g x3DmkbOe42toLk/fXV1fOtfTtxPnanLtvLq5vIQBUYNEMFBWa2F1dntDEqx3e6Mxr7Y0XdWU 5PmaViiK9gw5JzCZcK9qLVfBl3m0wVgMcDnCdZr8Jviq2e8vkgeydyD9X418lCJKSaLEovoV rckWEiqxa7YpoorIIBRnTQ7HtJSUzaQSfRSrIM1HzU5QLy2gh5S8ONOFe3sGZTQlgtoZuRiR 5CoxhE6nGA8Aivv9UeACLLbbXcAvw9Gogl1Snt9W/GKkJTDZH5MEqi9Q8gJv84A7QWFH0S5f sKFnTrnG5vcNf7DTVVqfdRJN6G8EIKEfhNbF6dnk9OY13AhhCi/WYS1ew4kT3nVwcWqdXFy8 f2XVDjeNQx/+1a1D/9PioJHI2HJ0pRZ037ssbUmViXZIm4Ab/mIh/Q+vNkyec+hbelQbwBDh cD+IfiXC3RYmICaLlsGiZg7QFVOv3j6ccldOfUW1+h/eT7974qPGpWoDLZn1T5vz0E0n6HbC Sd9qkXto62TPhIEsnm3pRCqYoDvyhjMvmLmtVtizu6MhHFoqKN4lmZXP8UxCGuodGunMGjQQ /8vNAkCt37r91bwYP8THzKb+FUda4YFGVDg/gs+tiNtWnqeTRITk48gQydxHwwGvUnJTGPrh KrqHv9Rxdx3RH2Jcm21WsVJqq8fwAWwq9GDK70TB/U2FSqNAPlfO9Opy8roWwok9XjsIxyXg E+bl4MO53CTMUnkCgzdJrztfBcEZFOuPO6Td4ciklblDVbY7319nBZGiRUBcu30yA7PtsqnL p3Pk0qksqTL7R7sllJfL4uDg4uBwBhaeZzApTvFnvPxh1dniDsM49EXc0u0A+jmyuz2muO5a QpXVgkxZmHUUhg5cicS6n1zg2CjqcpMFMhRDDZAMNZWszjV0H7NHmuAhGtuCeB2TfbKpGFuv 3n/4h3N6c05mVTSiPrNEBpk4FKgOtK6R99eq5RvI+ps8ZT23dBaJhI+QriojHYupFkmRAH1P 1+L89IIFlIy8zbDb3EfxGtkRa1hp75H2wK3ckx2/rcfVTq38E6w081CKZd3EgWg/eU+gGC4A EpHt4KKR0r1j07Xe7whw4+df5MlaqgFp3mRTpNqvnm4UlPUT/qTwsKKP4nCqo9EjK5eYI3hR cpjh7Xx152uG6rWPJ9NrZ/IbbEcOFft8ejGBw/vJGWteefBBwRV1PvQbyVknX8/q9LlaF5YL Va98kyJ6cYYvrXYhSZ1aZ8xxUMaDRqf9yObZM5jrDC4QDtA0IRrvp4PD+NPBc+vw/gDWN8mn Xs+VD13WnKEHD//+IgVnPpIUPuCpaGKW5ITn4ahbrXEuwH2SvVmbBexKnwNfMlFoC4O3xWzU R1s+HhvxcdJuzmBgkn+SuZu4QiY8A8mG3pjizCiIg7UpWOeOVMi8xPmjVdJq1eOIdOKY0i2S iKeP9nZxsPP2YSTfQWxMz8Cpm9Y+6zj1ym8cNg66dxGh36FswFVMhI+X0+uJ7my0Qdd57az5 8doc21xriqUkH3eEXEkc7Qrso9KoaEPt2bA/8oejcas1Hve7ntcJ7AoFTnFeW/BWko6O8uRj OOqKqwEOstDcNzJA1YEini7OPIrYids++295wvl8GTbzhXsP3YUWkGhZ15bS939HOtXPxINB ghMaPYIVLvC0Erqz9QbGO86floqCQo5TOl910HMKt/AEf0g8OJSXIK986a5vGygQwQ8SZVEv DgUJjioTZAAV/lIgR2roMNTZ2vNLNxURvbgb0omk78furN8feD0XgL3r9tudwbhtB9v7PpNZ eednErISmoXQZf6A2/Vm6fjB2s2LKSUFxpssvrMLG35ncC2npcxtEnke3wf3fuBtPivoPUKB 6NFowKCMjOkw3k0XN6ET/Igf5M9Y06kYieJI5TIJDEW8uN8sMc5XOtBpWhAvClbd7RlkDu4L sgeUs0z0ebT6zYRrtXt8b6mWe9NdTkpkaANAn4h+8ZKgVHZMsifPbhuN+4TG4FOOdK4TwjBD VPYLzcZkMsohXeg3eakWtU8JAUfTK1hjZe0ptzTHcqagCfR+oXAuV9EXZuvdUqugZ5piLMww YDTaidEQIfnAKnAXRfBs7CKxeBFtPt8SS5TIo1BPZu0KRlxCF7asCxd935sYmygKBeF2ho0u NGuvazd6ScMWWAmqGpYX3TICRGIGZy69anJMUMsIxxNdGtFM+B4PW9PV8NTxWkaNEr6KEEgg f3ybqfHAXWUqdnLsMSJlu4nFvMEUY7HgsbUX4IvfnC8SJx27gHjwvgu+Cn0SebN4jYI4X0en qrowoKVadUORkZbbp2kPH5k/PFM8UoKHtI1YJKtB4IbsDhg/yNHAsw+pbOKNF+MpaSEEZbST MZ8VBg9traGcM34mf0OAZOWVS44JGJYL9GawtdtoRc7KXa3chwaOZooOaJyBYKT8a0M2NzwA kb5LUYlMLwRRoCUvtBMGAANIMuSS2uarywFKuJbQ1tpRQhTbBRLJqUIUScrgukJP6G4Wxho2 s9H3b4P7aPXwip0AbO+8jpapqw0DIBqEHMmjkQ2OYKBJU2Kh029bT9QoUE8oVhbzrAow7lPn S9HyLlPm6YOZGy3bEttbgapsVjqzSP8fVNpkde5a6VIUmP2GG6/qruC+MJh1fLs96wxbrXa3 0x6H9rhX4UvJ5pIHfNkUJMcms2qvUxULoSTQAUz3+NiNH3KQLbm5hEOXu/ou9ke8nGdu/XO+ Pob/t/OKumObgsvA76HmFWGdK1hFDXF+/mUa30DzrzQVKQkwVsQt2oFcVMEu2o1eVPy9R175 PXVo9NqD/rDvj0cwgHqhbYdet4hKVJyHHj7F92nw2Iio6ScNHjEnIsH/3QdY52MCoLaN7QB7 YBPlXIRvSBjA2y5sCa6h3tGK0nxSVhAUP8BQXJXgnIL84MtrtvUSTUlMZ3dDHXRNpz2bXEyu J2dJaptSp9QvXhAs+IuZAFTA0xShhQIZ9JlXZOb35uTKeX1yeXryeqKy7FGWJBWRiEXRQr8B JSo+QLMUy4YoBiw9US9+CIjDbBHJl3QeAK9jxpJoI6IddQb7vRewyGuhlUrceKR4Sql1c2oM WFvbf9jnCI0RGEMxUCpVQx+exShkpjTFdcQNiTCoudysYHVhxinzNeG2KK4EylB+ut+whHkp CuMg4mr4otXZID8xI8w6fSifK9nv/PKq7u6q4Z/NRoNZ4I065Rr+sjcYGv7O6M+W8N8mFz5E /NVieS2//Sgtf9X3qf1Zkv2f5uECfepC+n6TE5i/ScvwDX6ABHLK7zkqxJPQ5O82uMCbUmP5 GPOwI0Y0eYZTU2YLlKAAFcVEMhQl6XSky9K2zTqDJgwDCQCS0PM2DfmLdPLHq4IVWSWPpjJZ P17kUpk1NCZ5YWStg85QnVroui7/Xj6v+n4Sk2zsDXvjcBi2WuHYHw+D4azdK98K8/nkp3g+ DfNQyBDSz2yJUDsSyr3BrbDQJAYJ4+ygZXI2UjfdHKE6eT02b8m9+TrImsbUrSgMEx72oMcB KPtsvEG4hxNPJCTaboBrM5z+M1cI5ahn0resZ/rvF+n5k9ItiYNTNBb6+Ya19B3ZXer6+SL5 iyWBW61mPvu64A/ce5b4xRK4EyJ1DKY3757a6JOoUmGDQSCIL/S1THWeTEhfENCIAlbBekpt 50fWvykmDf1Xq+ExnrwH6B39cDJ13v82uSQfg/UcUIn1HzMxTB9kNKuk0yvnzeTkAyXEKjTN 9tPWtVTUIMiuuVdifTPSNXCNqsyu8rBDK1zlW9I+m6rMGroFAHlspxZLX1Ljd7uEP7sDCXt9 RdYN9krBgnWnxgQstDX1+VipbNiaWa/j7pa+ouLhHsgjCADZZeda96gTwyDtUZh57IDxvrlo fo+N+cV+U7KgtfWJllS9iu+YW8FxPEVo3GHBLzE5p26bJVRNlvpeMyzSie9PYQUrKiZet3B5 Uy2IjWmi51RmkfFHo/DdlDX+eB2sUVSS3ueE3trrdxp9DDQ5atg2fbdCtmlxs6EY/u/VvDcL nS3TIs2rpzoBFKVv6qJawR/KcS6v4iNrxgqctbsW7bi5cflYK7IeSboMu9t9k85/pCw2g0Ie bT/T760curu9+VFGrKe82VIklRQ8YgCxEz7SX0NcjFmS+0k4+O64O/DavttqDQZjwEZ+f2Rv x0c6n3J8pNOwT4OwBv408RE64M+ml4yPzHZ/NFtMr5/J8zswQzK9/USqWGEPJlUkClHT2u+0 Ou2Wvb//X1n/j02QfwAA --AhhlLboLdkugWU4S-- ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: reorganize "Shared Memory and LWLocks" section of docs @ 2024-01-12 14:12 Aleksander Alekseev <[email protected]> 0 siblings, 1 reply; 11+ messages in thread From: Aleksander Alekseev @ 2024-01-12 14:12 UTC (permalink / raw) To: pgsql-hackers; +Cc: Nathan Bossart <[email protected]> Hi, > I recently began trying to write documentation for the dynamic shared > memory registry feature [0], and I noticed that the "Shared Memory and > LWLocks" section of the documentation might need some improvement. I know that feeling. > Thoughts? """ Any registered shmem_startup_hook will be executed shortly after each backend attaches to shared memory. """ IMO the word "each" here can give the wrong impression as if there are certain guarantees about synchronization between backends. Maybe we should change this to simply "... will be executed shortly after [the?] backend attaches..." """ should ensure that only one process allocates a new tranche_id (LWLockNewTrancheId) and initializes each new LWLock (LWLockInitialize). """ Personally I think that reminding the corresponding function name here is redundant and complicates reading just a bit. But maybe it's just me. Except for these nitpicks the patch looks good. -- Best regards, Aleksander Alekseev ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: reorganize "Shared Memory and LWLocks" section of docs @ 2024-01-12 15:46 Nathan Bossart <[email protected]> parent: Aleksander Alekseev <[email protected]> 0 siblings, 1 reply; 11+ messages in thread From: Nathan Bossart @ 2024-01-12 15:46 UTC (permalink / raw) To: Aleksander Alekseev <[email protected]>; +Cc: pgsql-hackers Thanks for reviewing. On Fri, Jan 12, 2024 at 05:12:28PM +0300, Aleksander Alekseev wrote: > """ > Any registered shmem_startup_hook will be executed shortly after each > backend attaches to shared memory. > """ > > IMO the word "each" here can give the wrong impression as if there are > certain guarantees about synchronization between backends. Maybe we > should change this to simply "... will be executed shortly after > [the?] backend attaches..." I see what you mean, but I don't think the problem is the word "each." I think the problem is the use of passive voice. What do you think about something like Each backend will execute the registered shmem_startup_hook shortly after it attaches to shared memory. > """ > should ensure that only one process allocates a new tranche_id > (LWLockNewTrancheId) and initializes each new LWLock > (LWLockInitialize). > """ > > Personally I think that reminding the corresponding function name here > is redundant and complicates reading just a bit. But maybe it's just > me. Yeah, I waffled on this one. I don't mind removing it. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: reorganize "Shared Memory and LWLocks" section of docs @ 2024-01-12 17:23 Nathan Bossart <[email protected]> parent: Nathan Bossart <[email protected]> 0 siblings, 1 reply; 11+ messages in thread From: Nathan Bossart @ 2024-01-12 17:23 UTC (permalink / raw) To: Aleksander Alekseev <[email protected]>; +Cc: pgsql-hackers On Fri, Jan 12, 2024 at 09:46:50AM -0600, Nathan Bossart wrote: > On Fri, Jan 12, 2024 at 05:12:28PM +0300, Aleksander Alekseev wrote: >> """ >> Any registered shmem_startup_hook will be executed shortly after each >> backend attaches to shared memory. >> """ >> >> IMO the word "each" here can give the wrong impression as if there are >> certain guarantees about synchronization between backends. Maybe we >> should change this to simply "... will be executed shortly after >> [the?] backend attaches..." > > I see what you mean, but I don't think the problem is the word "each." I > think the problem is the use of passive voice. What do you think about > something like > > Each backend will execute the registered shmem_startup_hook shortly > after it attaches to shared memory. > >> """ >> should ensure that only one process allocates a new tranche_id >> (LWLockNewTrancheId) and initializes each new LWLock >> (LWLockInitialize). >> """ >> >> Personally I think that reminding the corresponding function name here >> is redundant and complicates reading just a bit. But maybe it's just >> me. > > Yeah, I waffled on this one. I don't mind removing it. Here is a new version of the patch with these changes. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com Attachments: [text/x-diff] v2-0001-reorganize-shared-memory-and-lwlocks-documentatio.patch (9.3K, ../../20240112172350.GB3803561@nathanxps13/2-v2-0001-reorganize-shared-memory-and-lwlocks-documentatio.patch) download | inline diff: From 7cf22727a96757bf212ec106bd471bf55a6981b9 Mon Sep 17 00:00:00 2001 From: Nathan Bossart <[email protected]> Date: Thu, 11 Jan 2024 21:55:25 -0600 Subject: [PATCH v2 1/1] reorganize shared memory and lwlocks documentation --- doc/src/sgml/xfunc.sgml | 182 +++++++++++++++++++++++++--------------- 1 file changed, 114 insertions(+), 68 deletions(-) diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index 89116ae74c..0ba52b41d4 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -3397,90 +3397,136 @@ CREATE FUNCTION make_array(anyelement) RETURNS anyarray </sect2> <sect2 id="xfunc-shared-addin"> - <title>Shared Memory and LWLocks</title> + <title>Shared Memory</title> - <para> - Add-ins can reserve LWLocks and an allocation of shared memory on server - startup. The add-in's shared library must be preloaded by specifying - it in - <xref linkend="guc-shared-preload-libraries"/><indexterm><primary>shared_preload_libraries</primary></indexterm>. - The shared library should register a <literal>shmem_request_hook</literal> - in its <function>_PG_init</function> function. This - <literal>shmem_request_hook</literal> can reserve LWLocks or shared memory. - Shared memory is reserved by calling: + <sect3 id="xfunc-shared-addin-at-startup"> + <title>Requesting Shared Memory at Startup</title> + + <para> + Add-ins can reserve shared memory on server startup. To do so, the + add-in's shared library must be preloaded by specifying it in + <xref linkend="guc-shared-preload-libraries"/><indexterm><primary>shared_preload_libraries</primary></indexterm>. + The shared library should also register a + <literal>shmem_request_hook</literal> in its + <function>_PG_init</function> function. This + <literal>shmem_request_hook</literal> can reserve shared memory by + calling: <programlisting> void RequestAddinShmemSpace(int size) </programlisting> - from your <literal>shmem_request_hook</literal>. - </para> - <para> - LWLocks are reserved by calling: + Each backend sould obtain a pointer to the reserved shared memory by + calling: +<programlisting> +void *ShmemInitStruct(const char *name, Size size, bool *foundPtr) +</programlisting> + If this function sets <literal>foundPtr</literal> to + <literal>false</literal>, the caller should proceed to initialize the + contents of the reserved shared memory. If <literal>foundPtr</literal> + is set to <literal>true</literal>, the shared memory was already + initialized by another backend, and the caller need not initialize + further. + </para> + + <para> + To avoid race conditions, each backend should use the LWLock + <function>AddinShmemInitLock</function> when initializing its allocation + of shared memory, as shown here: +<programlisting> +static mystruct *ptr = NULL; +bool found; + +LWLockAcquire(AddinShmemInitLock, LW_EXCLUSIVE); +ptr = ShmemInitStruct("my struct name", size, &found); +if (!found) +{ + ... initialize contents of shared memory ... + ptr->locks = GetNamedLWLockTranche("my tranche name"); +} +LWLockRelease(AddinShmemInitLock); +</programlisting> + <literal>shmem_startup_hook</literal> provides a convenient place for the + initialization code, but it is not strictly required that all such code + be placed in this hook. Each backend will execute the registered + <literal>shmem_startup_hook</literal> shortly after it attaches to shared + memory. Note that add-ins should still acquire + <function>AddinShmemInitLock</function> within this hook, as shown in the + example above. + </para> + + <para> + An example of a <literal>shmem_request_hook</literal> and + <literal>shmem_startup_hook</literal> can be found in + <filename>contrib/pg_stat_statements/pg_stat_statements.c</filename> in + the <productname>PostgreSQL</productname> source tree. + </para> + </sect3> + </sect2> + + <sect2 id="xfunc-addin-lwlocks"> + <title>LWLocks</title> + + <sect3 id="xfunc-addin-lwlocks-at-startup"> + <title>Requesting LWLocks at Startup</title> + + <para> + Add-ins can reserve LWLocks on server startup. Like with shared memory, + the add-in's shared library must be preloaded by specifying it in + <xref linkend="guc-shared-preload-libraries"/><indexterm><primary>shared_preload_libraries</primary></indexterm>, + and the shared library should register a + <literal>shmem_request_hook</literal> in its + <function>_PG_init</function> function. This + <literal>shmem_request_hook</literal> can reserve LWLocks by calling: <programlisting> void RequestNamedLWLockTranche(const char *tranche_name, int num_lwlocks) </programlisting> - from your <literal>shmem_request_hook</literal>. This will ensure that an array of - <literal>num_lwlocks</literal> LWLocks is available under the name - <literal>tranche_name</literal>. Use <function>GetNamedLWLockTranche</function> - to get a pointer to this array. - </para> - <para> - An example of a <literal>shmem_request_hook</literal> can be found in - <filename>contrib/pg_stat_statements/pg_stat_statements.c</filename> in the - <productname>PostgreSQL</productname> source tree. - </para> - <para> - There is another, more flexible method of obtaining LWLocks. First, - allocate a <literal>tranche_id</literal> from a shared counter by - calling: + This ensures that an array of <literal>num_lwlocks</literal> LWLocks is + available under the name <literal>tranche_name</literal>. A pointer to + this array can be obtained by calling: <programlisting> -int LWLockNewTrancheId(void) +LWLockPadded *GetNamedLWLockTranche(const char *tranche_name) </programlisting> - Next, each individual process using the <literal>tranche_id</literal> - should associate it with a <literal>tranche_name</literal> by calling: + </para> + </sect3> + + <sect3 id="xfunc-addin-lwlocks-after-startup"> + <title>Requesting LWLocks After Startup</title> + + <para> + There is another, more flexible method of obtaining LWLocks that can be + done after server startup and outside a + <literal>shmem_request_hook</literal>. To do so, first allocate a + <literal>tranche_id</literal> by calling: <programlisting> -void LWLockRegisterTranche(int tranche_id, const char *tranche_name) +int LWLockNewTrancheId(void) </programlisting> - It is also required to call <function>LWLockInitialize</function> once - per LWLock, passing the <literal>tranche_id</literal> as argument: + Next, initialize each LWLock, passing the new + <literal>tranche_id</literal> as an argument: <programlisting> void LWLockInitialize(LWLock *lock, int tranche_id) </programlisting> - A complete usage example of <function>LWLockNewTrancheId</function>, - <function>LWLockInitialize</function> and - <function>LWLockRegisterTranche</function> can be found in - <filename>contrib/pg_prewarm/autoprewarm.c</filename> in the - <productname>PostgreSQL</productname> source tree. - </para> - <para> - To avoid possible race-conditions, each backend should use the LWLock - <function>AddinShmemInitLock</function> when connecting to and initializing - its allocation of shared memory, as shown here: -<programlisting> -static mystruct *ptr = NULL; + Similar to shared memory, each backend should ensure that only one + process allocates a new <literal>tranche_id</literal> and initializes + each new LWLock. One way to do this is to only call these functions in + your shared memory initialization code with the + <function>AddinShmemInitLock</function> held exclusively. + </para> -if (!ptr) -{ - bool found; - - LWLockAcquire(AddinShmemInitLock, LW_EXCLUSIVE); - ptr = ShmemInitStruct("my struct name", size, &found); - if (!found) - { - initialize contents of shmem area; - acquire any requested LWLocks using: - ptr->locks = GetNamedLWLockTranche("my tranche name"); - } - LWLockRelease(AddinShmemInitLock); -} + <para> + Finally, each backend using the <literal>tranche_id</literal> should + associate it with a <literal>tranche_name</literal> by calling: +<programlisting> +void LWLockRegisterTranche(int tranche_id, const char *tranche_name) </programlisting> - </para> - <para> - It is convenient to use <literal>shmem_startup_hook</literal> which allows - placing all the code responsible for initializing shared memory in one - place. When using <literal>shmem_startup_hook</literal> the extension - still needs to acquire <function>AddinShmemInitLock</function> in order to - work properly on all the supported platforms. - </para> + </para> + + <para> + A complete usage example of <function>LWLockNewTrancheId</function>, + <function>LWLockInitialize</function>, and + <function>LWLockRegisterTranche</function> can be found in + <filename>contrib/pg_prewarm/autoprewarm.c</filename> in the + <productname>PostgreSQL</productname> source tree. + </para> + </sect3> </sect2> <sect2 id="xfunc-addin-wait-events"> -- 2.25.1 ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: reorganize "Shared Memory and LWLocks" section of docs @ 2024-01-13 10:49 Aleksander Alekseev <[email protected]> parent: Nathan Bossart <[email protected]> 0 siblings, 1 reply; 11+ messages in thread From: Aleksander Alekseev @ 2024-01-13 10:49 UTC (permalink / raw) To: pgsql-hackers; +Cc: Nathan Bossart <[email protected]> Hi, Thanks for the updated patch. > > I see what you mean, but I don't think the problem is the word "each." I > > think the problem is the use of passive voice. What do you think about > > something like > > > > Each backend will execute the registered shmem_startup_hook shortly > > after it attaches to shared memory. That's much better, thanks. I think the patch could use another pair of eyes, ideally from a native English speaker. But if no one will express any objections for a while I suggest merging it. -- Best regards, Aleksander Alekseev ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: reorganize "Shared Memory and LWLocks" section of docs @ 2024-01-13 21:28 Nathan Bossart <[email protected]> parent: Aleksander Alekseev <[email protected]> 0 siblings, 1 reply; 11+ messages in thread From: Nathan Bossart @ 2024-01-13 21:28 UTC (permalink / raw) To: Aleksander Alekseev <[email protected]>; +Cc: pgsql-hackers On Sat, Jan 13, 2024 at 01:49:08PM +0300, Aleksander Alekseev wrote: > That's much better, thanks. > > I think the patch could use another pair of eyes, ideally from a > native English speaker. But if no one will express any objections for > a while I suggest merging it. Great. I've attached a v3 with a couple of fixes suggested in the other thread [0]. I'll wait a little while longer in case anyone else wants to take a look. [0] https://postgr.es/m/ZaF6UpYImGqVIhVp%40toroid.org -- Nathan Bossart Amazon Web Services: https://aws.amazon.com Attachments: [text/x-diff] v3-0001-reorganize-shared-memory-and-lwlocks-documentatio.patch (9.3K, ../../20240113212815.GA4065002@nathanxps13/2-v3-0001-reorganize-shared-memory-and-lwlocks-documentatio.patch) download | inline diff: From b56931edc4488a7376b27ba0e5519cc3a61b4899 Mon Sep 17 00:00:00 2001 From: Nathan Bossart <[email protected]> Date: Thu, 11 Jan 2024 21:55:25 -0600 Subject: [PATCH v3 1/1] reorganize shared memory and lwlocks documentation --- doc/src/sgml/xfunc.sgml | 182 +++++++++++++++++++++++++--------------- 1 file changed, 114 insertions(+), 68 deletions(-) diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index 89116ae74c..82e1dadcca 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -3397,90 +3397,136 @@ CREATE FUNCTION make_array(anyelement) RETURNS anyarray </sect2> <sect2 id="xfunc-shared-addin"> - <title>Shared Memory and LWLocks</title> + <title>Shared Memory</title> - <para> - Add-ins can reserve LWLocks and an allocation of shared memory on server - startup. The add-in's shared library must be preloaded by specifying - it in - <xref linkend="guc-shared-preload-libraries"/><indexterm><primary>shared_preload_libraries</primary></indexterm>. - The shared library should register a <literal>shmem_request_hook</literal> - in its <function>_PG_init</function> function. This - <literal>shmem_request_hook</literal> can reserve LWLocks or shared memory. - Shared memory is reserved by calling: + <sect3 id="xfunc-shared-addin-at-startup"> + <title>Requesting Shared Memory at Startup</title> + + <para> + Add-ins can reserve shared memory on server startup. To do so, the + add-in's shared library must be preloaded by specifying it in + <xref linkend="guc-shared-preload-libraries"/><indexterm><primary>shared_preload_libraries</primary></indexterm>. + The shared library should also register a + <literal>shmem_request_hook</literal> in its + <function>_PG_init</function> function. This + <literal>shmem_request_hook</literal> can reserve shared memory by + calling: <programlisting> void RequestAddinShmemSpace(int size) </programlisting> - from your <literal>shmem_request_hook</literal>. - </para> - <para> - LWLocks are reserved by calling: + Each backend should obtain a pointer to the reserved shared memory by + calling: +<programlisting> +void *ShmemInitStruct(const char *name, Size size, bool *foundPtr) +</programlisting> + If this function sets <literal>foundPtr</literal> to + <literal>false</literal>, the caller should proceed to initialize the + contents of the reserved shared memory. If <literal>foundPtr</literal> + is set to <literal>true</literal>, the shared memory was already + initialized by another backend, and the caller need not initialize + further. + </para> + + <para> + To avoid race conditions, each backend should use the LWLock + <function>AddinShmemInitLock</function> when initializing its allocation + of shared memory, as shown here: +<programlisting> +static mystruct *ptr = NULL; +bool found; + +LWLockAcquire(AddinShmemInitLock, LW_EXCLUSIVE); +ptr = ShmemInitStruct("my struct name", size, &found); +if (!found) +{ + ... initialize contents of shared memory ... + ptr->locks = GetNamedLWLockTranche("my tranche name"); +} +LWLockRelease(AddinShmemInitLock); +</programlisting> + <literal>shmem_startup_hook</literal> provides a convenient place for the + initialization code, but it is not strictly required that all such code + be placed in this hook. Each backend will execute the registered + <literal>shmem_startup_hook</literal> shortly after it attaches to shared + memory. Note that add-ins should still acquire + <function>AddinShmemInitLock</function> within this hook, as shown in the + example above. + </para> + + <para> + An example of a <literal>shmem_request_hook</literal> and + <literal>shmem_startup_hook</literal> can be found in + <filename>contrib/pg_stat_statements/pg_stat_statements.c</filename> in + the <productname>PostgreSQL</productname> source tree. + </para> + </sect3> + </sect2> + + <sect2 id="xfunc-addin-lwlocks"> + <title>LWLocks</title> + + <sect3 id="xfunc-addin-lwlocks-at-startup"> + <title>Requesting LWLocks at Startup</title> + + <para> + Add-ins can reserve LWLocks on server startup. As with shared memory, + the add-in's shared library must be preloaded by specifying it in + <xref linkend="guc-shared-preload-libraries"/><indexterm><primary>shared_preload_libraries</primary></indexterm>, + and the shared library should register a + <literal>shmem_request_hook</literal> in its + <function>_PG_init</function> function. This + <literal>shmem_request_hook</literal> can reserve LWLocks by calling: <programlisting> void RequestNamedLWLockTranche(const char *tranche_name, int num_lwlocks) </programlisting> - from your <literal>shmem_request_hook</literal>. This will ensure that an array of - <literal>num_lwlocks</literal> LWLocks is available under the name - <literal>tranche_name</literal>. Use <function>GetNamedLWLockTranche</function> - to get a pointer to this array. - </para> - <para> - An example of a <literal>shmem_request_hook</literal> can be found in - <filename>contrib/pg_stat_statements/pg_stat_statements.c</filename> in the - <productname>PostgreSQL</productname> source tree. - </para> - <para> - There is another, more flexible method of obtaining LWLocks. First, - allocate a <literal>tranche_id</literal> from a shared counter by - calling: + This ensures that an array of <literal>num_lwlocks</literal> LWLocks is + available under the name <literal>tranche_name</literal>. A pointer to + this array can be obtained by calling: <programlisting> -int LWLockNewTrancheId(void) +LWLockPadded *GetNamedLWLockTranche(const char *tranche_name) </programlisting> - Next, each individual process using the <literal>tranche_id</literal> - should associate it with a <literal>tranche_name</literal> by calling: + </para> + </sect3> + + <sect3 id="xfunc-addin-lwlocks-after-startup"> + <title>Requesting LWLocks After Startup</title> + + <para> + There is another, more flexible method of obtaining LWLocks that can be + done after server startup and outside a + <literal>shmem_request_hook</literal>. To do so, first allocate a + <literal>tranche_id</literal> by calling: <programlisting> -void LWLockRegisterTranche(int tranche_id, const char *tranche_name) +int LWLockNewTrancheId(void) </programlisting> - It is also required to call <function>LWLockInitialize</function> once - per LWLock, passing the <literal>tranche_id</literal> as argument: + Next, initialize each LWLock, passing the new + <literal>tranche_id</literal> as an argument: <programlisting> void LWLockInitialize(LWLock *lock, int tranche_id) </programlisting> - A complete usage example of <function>LWLockNewTrancheId</function>, - <function>LWLockInitialize</function> and - <function>LWLockRegisterTranche</function> can be found in - <filename>contrib/pg_prewarm/autoprewarm.c</filename> in the - <productname>PostgreSQL</productname> source tree. - </para> - <para> - To avoid possible race-conditions, each backend should use the LWLock - <function>AddinShmemInitLock</function> when connecting to and initializing - its allocation of shared memory, as shown here: -<programlisting> -static mystruct *ptr = NULL; + Similar to shared memory, each backend should ensure that only one + process allocates a new <literal>tranche_id</literal> and initializes + each new LWLock. One way to do this is to only call these functions in + your shared memory initialization code with the + <function>AddinShmemInitLock</function> held exclusively. + </para> -if (!ptr) -{ - bool found; - - LWLockAcquire(AddinShmemInitLock, LW_EXCLUSIVE); - ptr = ShmemInitStruct("my struct name", size, &found); - if (!found) - { - initialize contents of shmem area; - acquire any requested LWLocks using: - ptr->locks = GetNamedLWLockTranche("my tranche name"); - } - LWLockRelease(AddinShmemInitLock); -} + <para> + Finally, each backend using the <literal>tranche_id</literal> should + associate it with a <literal>tranche_name</literal> by calling: +<programlisting> +void LWLockRegisterTranche(int tranche_id, const char *tranche_name) </programlisting> - </para> - <para> - It is convenient to use <literal>shmem_startup_hook</literal> which allows - placing all the code responsible for initializing shared memory in one - place. When using <literal>shmem_startup_hook</literal> the extension - still needs to acquire <function>AddinShmemInitLock</function> in order to - work properly on all the supported platforms. - </para> + </para> + + <para> + A complete usage example of <function>LWLockNewTrancheId</function>, + <function>LWLockInitialize</function>, and + <function>LWLockRegisterTranche</function> can be found in + <filename>contrib/pg_prewarm/autoprewarm.c</filename> in the + <productname>PostgreSQL</productname> source tree. + </para> + </sect3> </sect2> <sect2 id="xfunc-addin-wait-events"> -- 2.25.1 ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: reorganize "Shared Memory and LWLocks" section of docs @ 2024-01-16 04:32 Bharath Rupireddy <[email protected]> parent: Nathan Bossart <[email protected]> 0 siblings, 1 reply; 11+ messages in thread From: Bharath Rupireddy @ 2024-01-16 04:32 UTC (permalink / raw) To: Nathan Bossart <[email protected]>; +Cc: Aleksander Alekseev <[email protected]>; pgsql-hackers On Sun, Jan 14, 2024 at 2:58 AM Nathan Bossart <[email protected]> wrote: > > Great. I've attached a v3 with a couple of fixes suggested in the other > thread [0]. I'll wait a little while longer in case anyone else wants to > take a look. The v3 patch looks good to me except for a nitpick: the input parameter for RequestAddinShmemSpace is 'Size' not 'int' <programlisting> void RequestAddinShmemSpace(int size) </programlisting> -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: reorganize "Shared Memory and LWLocks" section of docs @ 2024-01-16 14:20 Nathan Bossart <[email protected]> parent: Bharath Rupireddy <[email protected]> 0 siblings, 1 reply; 11+ messages in thread From: Nathan Bossart @ 2024-01-16 14:20 UTC (permalink / raw) To: Bharath Rupireddy <[email protected]>; +Cc: Aleksander Alekseev <[email protected]>; pgsql-hackers On Tue, Jan 16, 2024 at 10:02:15AM +0530, Bharath Rupireddy wrote: > The v3 patch looks good to me except for a nitpick: the input > parameter for RequestAddinShmemSpace is 'Size' not 'int' > > <programlisting> > void RequestAddinShmemSpace(int size) > </programlisting> Hah, I think this mistake is nearly old enough to vote (e0dece1, 5f78aa5). Good catch. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: reorganize "Shared Memory and LWLocks" section of docs @ 2024-01-16 15:52 Nathan Bossart <[email protected]> parent: Nathan Bossart <[email protected]> 0 siblings, 1 reply; 11+ messages in thread From: Nathan Bossart @ 2024-01-16 15:52 UTC (permalink / raw) To: Bharath Rupireddy <[email protected]>; +Cc: Aleksander Alekseev <[email protected]>; pgsql-hackers On Tue, Jan 16, 2024 at 08:20:19AM -0600, Nathan Bossart wrote: > On Tue, Jan 16, 2024 at 10:02:15AM +0530, Bharath Rupireddy wrote: >> The v3 patch looks good to me except for a nitpick: the input >> parameter for RequestAddinShmemSpace is 'Size' not 'int' >> >> <programlisting> >> void RequestAddinShmemSpace(int size) >> </programlisting> > > Hah, I think this mistake is nearly old enough to vote (e0dece1, 5f78aa5). > Good catch. I fixed this in v4. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com Attachments: [text/x-diff] v4-0001-reorganize-shared-memory-and-lwlocks-documentatio.patch (9.3K, ../../20240116155252.GA100542@nathanxps13/2-v4-0001-reorganize-shared-memory-and-lwlocks-documentatio.patch) download | inline diff: From 402eaf87776fb6a9d212da66947f47c63bd53f2a Mon Sep 17 00:00:00 2001 From: Nathan Bossart <[email protected]> Date: Thu, 11 Jan 2024 21:55:25 -0600 Subject: [PATCH v4 1/1] reorganize shared memory and lwlocks documentation --- doc/src/sgml/xfunc.sgml | 184 +++++++++++++++++++++++++--------------- 1 file changed, 115 insertions(+), 69 deletions(-) diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index 89116ae74c..ede2a5dea6 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -3397,90 +3397,136 @@ CREATE FUNCTION make_array(anyelement) RETURNS anyarray </sect2> <sect2 id="xfunc-shared-addin"> - <title>Shared Memory and LWLocks</title> + <title>Shared Memory</title> - <para> - Add-ins can reserve LWLocks and an allocation of shared memory on server - startup. The add-in's shared library must be preloaded by specifying - it in - <xref linkend="guc-shared-preload-libraries"/><indexterm><primary>shared_preload_libraries</primary></indexterm>. - The shared library should register a <literal>shmem_request_hook</literal> - in its <function>_PG_init</function> function. This - <literal>shmem_request_hook</literal> can reserve LWLocks or shared memory. - Shared memory is reserved by calling: + <sect3 id="xfunc-shared-addin-at-startup"> + <title>Requesting Shared Memory at Startup</title> + + <para> + Add-ins can reserve shared memory on server startup. To do so, the + add-in's shared library must be preloaded by specifying it in + <xref linkend="guc-shared-preload-libraries"/><indexterm><primary>shared_preload_libraries</primary></indexterm>. + The shared library should also register a + <literal>shmem_request_hook</literal> in its + <function>_PG_init</function> function. This + <literal>shmem_request_hook</literal> can reserve shared memory by + calling: <programlisting> -void RequestAddinShmemSpace(int size) +void RequestAddinShmemSpace(Size size) </programlisting> - from your <literal>shmem_request_hook</literal>. - </para> - <para> - LWLocks are reserved by calling: + Each backend should obtain a pointer to the reserved shared memory by + calling: +<programlisting> +void *ShmemInitStruct(const char *name, Size size, bool *foundPtr) +</programlisting> + If this function sets <literal>foundPtr</literal> to + <literal>false</literal>, the caller should proceed to initialize the + contents of the reserved shared memory. If <literal>foundPtr</literal> + is set to <literal>true</literal>, the shared memory was already + initialized by another backend, and the caller need not initialize + further. + </para> + + <para> + To avoid race conditions, each backend should use the LWLock + <function>AddinShmemInitLock</function> when initializing its allocation + of shared memory, as shown here: +<programlisting> +static mystruct *ptr = NULL; +bool found; + +LWLockAcquire(AddinShmemInitLock, LW_EXCLUSIVE); +ptr = ShmemInitStruct("my struct name", size, &found); +if (!found) +{ + ... initialize contents of shared memory ... + ptr->locks = GetNamedLWLockTranche("my tranche name"); +} +LWLockRelease(AddinShmemInitLock); +</programlisting> + <literal>shmem_startup_hook</literal> provides a convenient place for the + initialization code, but it is not strictly required that all such code + be placed in this hook. Each backend will execute the registered + <literal>shmem_startup_hook</literal> shortly after it attaches to shared + memory. Note that add-ins should still acquire + <function>AddinShmemInitLock</function> within this hook, as shown in the + example above. + </para> + + <para> + An example of a <literal>shmem_request_hook</literal> and + <literal>shmem_startup_hook</literal> can be found in + <filename>contrib/pg_stat_statements/pg_stat_statements.c</filename> in + the <productname>PostgreSQL</productname> source tree. + </para> + </sect3> + </sect2> + + <sect2 id="xfunc-addin-lwlocks"> + <title>LWLocks</title> + + <sect3 id="xfunc-addin-lwlocks-at-startup"> + <title>Requesting LWLocks at Startup</title> + + <para> + Add-ins can reserve LWLocks on server startup. As with shared memory, + the add-in's shared library must be preloaded by specifying it in + <xref linkend="guc-shared-preload-libraries"/><indexterm><primary>shared_preload_libraries</primary></indexterm>, + and the shared library should register a + <literal>shmem_request_hook</literal> in its + <function>_PG_init</function> function. This + <literal>shmem_request_hook</literal> can reserve LWLocks by calling: <programlisting> void RequestNamedLWLockTranche(const char *tranche_name, int num_lwlocks) </programlisting> - from your <literal>shmem_request_hook</literal>. This will ensure that an array of - <literal>num_lwlocks</literal> LWLocks is available under the name - <literal>tranche_name</literal>. Use <function>GetNamedLWLockTranche</function> - to get a pointer to this array. - </para> - <para> - An example of a <literal>shmem_request_hook</literal> can be found in - <filename>contrib/pg_stat_statements/pg_stat_statements.c</filename> in the - <productname>PostgreSQL</productname> source tree. - </para> - <para> - There is another, more flexible method of obtaining LWLocks. First, - allocate a <literal>tranche_id</literal> from a shared counter by - calling: + This ensures that an array of <literal>num_lwlocks</literal> LWLocks is + available under the name <literal>tranche_name</literal>. A pointer to + this array can be obtained by calling: <programlisting> -int LWLockNewTrancheId(void) +LWLockPadded *GetNamedLWLockTranche(const char *tranche_name) </programlisting> - Next, each individual process using the <literal>tranche_id</literal> - should associate it with a <literal>tranche_name</literal> by calling: + </para> + </sect3> + + <sect3 id="xfunc-addin-lwlocks-after-startup"> + <title>Requesting LWLocks After Startup</title> + + <para> + There is another, more flexible method of obtaining LWLocks that can be + done after server startup and outside a + <literal>shmem_request_hook</literal>. To do so, first allocate a + <literal>tranche_id</literal> by calling: <programlisting> -void LWLockRegisterTranche(int tranche_id, const char *tranche_name) +int LWLockNewTrancheId(void) </programlisting> - It is also required to call <function>LWLockInitialize</function> once - per LWLock, passing the <literal>tranche_id</literal> as argument: + Next, initialize each LWLock, passing the new + <literal>tranche_id</literal> as an argument: <programlisting> void LWLockInitialize(LWLock *lock, int tranche_id) </programlisting> - A complete usage example of <function>LWLockNewTrancheId</function>, - <function>LWLockInitialize</function> and - <function>LWLockRegisterTranche</function> can be found in - <filename>contrib/pg_prewarm/autoprewarm.c</filename> in the - <productname>PostgreSQL</productname> source tree. - </para> - <para> - To avoid possible race-conditions, each backend should use the LWLock - <function>AddinShmemInitLock</function> when connecting to and initializing - its allocation of shared memory, as shown here: -<programlisting> -static mystruct *ptr = NULL; + Similar to shared memory, each backend should ensure that only one + process allocates a new <literal>tranche_id</literal> and initializes + each new LWLock. One way to do this is to only call these functions in + your shared memory initialization code with the + <function>AddinShmemInitLock</function> held exclusively. + </para> -if (!ptr) -{ - bool found; - - LWLockAcquire(AddinShmemInitLock, LW_EXCLUSIVE); - ptr = ShmemInitStruct("my struct name", size, &found); - if (!found) - { - initialize contents of shmem area; - acquire any requested LWLocks using: - ptr->locks = GetNamedLWLockTranche("my tranche name"); - } - LWLockRelease(AddinShmemInitLock); -} + <para> + Finally, each backend using the <literal>tranche_id</literal> should + associate it with a <literal>tranche_name</literal> by calling: +<programlisting> +void LWLockRegisterTranche(int tranche_id, const char *tranche_name) </programlisting> - </para> - <para> - It is convenient to use <literal>shmem_startup_hook</literal> which allows - placing all the code responsible for initializing shared memory in one - place. When using <literal>shmem_startup_hook</literal> the extension - still needs to acquire <function>AddinShmemInitLock</function> in order to - work properly on all the supported platforms. - </para> + </para> + + <para> + A complete usage example of <function>LWLockNewTrancheId</function>, + <function>LWLockInitialize</function>, and + <function>LWLockRegisterTranche</function> can be found in + <filename>contrib/pg_prewarm/autoprewarm.c</filename> in the + <productname>PostgreSQL</productname> source tree. + </para> + </sect3> </sect2> <sect2 id="xfunc-addin-wait-events"> -- 2.25.1 ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: reorganize "Shared Memory and LWLocks" section of docs @ 2024-01-17 01:18 Bharath Rupireddy <[email protected]> parent: Nathan Bossart <[email protected]> 0 siblings, 1 reply; 11+ messages in thread From: Bharath Rupireddy @ 2024-01-17 01:18 UTC (permalink / raw) To: Nathan Bossart <[email protected]>; +Cc: Aleksander Alekseev <[email protected]>; pgsql-hackers On Tue, Jan 16, 2024 at 9:22 PM Nathan Bossart <[email protected]> wrote: > > I fixed this in v4. LGTM. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: reorganize "Shared Memory and LWLocks" section of docs @ 2024-01-19 17:22 Nathan Bossart <[email protected]> parent: Bharath Rupireddy <[email protected]> 0 siblings, 0 replies; 11+ messages in thread From: Nathan Bossart @ 2024-01-19 17:22 UTC (permalink / raw) To: Bharath Rupireddy <[email protected]>; +Cc: Aleksander Alekseev <[email protected]>; pgsql-hackers On Wed, Jan 17, 2024 at 06:48:37AM +0530, Bharath Rupireddy wrote: > LGTM. Committed. Thanks for reviewing! -- Nathan Bossart Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2024-01-19 17:22 UTC | newest] Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-03-15 14:20 [PATCH] cfe-12-gist_over_cfe-11-persistent squash commit Bruce Momjian <[email protected]> 2024-01-12 14:12 Re: reorganize "Shared Memory and LWLocks" section of docs Aleksander Alekseev <[email protected]> 2024-01-12 15:46 ` Re: reorganize "Shared Memory and LWLocks" section of docs Nathan Bossart <[email protected]> 2024-01-12 17:23 ` Re: reorganize "Shared Memory and LWLocks" section of docs Nathan Bossart <[email protected]> 2024-01-13 10:49 ` Re: reorganize "Shared Memory and LWLocks" section of docs Aleksander Alekseev <[email protected]> 2024-01-13 21:28 ` Re: reorganize "Shared Memory and LWLocks" section of docs Nathan Bossart <[email protected]> 2024-01-16 04:32 ` Re: reorganize "Shared Memory and LWLocks" section of docs Bharath Rupireddy <[email protected]> 2024-01-16 14:20 ` Re: reorganize "Shared Memory and LWLocks" section of docs Nathan Bossart <[email protected]> 2024-01-16 15:52 ` Re: reorganize "Shared Memory and LWLocks" section of docs Nathan Bossart <[email protected]> 2024-01-17 01:18 ` Re: reorganize "Shared Memory and LWLocks" section of docs Bharath Rupireddy <[email protected]> 2024-01-19 17:22 ` Re: reorganize "Shared Memory and LWLocks" section of docs Nathan Bossart <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox