Re: pg_rewind WAL segments deletion pitfall

Hello, Alex. At Fri, 26 Aug 2022 10:57:25 +0200, Alexander Kukushkin wrote in > On Fri, 26 Aug 2022 at 10:04, Kyotaro Horiguchi > wrote: > > What I don't still understand is why pg_rewind doesn't work for the > > old primary in that case. When archive_mode=on, the old primary has > > the

Re: shadow variables - pg15 edition

On Wed, Aug 24, 2022 at 10:47:31PM +1200, David Rowley wrote: > I really think #2s should be done last. I'm not as comfortable with > the renaming and we might want to discuss tactics on that. We could > either opt to rename the shadowed or shadowing variable, or both. If > we rename the

Re: wal_sync_method=fsync_writethrough

On Tue, Aug 30, 2022 at 3:44 AM Magnus Hagander wrote: > On Fri, Aug 26, 2022 at 11:29 PM Thomas Munro wrote: > > Now it looks strange: we have both "fsync" and "fsync_writethrough" > > doing exactly the same thing while vaguely implying otherwise, and the > > contrast with other operating

Re: introduce bufmgr hooks

At Mon, 29 Aug 2022 15:24:49 -0700, Nathan Bossart wrote in > I'd like to propose some new hooks for the buffer manager. My primary goal > is to allow users to create an additional caching mechanism between the ... > The attached patch is a first attempt at introducing these hooks with >

[PATCH v1] [doc] polish the comments of reloptions

When adding an option, we have 5 choices (bool, integer, real, enum, string), so the comments seem stale. There are some sentences missing *at ShareUpdateExclusiveLock*, this patch adds them to make the sentences complete. One thing I'm not sure is should we use *at ShareUpdateExclusiveLock* or

Re: configure openldap crash warning

Hi, On 2022-08-29 23:18:23 -0400, Tom Lane wrote: > Andres Freund writes: > > Why do we continue to link the backend to ldap when we find ldap_r, given > > that > > we know that it can cause problems for extension libraries using libpq? > > Uh ... if we know that, it's news to me. Isn't that

Re: Reducing the chunk header sizes on all memory context types

David Rowley writes: > I can revert df0f4feef, but would prefer just to get the green light > for d5ee4db0e from those 32-bit arm animals before doing so. I have a check-world pass on my RPI3 (Fedora 30 armv7l image). PPC test still running, but I don't doubt it will pass; it's finished

Re: Reducing the chunk header sizes on all memory context types

On Tue, 30 Aug 2022 at 15:15, Tom Lane wrote: > AFAICS that could only happen if "double" has 8-byte alignment > requirement but int64 does not. I recall some discussion about > that possibility a month or two back, but I think we concluded > that we weren't going to support it. ok > I guess

Re: Making Vars outer-join aware

On Mon, Aug 29, 2022 at 2:30 PM Richard Guo wrote: > > On Fri, Aug 19, 2022 at 2:45 AM Tom Lane wrote: > >> Here's a rebase up to HEAD, mainly to get the cfbot back in sync >> as to what's the live patch. > > > Noticed another different behavior from previous. When we try to reduce > JOIN_LEFT

Re: configure openldap crash warning

Andres Freund writes: > Why do we continue to link the backend to ldap when we find ldap_r, given that > we know that it can cause problems for extension libraries using libpq? Uh ... if we know that, it's news to me. I think we might've avoided ldap_r for fear of pulling libpthread into the

Re: Reducing the chunk header sizes on all memory context types

David Rowley writes: > On Tue, 30 Aug 2022 at 03:39, Tom Lane wrote: >> I'd suggest reverting df0f4feef as it seems to be >> a red herring. > I think it's useless providing that a 64-bit variable will always be > aligned to 8 bytes on all of our supported 32-bit platforms as, > without the

Re: configure openldap crash warning

Hi, On 2022-05-06 14:00:43 -0400, Tom Lane wrote: > I wrote: > > Oh, I have a theory about this: I bet your Homebrew installation > > has a recent OpenLDAP version that only supplies libldap not libldap_r. > > In that case, configure will still find libldap_r available and will > > bind libpq to

Re: Reducing the chunk header sizes on all memory context types

On Tue, 30 Aug 2022 at 03:39, Tom Lane wrote: > I'd suggest reverting df0f4feef as it seems to be > a red herring. I think it's useless providing that a 64-bit variable will always be aligned to 8 bytes on all of our supported 32-bit platforms as, without the padding, the uint64 hdrmask in

Re: use ARM intrinsics in pg_lfind32() where available

On Tue, Aug 30, 2022 at 12:17 AM Nathan Bossart wrote: > Thanks! I've attached a follow-up patch with a couple of small > suggestions. Pushed, thanks! -- John Naylor EDB: http://www.enterprisedb.com

Re: Reducing the chunk header sizes on all memory context types

On Tue, 30 Aug 2022 at 13:58, Tomas Vondra wrote: > > On 8/30/22 03:16, David Rowley wrote: > > Any chance you could run make check-world on your 32-bit Raspberry PI? > > > > Will do, but I think the sentinel fix should be Thank you. I think Tom is also running make check-world. I now have an

Re: Postmaster self-deadlock due to PLT linkage resolution

On Mon, Aug 29, 2022 at 03:43:55PM -0400, Tom Lane wrote: > I'd originally intended to make this code "#ifdef __NetBSD__", > but on looking into the FreeBSD sources I find much the same locking > logic in their dynamic loader, and now I'm wondering if such behavior > isn't pretty standard. I

Re: Support logical replication of global object commands

> > I think a publication of ALL OBJECTS sounds intuitive. Does it mean we'll > > publish all DDL commands, all commit and abort operations in every > > database if there is such publication of ALL OBJECTS? > > > > Actually, I intend something for global objects. But the main thing > that is

Re: Reducing the chunk header sizes on all memory context types

On Tue, 30 Aug 2022 at 13:55, Tom Lane wrote: > I wonder if slab ought to artificially bump up such requests when > MEMORY_CONTEXT_CHECKING is enabled, so there's room for a sentinel. > I think it's okay for aset.c to not do that, because its power-of-2 > behavior means there usually is room for

Re: Reducing the chunk header sizes on all memory context types

On Tue, 30 Aug 2022 at 13:58, Tomas Vondra wrote: > armv7l (32-bit rpi4) > > +WARNING: chunkSize 216 fullChunkSize 232 header 16 > +WARNING: chunkSize 64 fullChunkSize 80 header 16 > > aarch64 (64-bit rpi4) > > +WARNING: chunkSize 304 fullChunkSize 320 header 16 > +WARNING: chunkSize 80

RE: Data is copied twice when specifying both child and parent table in publication

On Wednesday, August 10, 2022 7:45 AM Peter Smith wrote: > > Here are some more review comments for the HEAD_v8 patch: > > == > > 1. Commit message > > If there are two publications, one of them publish a parent table with > (publish_via_partition_root = true) and another publish child

Re: replacing role-level NOINHERIT with a grant-level option

On Mon, Aug 29, 2022 at 6:04 PM Nathan Bossart wrote: > On Mon, Aug 29, 2022 at 03:38:57PM -0400, Robert Haas wrote: > > Here is a patch to rearrange the logic slightly and also add a test > > case memorializing the intended behavior. Without this change, the > > regression test included in the

Re: Reducing the chunk header sizes on all memory context types

On 8/30/22 03:55, Tom Lane wrote: > Tomas Vondra writes: >> On 8/30/22 02:45, David Rowley wrote: >>> I think the existing sentinel check looks wrong: >>> if (!sentinel_ok(chunk, slab->chunkSize)) >>> shouldn't that be passing the pointer rather than the chunk? > >> I agree the check in

Re: [PATCH] Add native windows on arm64 support

Michael Paquier writes: > On Mon, Aug 29, 2022 at 05:33:56PM -0700, Andres Freund wrote: >> The weirdest part is that it only happens as part of the the pg_upgrade test. > make check has just failed: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird=2022-08-30%2001%3A15%3A13

Re: Reducing the chunk header sizes on all memory context types

On 8/30/22 03:16, David Rowley wrote: > On Tue, 30 Aug 2022 at 12:45, David Rowley wrote: >> I think the existing sentinel check looks wrong: >> >> if (!sentinel_ok(chunk, slab->chunkSize)) >> >> shouldn't that be passing the pointer rather than the chunk? > > Here's v2 of the slab-fix patch. >

Re: Reducing the chunk header sizes on all memory context types

Tomas Vondra writes: > On 8/30/22 02:45, David Rowley wrote: >> I think the existing sentinel check looks wrong: >> if (!sentinel_ok(chunk, slab->chunkSize)) >> shouldn't that be passing the pointer rather than the chunk? > I agree the check in SlabCheck() looks wrong, as it's ignoring the chunk

Re: Reducing the chunk header sizes on all memory context types

David Rowley writes: > Here's v2 of the slab-fix patch. > I've included the sentinel check fix. This passes make check-world > for me when do a 32-bit build on my x86_64 machine and adjust > pg_config.h to set MAXIMUM_ALIGNOF to 8. > Any chance you could run make check-world on your 32-bit

Re: [PATCH] Add native windows on arm64 support

On Mon, Aug 29, 2022 at 05:33:56PM -0700, Andres Freund wrote: > The weirdest part is that it only happens as part of the the pg_upgrade test. make check has just failed: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird=2022-08-30%2001%3A15%3A13 > I just tested it in my test

Re: Bump MIN_WINNT to 0x0600 (Vista) as minimal runtime in 16~

On Tue, Aug 30, 2022 at 12:57 PM Michael Paquier wrote: > On Sat, Aug 27, 2022 at 02:35:25PM +0900, Michael Paquier wrote: > > There may be a point in enforcing CreateProcess() if > > CreateRestrictedToken() cannot be loaded, but that would be a security > > issue if Windows goes crazy as we

Re: Reducing the chunk header sizes on all memory context types

On 8/30/22 02:45, David Rowley wrote: > On Tue, 30 Aug 2022 at 03:39, Tomas Vondra > wrote: >> The attached patch seems to fix the issue for me - at least it seems >> like that. This probably will need to get backpatched, I guess. Maybe we >> should add an assert to MemoryChunkGetPointer to

Re: effective_multixact_freeze_max_age issue

On Mon, Aug 29, 2022 at 2:20 AM Matthias van de Meent wrote: > Apart from the message that this behaviour is changing, I'd prefer > some more description in the commit message as to why this needs > changing. I usually only write a full commit message before posting a patch when it's a full

Re: pg_stat_wal: tracking the compression effect

On 2022-08-27 16:48, Bharath Rupireddy wrote: On Fri, Aug 26, 2022 at 8:39 AM Kyotaro Horiguchi wrote: At Fri, 26 Aug 2022 11:55:27 +0900 (JST), Kyotaro Horiguchi wrote in > At Thu, 25 Aug 2022 16:04:50 +0900, Ken Kato wrote in > > Accumulating the values, which indicates how much space

Re: Reducing the chunk header sizes on all memory context types

On Tue, 30 Aug 2022 at 12:45, David Rowley wrote: > I think the existing sentinel check looks wrong: > > if (!sentinel_ok(chunk, slab->chunkSize)) > > shouldn't that be passing the pointer rather than the chunk? Here's v2 of the slab-fix patch. I've included the sentinel check fix. This passes

Re: Reducing the chunk header sizes on all memory context types

On Tue, 30 Aug 2022 at 12:22, Tomas Vondra wrote: > I also suggested doing a similar check in MemoryChunkGetPointer, so that > we catch the issue earlier - right after we allocate the chunk. Any > opinion on that? I think it's probably a good idea. However, I'm not yet sure if we can keep it as

Re: Bump MIN_WINNT to 0x0600 (Vista) as minimal runtime in 16~

On Sat, Aug 27, 2022 at 02:35:25PM +0900, Michael Paquier wrote: > There may be a point in enforcing CreateProcess() if > CreateRestrictedToken() cannot be loaded, but that would be a security > issue if Windows goes crazy as we should always expect the function, > so this had better return an

Re: Reducing the chunk header sizes on all memory context types

On Tue, 30 Aug 2022 at 03:39, Tomas Vondra wrote: > The attached patch seems to fix the issue for me - at least it seems > like that. This probably will need to get backpatched, I guess. Maybe we > should add an assert to MemoryChunkGetPointer to check alignment? Hi Tomas, I just wanted to

Re: [PATCH] Add native windows on arm64 support

Hi, On 2022-08-29 19:58:31 -0400, Tom Lane wrote: > Michael Paquier writes: > > This is amazing. The issue has showed up a second time in a row in > > bowerbird, as of: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird=2022-08-29%2013%3A30%3A32 > > That is fascinating. > >

Re: Reducing the chunk header sizes on all memory context types

On 8/29/22 23:57, Tom Lane wrote: > David Rowley writes: >> I've read over the emails and glanced at Tomas' patch. I think that >> seems good. I think I'd rather see us do that than pad the struct out >> further as Tomas' method is more aligned to what we do in aset.c >> (ALLOC_BLOCKHDRSZ) and

Re: [PATCH] Add native windows on arm64 support

Hi, On 2022-08-30 08:48:38 +0900, Michael Paquier wrote: > On Mon, Aug 29, 2022 at 10:12:20AM +0900, Michael Paquier wrote: > > I have noticed that yesterday, but cannot think much about it. This > > basically changes the position of "" for the first record, > > leaving the second one untouched:

Re: [PATCH] Add native windows on arm64 support

Michael Paquier writes: > This is amazing. The issue has showed up a second time in a row in > bowerbird, as of: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird=2022-08-29%2013%3A30%3A32 That is fascinating. > I don't know what to think about ASLR that manipulates the

Re: [PATCH] Add native windows on arm64 support

On Mon, Aug 29, 2022 at 10:12:20AM +0900, Michael Paquier wrote: > I have noticed that yesterday, but cannot think much about it. This > basically changes the position of "" for the first record, > leaving the second one untouched: > > > > I am not used to xmltable(), but I wonder if there is

Re: identifying the backend that owns a temporary schema

On Tue, Aug 23, 2022 at 10:29:05AM +0100, Greg Stark wrote: > Having this function would be great (I admit I never responded because > I never figured out if your suggestion was right or not:). But should > it also be added to the pg_stat_activity view? Perhaps even just in > the SQL view using

Re: archive modules

On Thu, Aug 25, 2022 at 01:06:00PM -0700, Nathan Bossart wrote: > On Thu, Aug 25, 2022 at 03:29:41PM +0200, talk to ben wrote: >> Here is a patch with the proposed wording. > > Here is the same patch with a couple more links. I would advise that you create a commitfest entry for your patch so

Re: effective_multixact_freeze_max_age issue

On Mon, Aug 29, 2022 at 10:25:50AM -0700, Peter Geoghegan wrote: > On Sun, Aug 28, 2022 at 4:14 PM Nathan Bossart > wrote: >> The idea seems sound to me, and IMO your patch simplifies things nicely, >> which might be reason enough to proceed with it. > > It is primarily a case of making things

introduce bufmgr hooks

Hi hackers, I'd like to propose some new hooks for the buffer manager. My primary goal is to allow users to create an additional caching mechanism between the shared buffers and disk for evicted buffers. For example, some EC2 instance classes have ephemeral disks that are physically attached to

windows resource files, bugs and what do we actually want

Hi, A few things about the windows resource files we generate 1) For make based builds, all libraries that are built with MODULES rather than MODULES_big have the wrong "FILETYPE", because Makefile.win32 checks $(shlib), which is only set for MODULES_big. This used to be even more

Re: replacing role-level NOINHERIT with a grant-level option

On Mon, Aug 29, 2022 at 03:38:57PM -0400, Robert Haas wrote: > Here is a patch to rearrange the logic slightly and also add a test > case memorializing the intended behavior. Without this change, the > regression test included in the patch fails like this: > > ERROR: no possible grantors > >

Re: Reducing the chunk header sizes on all memory context types

David Rowley writes: > I've read over the emails and glanced at Tomas' patch. I think that > seems good. I think I'd rather see us do that than pad the struct out > further as Tomas' method is more aligned to what we do in aset.c > (ALLOC_BLOCKHDRSZ) and generation.c (Generation_BLOCKHDRSZ). > I

Re: Reducing the chunk header sizes on all memory context types

On Tue, 30 Aug 2022 at 03:43, Tom Lane wrote: > I think adding a padding field to SlabBlock would be a less messy > solution than your patch. Thank you both of you for looking at this while I was sleeping. I've read over the emails and glanced at Tomas' patch. I think that seems good. I think

Re: SQL/JSON features for v15

On 2022-08-29 Mo 09:35, Jonathan S. Katz wrote: > On 8/29/22 8:56 AM, Amit Langote wrote: >> On Sat, Aug 27, 2022 at 5:11 AM Nikita Glukhov >> wrote: > >> I am not sure if it's OK to eval_const_expressions() on a Query >> sub-expression during parse-analysis.  IIUC, it is only correct to >>

Re: logical decoding and replication of sequences

On Tue, Aug 30, 2022 at 6:04 AM Tomas Vondra wrote: > On 8/29/22 12:21, Thomas Munro wrote: > > 0001: Instead of figuring out when to invalidate the cache, let's > > just invalidate it before every read attempt. It is only marked valid > > after success (ie state->readLen > 0). No need to

Re: New strategies for freezing, advancing relfrozenxid early

On Mon, Aug 29, 2022 at 11:47 AM Jeff Davis wrote: > Sounds like a good goal, and loosely follows the precedent of > checkpoint targets and vacuum cost delays. Right. > Why is the threshold per-table? Imagine someone who has a bunch of 4GB > partitions that add up to a huge amount of deferred

Postmaster self-deadlock due to PLT linkage resolution

Buildfarm member mamba (NetBSD-current on prairiedog's former hardware) has failed repeatedly since I set it up. I have now run the cause of that to ground [1], and here's what's happening: if the postmaster receives a signal just before it first waits at the select() in ServerLoop, it can

Re: replacing role-level NOINHERIT with a grant-level option

On Mon, Aug 29, 2022 at 10:17 AM Robert Haas wrote: > Good catch. Thanks for the review. Committed with that correction. Argh, I found a bug, and one that I should have caught during testing, too. I modelled the new function select_best_grantor() on is_admin_of_role(), but it differs in that it

Re: New strategies for freezing, advancing relfrozenxid early

On Thu, 2022-08-25 at 14:21 -0700, Peter Geoghegan wrote: > The main high level goal of this work is to avoid painful, disruptive > antiwraparound autovacuums (and other aggressive VACUUMs) that do way > too much "catch up" freezing, all at once, causing significant > disruption to production

Re: logical decoding and replication of sequences

On 8/29/22 12:21, Thomas Munro wrote: > On Mon, Aug 8, 2022 at 8:56 PM Kyotaro Horiguchi > wrote: >> At Mon, 08 Aug 2022 17:33:22 +0900 (JST), Kyotaro Horiguchi >> wrote in >>> If WaitForWALToBecomeAvailable returned by promotion, ReadPageInteral >>> misses the chance to inavlidate

Re: effective_multixact_freeze_max_age issue

On Sun, Aug 28, 2022 at 4:14 PM Nathan Bossart wrote: > The idea seems sound to me, and IMO your patch simplifies things nicely, > which might be reason enough to proceed with it. It is primarily a case of making things simpler. Why would it ever make sense to interpret age differently in the

Re: use ARM intrinsics in pg_lfind32() where available

On Mon, Aug 29, 2022 at 05:49:46PM +0700, John Naylor wrote: > Bowerbird just reported the same error, so I went ahead and pushed a > fix with this. Thanks! I've attached a follow-up patch with a couple of small suggestions. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com diff

Re: [BUG] Panic due to incorrect missingContrecPtr after promotion

On Mon, Aug 29, 2022 at 12:54 PM Robert Haas wrote: > On Wed, Aug 10, 2022 at 4:37 AM Kyotaro Horiguchi > wrote: > > So, it seems that the *standby* received the inconsistent WAL stream > > (aborted-contrecord not followed by a overwriting-missing-contrecord) > > from the primary. Thus the

Re: [BUG] Panic due to incorrect missingContrecPtr after promotion

On Wed, Aug 10, 2022 at 4:37 AM Kyotaro Horiguchi wrote: > So, it seems that the *standby* received the inconsistent WAL stream > (aborted-contrecord not followed by a overwriting-missing-contrecord) > from the primary. Thus the inconsistency happened on the primary, not > on the standby. > >

Re: standby promotion can create unreadable WAL

On Mon, Aug 29, 2022 at 12:21 AM Kyotaro Horiguchi wrote: > Mmm. That seems wrong. So forget about that. The proposed patch looks > fine to me. Thanks for thinking it over. Committed and back-patched as far as v10, since that's the oldest supported release. -- Robert Haas EDB:

Re: Reducing the chunk header sizes on all memory context types

On 8/29/22 17:43, Tom Lane wrote: > Tomas Vondra writes: >> I suspect it's a pre-existing bug in Slab allocator, because it does this: > >> #define SlabBlockGetChunk(slab, block, idx) \ >> ((MemoryChunk *) ((char *) (block) + sizeof(SlabBlock) \ >> +

Re: Reducing the chunk header sizes on all memory context types

Andres Freund writes: > On 2022-08-29 11:43:14 -0400, Tom Lane wrote: >> I think adding a padding field to SlabBlock would be a less messy >> solution than your patch. > That just seems to invite the same problem happening again later and it's > harder to ensure that the padding is correct

Re: Reducing the chunk header sizes on all memory context types

Hi, On 2022-08-29 11:43:14 -0400, Tom Lane wrote: > Tomas Vondra writes: > > I suspect it's a pre-existing bug in Slab allocator, because it does this: > > > #define SlabBlockGetChunk(slab, block, idx) \ > > ((MemoryChunk *) ((char *) (block) + sizeof(SlabBlock) \ > >

Re: wal_sync_method=fsync_writethrough

On Fri, Aug 26, 2022 at 11:29 PM Thomas Munro wrote: > > On Sat, Aug 27, 2022 at 12:17 AM Magnus Hagander wrote: > > So, I don't know how it works now, but the history at least was this: > > it was not about the disk caches, it was about raid controller caches. > > Basically, we determined that

Re: Reducing the chunk header sizes on all memory context types

Tomas Vondra writes: > I suspect it's a pre-existing bug in Slab allocator, because it does this: > #define SlabBlockGetChunk(slab, block, idx) \ > ((MemoryChunk *) ((char *) (block) + sizeof(SlabBlock) \ > + (idx * slab->fullChunkSize))) > and

Re: Reducing the chunk header sizes on all memory context types

On 8/29/22 17:27, Tomas Vondra wrote: > ... > > I suspect it's a pre-existing bug in Slab allocator, because it does this: > > #define SlabBlockGetChunk(slab, block, idx) \ > ((MemoryChunk *) ((char *) (block) + sizeof(SlabBlock) \ > + (idx *

Re: Reducing the chunk header sizes on all memory context types

Got it: sizeof(SlabBlock) isn't a multiple of MAXALIGN, (gdb) p sizeof(SlabBlock) $4 = 20 but this coding requires it to be: #define SlabBlockGetChunk(slab, block, idx) \ ((MemoryChunk *) ((char *) (block) + sizeof(SlabBlock) \ + (idx *

Re: Reducing the chunk header sizes on all memory context types

Robert Haas writes: > I've got another problem with this patch here on macOS: > In file included from aset.c:52: > ../../../../src/include/utils/memutils_memorychunk.h:170:18: error: > comparison of constant 7 with expression of type > 'MemoryContextMethodID' (aka 'enum MemoryContextMethodID')

Re: Reducing the chunk header sizes on all memory context types

On 8/29/22 17:20, Tom Lane wrote: > Tomas Vondra writes: >> I can reproduce it on my system (rpi4 running 32-bit raspbian). > > Yeah, more or less same as what I'm testing on. > > Seeing that the complaint is about pfree'ing a non-maxaligned > ReorderBufferChange pointer, I tried adding > >

Re: Reducing the chunk header sizes on all memory context types

I wrote: > So the bug is in fact in David's changes, and it consists in palloc > sometimes handing back non-maxaligned pointers. I find it mildly > astonishing that we managed to get through core regression tests > without such a fault surfacing, but there you have it. Oh! I just noticed that

Re: Reducing the chunk header sizes on all memory context types

Tomas Vondra writes: > I can reproduce it on my system (rpi4 running 32-bit raspbian). Yeah, more or less same as what I'm testing on. Seeing that the complaint is about pfree'ing a non-maxaligned ReorderBufferChange pointer, I tried adding diff --git

Re: Reducing the chunk header sizes on all memory context types

Hi, I've got another problem with this patch here on macOS: ccache clang -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Werror=unguarded-availability-new -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv

Re: Reducing the chunk header sizes on all memory context types

Amit Kapila writes: > Yeah, I also thought that way but couldn't find a reason. I think if > David is able to reproduce it on one of his systems then he can try > locally reverting both the commits one by one. It seems to repro easily on any 32-bit platform. Aside from the buildfarm results,

Re: Reducing the chunk header sizes on all memory context types

On 8/29/22 16:02, Amit Kapila wrote: > On Mon, Aug 29, 2022 at 7:17 PM Tom Lane wrote: >> >> David Rowley writes: >>> I suspect, going by all 3 failing animals being 32-bit which have a >>> MAXIMUM_ALIGNOF 8 and SIZEOF_SIZE_T of 4 that this is due to the lack >>> of padding in the MemoryChunk

Re: Expand palloc/pg_malloc API

On Fri, Aug 12, 2022 at 3:31 AM Peter Eisentraut wrote: > (Personally, I have always been a bit suspicious about using the name > palloc() without memory context semantics in frontend code, but I guess > this is wide-spread now.) I think it would be a good thing to add memory context support to

Re: replacing role-level NOINHERIT with a grant-level option

On Sun, Aug 28, 2022 at 5:14 PM Nathan Bossart wrote: > nitpick: I believe there should be a period before "After." > > Otherwise, LGTM. Good catch. Thanks for the review. Committed with that correction. -- Robert Haas EDB: http://www.enterprisedb.com

Re: Add semi-join pushdown to postgres_fdw

Hi Alexander, Thanks for working on this. It's great to see FDW join pushdown scope being expanded to more complex cases. I am still figuring out the implementation. It's been a while I have looked at join push down code. But following change strikes me odd -- subquery using immutable function

Re: Reducing the chunk header sizes on all memory context types

On Mon, Aug 29, 2022 at 7:17 PM Tom Lane wrote: > > David Rowley writes: > > I suspect, going by all 3 failing animals being 32-bit which have a > > MAXIMUM_ALIGNOF 8 and SIZEOF_SIZE_T of 4 that this is due to the lack > > of padding in the MemoryChunk struct. > > AllocChunkData and

Re: Reducing the chunk header sizes on all memory context types

David Rowley writes: > I suspect, going by all 3 failing animals being 32-bit which have a > MAXIMUM_ALIGNOF 8 and SIZEOF_SIZE_T of 4 that this is due to the lack > of padding in the MemoryChunk struct. > AllocChunkData and GenerationChunk had padding to account for > sizeof(Size) being 4 and

Re: SQL/JSON features for v15

On 8/29/22 8:56 AM, Amit Langote wrote: On Sat, Aug 27, 2022 at 5:11 AM Nikita Glukhov wrote: I am not sure if it's OK to eval_const_expressions() on a Query sub-expression during parse-analysis. IIUC, it is only correct to apply it to after the rewriting phase. Maybe it would be

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

On 2022-08-25 01:54, Damir Belyalov wrote: + /* Buffer was filled, commit subtransaction and prepare to replay */ + ReleaseCurrentSubTransaction(); What is actually being committed by this ReleaseCurrentSubTransaction()? It seems to me that just

Re: SQL/JSON features for v15

On Sat, Aug 27, 2022 at 5:11 AM Nikita Glukhov wrote: > On 26.08.2022 22:25, Andrew Dunstan wrote: > > On 2022-08-24 We 20:05, Nikita Glukhov wrote: > > v8 - is a highly WIP patch, which I failed to finish today. > Even some test cases fail now, and they simply show unfinished > things like casts

Re: Fix possible bogus array out of bonds (src/backend/access/brin/brin_minmax_multi.c)

Em dom., 28 de ago. de 2022 às 22:06, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > At Fri, 26 Aug 2022 10:28:50 -0300, Ranier Vilela > wrote in > > At function has_matching_range, if variable ranges->nranges == 0, > > we exit quickly with a result equal to false. > > > > This means

RE: patch: Add missing descriptions for rmgr APIs

> Your observation seems correct to me but you have not updated the > comment for the mask. Is there a reason for the same? Oh, it seems that I attached wrong one. There is no reason. PSA the newer version. Best Regards, Hayato Kuroda FUJITSU LIMITED v2-0001-add-a-missing-comment.patch

Re: Make #else/#endif comments more consistent

On 29/08/2022 14:50, Peter Eisentraut wrote: I usually try to follow the guidelines in , which pretty much match what you are proposing. Thank you for the link, it's a useful one and the wording is better than mine. Note that for

Re: patch: Add missing descriptions for rmgr APIs

On Mon, Aug 29, 2022 at 8:48 AM kuroda.hay...@fujitsu.com wrote: > > Hi hackers, > > While reading codes related with logical decoding, > I thought that following comment in rmgrlist.h is not consistent. > > > /* symbol name, textual name, redo, desc, identify, startup, cleanup */ > > This

[PATCH] Enable using llvm jitlink as an alternative llvm jit linker of old Rtdyld.

This brings the bonus of support jitting on riscv64 (included in this patch) and other platforms Rtdyld doesn't support, e.g. windows COFF. Currently, llvm doesn't expose jitlink (ObjectLinkingLayer) via C API, so a wrapper is added. This also adds minor llvm 15 compat fix that is needed ---

Re: Handle infinite recursion in logical replication setup

On Mon, Aug 29, 2022 at 11:59 AM Peter Smith wrote: > > Here are some review comments for patch v42-0001: > > ~~ > > 6. > > + warning to notify user to check the publisher tables. The user can ensure > + that publisher tables do not have data which has an origin associated > before > +

Re: Make #else/#endif comments more consistent

On 29.08.22 11:38, Anton Voloshin wrote: I propose making them more consistent. Would the following guidelines be acceptable? I usually try to follow the guidelines in , which pretty much match what you are proposing. And this:

Re: pg_checksum: add test for coverage

> On 29 Aug 2022, at 13:26, Dong Wook Lee wrote: > I add a tiny test to pg_checksum for coverage. > I checked it improve test coverage 77.9% -> 87.7%. +# Checksums are verified if --progress arguments are specified +command_ok( + [ 'pg_checksums', '--progress', '-D', $pgdata ], +

RE: Perform streaming logical transactions by background workers and parallel apply

On Tues, Aug 24, 2022 16:41 PM Kuroda, Hayato/黒田 隼人 wrote: > Dear Wang, > > Followings are my comments about v23-0003. Currently I do not have any > comments about 0002 and 0004. Thanks for your comments. > 09. general > > It seems that logicalrep_rel_mark_parallel_apply() is always called

pg_checksum: add test for coverage

Hi, I add a tiny test to pg_checksum for coverage. I checked it improve test coverage 77.9% -> 87.7%. --- Regards, DongWook Lee. v1_add_test_to_pg_checksum.patch Description: Binary data

Re: Reducing the chunk header sizes on all memory context types

On Mon, 29 Aug 2022 at 21:37, Amit Kapila wrote: > 2022-08-29 03:29:56.911 EDT [1056:67] pg_regress/ddl STATEMENT: > SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, > NULL, 'include-xids', '0', 'skip-empty-xacts', '1'); > TRAP: FailedAssertion("pointer == (void *)

Re: Handle infinite recursion in logical replication setup

On Wed, Aug 24, 2022 at 7:27 PM vignesh C wrote: > > Since there was no objections to change it to throw a warning, I have > made the changes for the same. > Review comments for v42-0001* == 1. Can we improve the query in check_pub_table_subscribed() so that it doesn't

Re: use ARM intrinsics in pg_lfind32() where available

On Mon, Aug 29, 2022 at 4:28 PM John Naylor wrote: > > Here's the simplest fix I can think of: > > /* > * Exactly like vector8_is_highbit_set except for the input type, so > it still looks > * at each _byte_ separately. > * > * XXX x86 uses the same underlying type for vectors with 8-bit, >

Re: [PATCH] Optimize json_lex_string by batching character copying

> I wonder why copyable_characters_length is not reset after flushing. It's not necessary because of the break statement right after. But this part of the code was refactored away in John's improved patch that's actually merged: 

Re: logical decoding and replication of sequences

On Mon, Aug 8, 2022 at 8:56 PM Kyotaro Horiguchi wrote: > At Mon, 08 Aug 2022 17:33:22 +0900 (JST), Kyotaro Horiguchi > wrote in > > If WaitForWALToBecomeAvailable returned by promotion, ReadPageInteral > > misses the chance to inavlidate reader-state. That state is not an > > error while in

Re: standby promotion can create unreadable WAL

On Fri, Aug 26, 2022 at 6:14 PM Dilip Kumar wrote: > > On Tue, Aug 23, 2022 at 12:06 AM Robert Haas wrote: > > > However, if anything > > did try to look at file #4 it would get confused. Maybe that can > > happen if this is a streaming standby, where we only write an > > end-of-recovery record

Re: Reducing the chunk header sizes on all memory context types

On Mon, 29 Aug 2022 at 21:37, Amit Kapila wrote: > I am not completely sure if the failure is due to your commit but it > was showing the line added by this commit. Note that I had also > committed (commit id: d2169c9985) one patch today but couldn't > correlate the failure with that so thought

Make #else/#endif comments more consistent

Hello, while reading the postgres code, occasionally I see a little bit of inconsistency in the comments after #else (and corresponding #endif). In some places #else/endif's comment expresses condition for else block to be active: #ifdef HAVE_UUID_OSSP ... #else /*

  1   2   >