Re: pgsql: Generational memory allocator

Tomas Vondra writes: > BTW I also see these failures in hstore: > ==15168== Source and destination overlap in memcpy(0x5d0fed0, 0x5d0fed0, 40) > ==15168==at 0x4C2E00C: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018) > ==15168==by 0x15419A06: hstoreUniquePairs (hstore_io.c:343) > ==15168==

Re: pgsql: Generational memory allocator

Hi, On 11/25/2017 02:25 AM, Tom Lane wrote: I wrote: For me, this patch fixes the valgrind failures inside generation.c itself, but I still see one more in the test_decoding run: ... Not sure what to make of this: the stack traces make it look unrelated to the GenerationContext changes, but if

Re: pgsql: Generational memory allocator

I wrote: > For me, this patch fixes the valgrind failures inside generation.c > itself, but I still see one more in the test_decoding run: ... > Not sure what to make of this: the stack traces make it look unrelated > to the GenerationContext changes, but if it's not related, how come > skink was p

pgsql: Improve valgrind logic in aset.c, and fix multiple issues in gen

Improve valgrind logic in aset.c, and fix multiple issues in generation.c. Revise aset.c so that all the "private" fields of chunk headers are marked NOACCESS when outside the module, improving on the previous coding which protected only requested_size. Fix a couple of corner case bugs, such as f

pgsql: Mostly-cosmetic improvements in memory chunk header alignment co

Mostly-cosmetic improvements in memory chunk header alignment coding. Add commentary about what we're doing and why. Apply the method used for padding in GenerationChunk to AllocChunkData, replacing the rather ad-hoc solution used in commit 7e3aa03b4. Reorder fields in GenerationChunk so that th

Re: pgsql: Generational memory allocator

I wrote: > Tomas Vondra writes: >> Thanks. Do we need to do something similar to the other memory contexts? >> I see Slab does not do this at all (assuming it's not necessary), and >> AllocSet does this in a different way (which seems a bit strange). > Hm ... the coding in AllocSet is ancient a

pgsql: Fix bug in generation.c's valgrind support.

Fix bug in generation.c's valgrind support. This doesn't look like the last such bug, but it's one that the test_decoding regression test is tripping over. Per buildfarm. Tomas Vondra Discussion: https://postgr.es/m/c903f275-2150-fa52-64bf-dca7b53eb...@fuzzy.cz Branch -- master Details --

Re: pgsql: Generational memory allocator

Tomas Vondra writes: > I agree it would be useful to get the valgrind log from the animal, but > I guess you'd need to get valgrind working to fix the issue anyway. > Anyway, the attached patch fixes the issues for me - strictly speaking > the Assert is not needed, but it doesn't hurt. For me,

Re: pgsql: Generational memory allocator

On 11/23/2017 03:06 PM, Tom Lane wrote: > > I think it's a legitimate complaint that postmaster.log wasn't captured > in this failure, but that's a buildfarm script oversight and hardly > Andres' fault. > A fix for this will be in the next buildfarm release. cheers andrew -- Andrew Dunstan

Re: pgsql: Generational memory allocator

On 24 November 2017 at 09:04, Tom Lane wrote: > Andres Freund writes: >> On 2017-11-23 22:34:57 +0100, Tomas Vondra wrote: >>> Hmmm, I see. Presumably adding this to GenerationChunk (similarly to what we >>> do in AllocChunkData) would address the issue: >>> >>> #if MAXIMUM_ALIGNOF > 4 && SIZEOF_

pgsql: RLS comment fixes.

RLS comment fixes. The comments in get_policies_for_relation() say that CREATE POLICY does not support defining restrictive policies. This is no longer true, starting from PG10. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9c55391f0f277318c754f89950e65363ede4136e

pgsql: RLS comment fixes.

RLS comment fixes. The comments in get_policies_for_relation() say that CREATE POLICY does not support defining restrictive policies. This is no longer true, starting from PG10. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a1187c4efe024e5a1f5cf9221b13a3f32

pgsql: Fix broken XML in CREATE POLICY sgml.

Fix broken XML in CREATE POLICY sgml. Commit 87c2a17fee failed to close some tags (necessary now that the SGML docs are in fact XML). Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/26329ad8dcc78eb651ab61f6b17c4f5f7bb77323 Modified Files -- doc/src/sgml

pgsql: Doc: add a summary table to the CREATE POLICY docs.

Doc: add a summary table to the CREATE POLICY docs. This table summarizes which RLS policy expressions apply to each command type, and whether they apply to the old or new tuples (or both), which saves reading through a lot of text. Rod Taylor, hacked on by me. Reviewed by Fabien Coelho. Discuss

pgsql: Doc: add a summary table to the CREATE POLICY docs.

Doc: add a summary table to the CREATE POLICY docs. This table summarizes which RLS policy expressions apply to each command type, and whether they apply to the old or new tuples (or both), which saves reading through a lot of text. Rod Taylor, hacked on by me. Reviewed by Fabien Coelho. Discuss

pgsql: Doc: add a summary table to the CREATE POLICY docs.

Doc: add a summary table to the CREATE POLICY docs. This table summarizes which RLS policy expressions apply to each command type, and whether they apply to the old or new tuples (or both), which saves reading through a lot of text. Rod Taylor, hacked on by me. Reviewed by Fabien Coelho. Discuss

pgsql: Doc: add a summary table to the CREATE POLICY docs.

Doc: add a summary table to the CREATE POLICY docs. This table summarizes which RLS policy expressions apply to each command type, and whether they apply to the old or new tuples (or both), which saves reading through a lot of text. Rod Taylor, hacked on by me. Reviewed by Fabien Coelho. Discuss