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
signature.asc
Description
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
I wrote:
> Alexander Lakhin 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
On 2020-04-19 09:37:08 -0400, Tom Lane wrote:
> Peter Eisentraut 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
Alexander Lakhin 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
Peter Eisentraut 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.
On 2020-04-21 20:27, Tom Lane wrote:
Peter Eisentraut 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
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-
Peter Eisentraut 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
On 2020-04-19 15:37, Tom Lane wrote:
Peter Eisentraut 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 HEAPAMSLOTDEBUGA
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 ‘GenerationAl
Hello hackers,
19.04.2020 13:37, Tom Lane wrote:
>
> Peter Eisentraut 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 a
Peter Eisentraut 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 co
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 t
14 matches
Mail list logo
