|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||David Rowley <dgrowleyml(at)gmail(dot)com>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Reducing the chunk header sizes on all memory context types|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Fri, 7 Oct 2022 at 12:35, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Which leaves me with the attached proposed wording.
> No objections here.
Cool, I'll push in a little bit.
> With these comments I'd be using slot MCTX_UNUSED4_ID first, then I'd
> probably be looking at MCTX_UNUSED5_ID after adjusting wipe_mem to do
> something other than setting bytes to 0x7F.
Well, the only way that you could free up a bitpattern that way is
to make wipe_mem use something ending in 000 or 001. I'd be against
using 000 because then wiped memory might appear to contain valid
(aligned) pointers. But perhaps 001 would be ok.
> I'd then use
> MCTX_UNUSED3_ID since that pattern is only used for larger chunks with
> glibc (per your findings). After that, I'd probably start looking
> into making more than 3 bits available. If that wasn't possible, I'd
> be using MCTX_UNUSED2_ID and at last resort MCTX_UNUSED1_ID.
If we get to having three-quarters or seven-eighths of the bitpatterns
being valid IDs, we'll have precious little ability to detect garbage.
So personally I'd put "find a fourth bit" higher on the priority list.
In any case, we needn't invest more effort here until someone comes
with a fifth context method ... and I don't recall hearing discussions
of even a fourth one yet.
regards, tom lane
|Next Message||Виктория Шепард||2022-10-07 01:01:24||Re: Possible solution for masking chosen columns when using pg_dump|
|Previous Message||David Rowley||2022-10-07 00:50:11||Re: Reducing the chunk header sizes on all memory context types|