pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedHEAPDEBUGALL is broken
14+ messages / 5 participants
[nested] [flat]
* HEAPDEBUGALL is broken
@ 2020-04-19 12:50 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 2 replies; 14+ messages in thread
From: Peter Eisentraut @ 2020-04-19 12:50 UTC (permalink / raw)
To: pgsql-hackers
The HEAPDEBUGALL define has been broken since PG12 due to tableam
changes. Should we just remove this? It doesn't look very useful.
It's been around since Postgres95.
If we opt for removing: PG12 added an analogous HEAPAMSLOTDEBUGALL
(which still compiles correctly). Would we want to keep that?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-19 13:37 Tom Lane <tgl@sss.pgh.pa.us>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
1 sibling, 2 replies; 14+ messages in thread
From: Tom Lane @ 2020-04-19 13:37 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> The HEAPDEBUGALL define has been broken since PG12 due to tableam
> changes. Should we just remove this? It doesn't look very useful.
> It's been around since Postgres95.
> If we opt for removing: PG12 added an analogous HEAPAMSLOTDEBUGALL
> (which still compiles correctly). Would we want to keep that?
+1 for removing both. There are a lot of such debug "features"
in the code, and few of them are worth anything IME.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-19 20:00 Alexander Lakhin <exclusion@gmail.com>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
1 sibling, 1 reply; 14+ messages in thread
From: Alexander Lakhin @ 2020-04-19 20:00 UTC (permalink / raw)
To: pgsql-hackers
Hello hackers,
19.04.2020 13:37, Tom Lane wrote:
>
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> The HEAPDEBUGALL define has been broken since PG12 due to tableam
>> changes. Should we just remove this? It doesn't look very useful.
>> It's been around since Postgres95.
>> If we opt for removing: PG12 added an analogous HEAPAMSLOTDEBUGALL
>> (which still compiles correctly). Would we want to keep that?
>
> +1 for removing both. There are a lot of such debug "features"
> in the code, and few of them are worth anything IME.
To the point, I've tried to use HAVE_ALLOCINFO on master today and it
failed too:
$ CPPFLAGS="-DHAVE_ALLOCINFO" ./configure --enable-tap-tests
--enable-debug --enable-cassert >/dev/null && make -j16 >/dev/null
generation.c: In function ‘GenerationAlloc’:
generation.c:191:11: error: ‘GenerationContext {aka struct
GenerationContext}’ has no member named ‘name’
(_cxt)->name, (_chunk), (_chunk)->size)
^
generation.c:386:3: note: in expansion of macro ‘GenerationAllocInfo’
GenerationAllocInfo(set, chunk);
^~~~~~~~~~~~~~~~~~~
generation.c:191:11: error: ‘GenerationContext {aka struct
GenerationContext}’ has no member named ‘name’
(_cxt)->name, (_chunk), (_chunk)->size)
^
generation.c:463:2: note: in expansion of macro ‘GenerationAllocInfo’
GenerationAllocInfo(set, chunk);
^~~~~~~~~~~~~~~~~~~
Best regards,
Alexander
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-21 18:01 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Alexander Lakhin <exclusion@gmail.com>
0 siblings, 1 reply; 14+ messages in thread
From: Peter Eisentraut @ 2020-04-21 18:01 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; pgsql-hackers
On 2020-04-19 22:00, Alexander Lakhin wrote:
> To the point, I've tried to use HAVE_ALLOCINFO on master today and it
> failed too:
> $ CPPFLAGS="-DHAVE_ALLOCINFO" ./configure --enable-tap-tests
> --enable-debug --enable-cassert >/dev/null && make -j16 >/dev/null
> generation.c: In function ‘GenerationAlloc’:
> generation.c:191:11: error: ‘GenerationContext {aka struct
> GenerationContext}’ has no member named ‘name’
> (_cxt)->name, (_chunk), (_chunk)->size)
> ^
> generation.c:386:3: note: in expansion of macro ‘GenerationAllocInfo’
> GenerationAllocInfo(set, chunk);
> ^~~~~~~~~~~~~~~~~~~
> generation.c:191:11: error: ‘GenerationContext {aka struct
> GenerationContext}’ has no member named ‘name’
> (_cxt)->name, (_chunk), (_chunk)->size)
> ^
> generation.c:463:2: note: in expansion of macro ‘GenerationAllocInfo’
> GenerationAllocInfo(set, chunk);
> ^~~~~~~~~~~~~~~~~~~
Do you have a proposed patch?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-21 18:11 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 14+ messages in thread
From: Peter Eisentraut @ 2020-04-21 18:11 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
On 2020-04-19 15:37, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> The HEAPDEBUGALL define has been broken since PG12 due to tableam
>> changes. Should we just remove this? It doesn't look very useful.
>> It's been around since Postgres95.
>> If we opt for removing: PG12 added an analogous HEAPAMSLOTDEBUGALL
>> (which still compiles correctly). Would we want to keep that?
>
> +1 for removing both. There are a lot of such debug "features"
> in the code, and few of them are worth anything IME.
removed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-21 18:27 Tom Lane <tgl@sss.pgh.pa.us>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 14+ messages in thread
From: Tom Lane @ 2020-04-21 18:27 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-04-19 15:37, Tom Lane wrote:
>> +1 for removing both. There are a lot of such debug "features"
>> in the code, and few of them are worth anything IME.
> removed
I don't see a commit?
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-22 04:00 Alexander Lakhin <exclusion@gmail.com>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 14+ messages in thread
From: Alexander Lakhin @ 2020-04-22 04:00 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
21.04.2020 21:01, Peter Eisentraut wrote:
> On 2020-04-19 22:00, Alexander Lakhin wrote:
>> To the point, I've tried to use HAVE_ALLOCINFO on master today and it
>> failed too:
>
> Do you have a proposed patch?
>
As this is broken at least since the invention of the generational
allocator (2017-11-23, a4ccc1ce), I believe than no one uses this (and
slab is broken too). Nonetheless, HAVE_ALLOCINFO in aset.c is still
working, so it could be leaved alone, though the output too chatty for
general use (`make check` produces postmaster log of size 3.8GB). I
think someone would still need to insert some extra conditions to use
that or find another way to debug memory allocations.
So I would just remove this debug macro. The proposed patch is attached.
Best regards,
Alexander
Attachments:
[text/x-patch] remove-allocinfo.patch (5.2K, ../../8936216c-3492-3f6e-634b-d638fddc5f91@gmail.com/2-remove-allocinfo.patch)
download | inline diff:
diff --git a/src/backend/utils/mmgr/aset.c b/src/backend/utils/mmgr/aset.c
index c0623f106d2..dd8d7a33a4f 100644
--- a/src/backend/utils/mmgr/aset.c
+++ b/src/backend/utils/mmgr/aset.c
@@ -50,9 +50,6 @@
#include "utils/memdebug.h"
#include "utils/memutils.h"
-/* Define this to detail debug alloc information */
-/* #define HAVE_ALLOCINFO */
-
/*--------------------
* Chunk freelist k holds chunks of size 1 << (k + ALLOC_MINBITS),
* for k = 0 .. ALLOCSET_NUM_FREELISTS-1.
@@ -298,21 +295,6 @@ static const MemoryContextMethods AllocSetMethods = {
#endif
};
-/* ----------
- * Debug macros
- * ----------
- */
-#ifdef HAVE_ALLOCINFO
-#define AllocFreeInfo(_cxt, _chunk) \
- fprintf(stderr, "AllocFree: %s: %p, %zu\n", \
- (_cxt)->header.name, (_chunk), (_chunk)->size)
-#define AllocAllocInfo(_cxt, _chunk) \
- fprintf(stderr, "AllocAlloc: %s: %p, %zu\n", \
- (_cxt)->header.name, (_chunk), (_chunk)->size)
-#else
-#define AllocFreeInfo(_cxt, _chunk)
-#define AllocAllocInfo(_cxt, _chunk)
-#endif
/* ----------
* AllocSetFreeIndex -
@@ -796,8 +778,6 @@ AllocSetAlloc(MemoryContext context, Size size)
set->blocks = block;
}
- AllocAllocInfo(set, chunk);
-
/* Ensure any padding bytes are marked NOACCESS. */
VALGRIND_MAKE_MEM_NOACCESS((char *) AllocChunkGetPointer(chunk) + size,
chunk_size - size);
@@ -835,8 +815,6 @@ AllocSetAlloc(MemoryContext context, Size size)
randomize_mem((char *) AllocChunkGetPointer(chunk), size);
#endif
- AllocAllocInfo(set, chunk);
-
/* Ensure any padding bytes are marked NOACCESS. */
VALGRIND_MAKE_MEM_NOACCESS((char *) AllocChunkGetPointer(chunk) + size,
chunk->size - size);
@@ -996,8 +974,6 @@ AllocSetAlloc(MemoryContext context, Size size)
randomize_mem((char *) AllocChunkGetPointer(chunk), size);
#endif
- AllocAllocInfo(set, chunk);
-
/* Ensure any padding bytes are marked NOACCESS. */
VALGRIND_MAKE_MEM_NOACCESS((char *) AllocChunkGetPointer(chunk) + size,
chunk_size - size);
@@ -1021,8 +997,6 @@ AllocSetFree(MemoryContext context, void *pointer)
/* Allow access to private part of chunk header. */
VALGRIND_MAKE_MEM_DEFINED(chunk, ALLOCCHUNK_PRIVATE_LEN);
- AllocFreeInfo(set, chunk);
-
#ifdef MEMORY_CONTEXT_CHECKING
/* Test for someone scribbling on unused space in chunk */
if (chunk->requested_size < chunk->size)
diff --git a/src/backend/utils/mmgr/generation.c b/src/backend/utils/mmgr/generation.c
index 56651d06931..af52616e575 100644
--- a/src/backend/utils/mmgr/generation.c
+++ b/src/backend/utils/mmgr/generation.c
@@ -178,22 +178,6 @@ static const MemoryContextMethods GenerationMethods = {
#endif
};
-/* ----------
- * Debug macros
- * ----------
- */
-#ifdef HAVE_ALLOCINFO
-#define GenerationFreeInfo(_cxt, _chunk) \
- fprintf(stderr, "GenerationFree: %s: %p, %lu\n", \
- (_cxt)->name, (_chunk), (_chunk)->size)
-#define GenerationAllocInfo(_cxt, _chunk) \
- fprintf(stderr, "GenerationAlloc: %s: %p, %lu\n", \
- (_cxt)->name, (_chunk), (_chunk)->size)
-#else
-#define GenerationFreeInfo(_cxt, _chunk)
-#define GenerationAllocInfo(_cxt, _chunk)
-#endif
-
/*
* Public routines
@@ -383,8 +367,6 @@ GenerationAlloc(MemoryContext context, Size size)
/* add the block to the list of allocated blocks */
dlist_push_head(&set->blocks, &block->node);
- GenerationAllocInfo(set, chunk);
-
/* Ensure any padding bytes are marked NOACCESS. */
VALGRIND_MAKE_MEM_NOACCESS((char *) GenerationChunkGetPointer(chunk) + size,
chunk_size - size);
@@ -460,8 +442,6 @@ GenerationAlloc(MemoryContext context, Size size)
randomize_mem((char *) GenerationChunkGetPointer(chunk), size);
#endif
- GenerationAllocInfo(set, chunk);
-
/* Ensure any padding bytes are marked NOACCESS. */
VALGRIND_MAKE_MEM_NOACCESS((char *) GenerationChunkGetPointer(chunk) + size,
chunk_size - size);
diff --git a/src/backend/utils/mmgr/slab.c b/src/backend/utils/mmgr/slab.c
index c928476c479..e9e962d7674 100644
--- a/src/backend/utils/mmgr/slab.c
+++ b/src/backend/utils/mmgr/slab.c
@@ -157,22 +157,6 @@ static const MemoryContextMethods SlabMethods = {
#endif
};
-/* ----------
- * Debug macros
- * ----------
- */
-#ifdef HAVE_ALLOCINFO
-#define SlabFreeInfo(_cxt, _chunk) \
- fprintf(stderr, "SlabFree: %s: %p, %zu\n", \
- (_cxt)->header.name, (_chunk), (_chunk)->header.size)
-#define SlabAllocInfo(_cxt, _chunk) \
- fprintf(stderr, "SlabAlloc: %s: %p, %zu\n", \
- (_cxt)->header.name, (_chunk), (_chunk)->header.size)
-#else
-#define SlabFreeInfo(_cxt, _chunk)
-#define SlabAllocInfo(_cxt, _chunk)
-#endif
-
/*
* SlabContextCreate
@@ -499,8 +483,6 @@ SlabAlloc(MemoryContext context, Size size)
randomize_mem((char *) SlabChunkGetPointer(chunk), size);
#endif
- SlabAllocInfo(slab, chunk);
-
Assert(slab->nblocks * slab->blockSize == context->mem_allocated);
return SlabChunkGetPointer(chunk);
@@ -518,8 +500,6 @@ SlabFree(MemoryContext context, void *pointer)
SlabChunk *chunk = SlabPointerGetChunk(pointer);
SlabBlock *block = chunk->block;
- SlabFreeInfo(slab, chunk);
-
#ifdef MEMORY_CONTEXT_CHECKING
/* Test for someone scribbling on unused space in chunk */
if (slab->chunkSize < (slab->fullChunkSize - sizeof(SlabChunk)))
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-22 11:29 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 14+ messages in thread
From: Peter Eisentraut @ 2020-04-22 11:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
On 2020-04-21 20:27, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> On 2020-04-19 15:37, Tom Lane wrote:
>>> +1 for removing both. There are a lot of such debug "features"
>>> in the code, and few of them are worth anything IME.
>
>> removed
>
> I don't see a commit?
pushed now
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-22 14:17 Tom Lane <tgl@sss.pgh.pa.us>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 14+ messages in thread
From: Tom Lane @ 2020-04-22 14:17 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-04-21 20:27, Tom Lane wrote:
>> I don't see a commit?
> pushed now
Looking at this, I'm tempted to nuke ACLDEBUG as well, which
is the only remaining undocumented symbol in pg_config_manual.h.
The code it controls looks equally forlorn and not-useful-as-is.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-22 14:19 Tom Lane <tgl@sss.pgh.pa.us>
parent: Alexander Lakhin <exclusion@gmail.com>
0 siblings, 1 reply; 14+ messages in thread
From: Tom Lane @ 2020-04-22 14:19 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
Alexander Lakhin <exclusion@gmail.com> writes:
> 21.04.2020 21:01, Peter Eisentraut wrote:
>> Do you have a proposed patch?
> As this is broken at least since the invention of the generational
> allocator (2017-11-23, a4ccc1ce), I believe than no one uses this (and
> slab is broken too). Nonetheless, HAVE_ALLOCINFO in aset.c is still
> working, so it could be leaved alone, though the output too chatty for
> general use (`make check` produces postmaster log of size 3.8GB). I
> think someone would still need to insert some extra conditions to use
> that or find another way to debug memory allocations.
> So I would just remove this debug macro. The proposed patch is attached.
I didn't review this in close detail, but I think it's a good idea.
We have better memory-use-analysis tools these days, such as valgrind,
so it's no surprise that nobody is using this old code.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-23 03:44 Andres Freund <andres@anarazel.de>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 14+ messages in thread
From: Andres Freund @ 2020-04-23 03:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On 2020-04-19 09:37:08 -0400, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > The HEAPDEBUGALL define has been broken since PG12 due to tableam
> > changes. Should we just remove this? It doesn't look very useful.
> > It's been around since Postgres95.
> > If we opt for removing: PG12 added an analogous HEAPAMSLOTDEBUGALL
> > (which still compiles correctly). Would we want to keep that?
>
> +1 for removing both. There are a lot of such debug "features"
> in the code, and few of them are worth anything IME.
Belatedly: +many
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-23 19:28 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 14+ messages in thread
From: Tom Lane @ 2020-04-23 19:28 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
I wrote:
> Alexander Lakhin <exclusion@gmail.com> writes:
>> So I would just remove this debug macro. The proposed patch is attached.
> I didn't review this in close detail, but I think it's a good idea.
I checked this more closely and pushed it.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-23 19:38 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 14+ messages in thread
From: Tom Lane @ 2020-04-23 19:38 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: pgsql-hackers
I wrote:
> Looking at this, I'm tempted to nuke ACLDEBUG as well, which
> is the only remaining undocumented symbol in pg_config_manual.h.
> The code it controls looks equally forlorn and not-useful-as-is.
Did that, too.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: HEAPDEBUGALL is broken
@ 2020-04-24 07:19 Michael Paquier <michael@paquier.xyz>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 14+ messages in thread
From: Michael Paquier @ 2020-04-24 07:19 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; pgsql-hackers
On Wed, Apr 22, 2020 at 08:44:18PM -0700, Andres Freund wrote:
> On 2020-04-19 09:37:08 -0400, Tom Lane wrote:
>> +1 for removing both. There are a lot of such debug "features"
>> in the code, and few of them are worth anything IME.
>
> Belatedly: +many
+1.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20200424071924.GO33034@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2020-04-24 07:19 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-04-19 12:50 HEAPDEBUGALL is broken Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-04-19 13:37 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-04-21 18:11 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-04-21 18:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-04-22 11:29 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-04-22 14:17 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-04-23 19:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-04-23 03:44 ` Andres Freund <andres@anarazel.de>
2020-04-24 07:19 ` Michael Paquier <michael@paquier.xyz>
2020-04-19 20:00 ` Alexander Lakhin <exclusion@gmail.com>
2020-04-21 18:01 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2020-04-22 04:00 ` Alexander Lakhin <exclusion@gmail.com>
2020-04-22 14:19 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-04-23 19:28 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox