Hi,
On Thu, Apr 17, 2025 at 01:58:44AM +1200, Thomas Munro wrote:
> On Wed, Apr 16, 2025 at 9:14 PM Jakub Wartak
> wrote:
> > 2. Should we also interleave DSA/DSM for Parallel Query? (I'm not an
> > expert on DSA/DSM at all)
>
> I have no answers but I have speculated for years about a very
> sp
Hi,
On Wed, Apr 16, 2025 at 10:05:04AM -0400, Robert Haas wrote:
> On Wed, Apr 16, 2025 at 5:14 AM Jakub Wartak
> wrote:
> > Normal pgbench workloads tend to be not affected, as each backend
> > tends to touch just a small partition of shm (thanks to BAS
> > strategies). Some remaining questions
On Wed, Apr 16, 2025 at 5:14 AM Jakub Wartak
wrote:
> Normal pgbench workloads tend to be not affected, as each backend
> tends to touch just a small partition of shm (thanks to BAS
> strategies). Some remaining questions are:
> 1. How to name this GUC (numa or numa_shm_interleave) ? I prefer the
On Thu, Apr 17, 2025 at 1:58 AM Thomas Munro wrote:
> I have no answers but I have speculated for years about a very
> specific case (without any idea where to begin due to lack of ... I
> guess all this sort of stuff): in ExecParallelHashJoinNewBatch(),
> workers split up and try to work on diffe
On Wed, Apr 16, 2025 at 9:14 PM Jakub Wartak
wrote:
> 2. Should we also interleave DSA/DSM for Parallel Query? (I'm not an
> expert on DSA/DSM at all)
I have no answers but I have speculated for years about a very
specific case (without any idea where to begin due to lack of ... I
guess all this
25%RAM) , but with >= 4 NUMA nodes (4 sockets or some
modern MCMs) kernel might start spilling the s_b (> 25%) to the other
NUMA node on it's own, so it's best to verify it using
pg_shmem_allocations_numa...
-J.
[1] -
https://anarazel.de/talks/2024-10-23-pgconf-eu-numa-vs-postgresql
memory is no longer allocated individually, it
> cannot be freed
> separately. This results in the following error:
>
> ERROR: pfree called with invalid pointer 0x60a15edc44e0 (header
> 0x0028)
>
> These allocations are done together to improve reporting of shared
>
Thanks!
I've pushed the first two parts, improving the shmem accounting.
I've done a couple additional adjustments before commit, namely:
1) I've renamed hash_get_init_size() to just hash_get_size(). We've not
indicated that it's "initial" allocation before, I don't think we need
to indicate to
Hi,
I think it's almost committable. Attached is v8 with some minor review
> adjustments, and updated commit messages. Please read through those and
> feel free to suggest changes.
>
>
The changes look good to me.
About the following question.
/* XXX what about segment size? should check have H
idually, it cannot
be freed
separately. This results in the following error:
ERROR: pfree called with invalid pointer 0x60a15edc44e0 (header
0x0028)
These allocations are done together to improve reporting of shared memory
allocations
for shared hash tables. Similar change is done for non-
data, but you have to say
@@ -507,9 +538,35 @@ hash_create(const char *tabname, long nelem, const HASHCTL *info, int flags)
hashp->isshared = false;
}
+ /* Choose the number of entries to allocate at a time. */
+ nelem_batch = choose_nelem_alloc(info->entrysize);
+
+ /*
+ * Calculate the num
s, which incorporates your review patches
and addresses a few remaining comments.
Thank you,
Rahila Syed
v7-0002-Replace-ShmemAlloc-calls-by-ShmemInitStruct.patch
Description: Binary data
v7-0003-Add-cacheline-padding-between-heavily-accessed-array.patch
Description: Binary data
v7-0001-Account-for-all-the-shared-memory-allocated-by-hash_.patch
Description: Binary data
ot;elements" allocation is aligned
> to PG_CACHE_LINE_SIZE, i.e. 128B, because ShmemAllocRaw() does this:
>
> size = CACHELINEALIGN(size);
>
> So it distributes memory in multiples of 128B, and I believe it starts
> at a multiple of 128B.
>
>
;
> So it distributes memory in multiples of 128B, and I believe it starts
> at a multiple of 128B.
>
> But the patch reworks this to allocate everything at once, and thus it
> won't get this alignment automatically. AFAIK that's not intentional,
> because no one explic
;s ignored.
The bit "For more explanation see comments within this function" is not
great, if only because there are not many comments within the function,
so there's no "more explanation". But if there's something important, it
should be in the main comment, preferably.
r
Hi,
On 3/27/25 13:02, Rahila Syed wrote:
>
> Hi Tomas,
>
>
> I did a review on v3 of the patch. I see there's been some minor changes
> in v4 - I haven't tried to adjust my review, but I assume most of my
> comments still apply.
>
>
> Thank you for your interest and review.
>
>
alculate nbuckets and
nsegs,
hence the probability of mismatch is low. I am open to adding some
asserts to verify this.
Do you have any suggestions in mind?
Please find attached updated patches after merging all your review comments
except
a few discussed above.
Thank you,
Rahila Syed
v5-0003-Add-cacheline-padding-between-heavily-accessed-array.patch
Description: Binary data
v5-0001-Account-for-initial-shared-memory-allocated-by-hash_.patch
Description: Binary data
v5-0002-Replace-ShmemAlloc-calls-by-ShmemInitStruct.patch
Description: Binary data
ntion can we
get there? I don't get it.
Also, why is the patch adding padding after statusFlags (the last array
allocated in InitProcGlobal) and not between allProcs and xids?
regards
--
Tomas Vondra
From f527909dda02b4c7231db53a0fe6cecbaec55ca4 Mon Sep 17 00:00:00 2001
From: Rahila Sye
int() on num_partitions before running the function.
Additionally, I am not adding any new code to the compute_buckets_and_segs
function. I am simply moving part of the init_tab() code into a separate
function
for reuse.
Please find attached the updated and rebased patches.
Thank you,
Rahila Syed
v4-0002-Replace-ShmemAlloc-calls-by-ShmemInitStruct.patch
Description: Binary data
v4-0001-Account-for-initial-shared-memory-allocated-by-hash_.patch
Description: Binary data
Hi,
On Wed, 12 Mar 2025 at 13:46, Rahila Syed wrote:
> I have now made the changes uniformly across shared and non-shared hash
> tables,
> making the code fix look cleaner. I hope this aligns with your suggestions.
> Please find attached updated and rebased versions of both patches.
Thank you f
d non-shared hash
tables,
making the code fix look cleaner. I hope this aligns with your suggestions.
Please find attached updated and rebased versions of both patches.
Kindly let me know your views.
Thank you,
Rahila Syed
v3-0001-Account-for-initial-shared-memory-allocated-by-hash_.patch
Description: Binary data
v3-0002-Replace-ShmemAlloc-calls-by-ShmemInitStruct.patch
Description: Binary data
83 100644
> > --- a/src/include/utils/hsearch.h
> > +++ b/src/include/utils/hsearch.h
> > @@ -151,7 +151,7 @@ extern void hash_seq_term(HASH_SEQ_STATUS *status);
> > extern void hash_freeze(HTAB *hashp);
> > extern Size hash_estimate_size(long num_entries
uum to use shared memory for easier testing
0003: the above 1-line change
drop table if exists test;
create unlogged table test (a int) with (AUTOVACUUM_ENABLED=false);
insert into test select * from generate_series(1,20_000_000,1);
create index on test (a);
select pg_prewarm('test'
Hi,
Thanks for sending these, the issues addressed here have been bugging me for a
long while.
On 2025-03-01 10:19:01 +0530, Rahila Syed wrote:
> The 0001* patch improved the accounting for the shared memory allocated for
> a hash table during hash_create. pg_shmem_allocations tracks the
Hi,
The 0001* patch improved the accounting for the shared memory allocated for
a
hash table during hash_create.
pg_shmem_allocations tracks the memory allocated by ShmemInitStruct, which,
for shared hash tables, only covers memory allocated for the hash
directory
and control structure via
On Tue, 14 Jan 2025 at 12:32, Tom Lane wrote:
> Robins Tharakan writes:
> > The error seems to be around "annobin.so" and so it may be about how
> > gcc is being compiled (not sure). While I figure out if GCC compilation
> > needs work, I thought to bring it up here since v16+ seems to work fine
Robins Tharakan writes:
> Unrelated, parula has been failing the libperl test (only v15 and older),
> for the past
> 3 weeks - to clarify, this test started to fail (~18 days ago) before I
> fixed the
> 'RemoveIPC' configuration (~5 days ago), so this is unrelated to that
> change.
> https://buil
Hi Alexander,
On Sun, 22 Dec 2024 at 17:57, Robins Tharakan wrote:
>
> So if that's a key reason here, then probably by this time next week
things should
> settle down. I've begun setting it correctly (2 done with a few more to
go) - although
> given that some machines are at work, I'll try
On Thu, 9 Jan 2025 at 15:30, Alexander Lakhin wrote:
>
> Maybe you could try to reproduce such failures without buildfarm client,
just
> by running select_parallel, for example, with the attached patch applied.
> I mean running `make check` with parallel_schedule like:
> ...
> Or
> TESTS="test_set
Hello Robins,
22.12.2024 09:27, Robins Tharakan wrote:
- The only info about leafhopper may be relevant is that it's one of the newest machines (Graviton4) so it comes with
a recent hardware / kernel / stock gcc 11.4.1.
Could you please take a look at leafhopper. which is producing weird tes
On Sun, Dec 22, 2024 at 08:00:00AM +0200, Alexander Lakhin wrote:
> and batta:
> sid | gcc recent | aarch64 | michael [ a t ] paquier.xyz
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=batta&dt=2024-12-16%2008%3A05%3A04
I suspect that this one has been caused by me, as I have logged int
ed by "could not open shared
> memory segment ...: No such file or directory" errors.
- I am unsure how batta is set up, but till late last week, none of my
instances had set REMOVEIPC correctly. I am sorry, I didn't know about this
until Thomas pointed it out to me in another thre
Hello hackers,
I'd like to bring your attention to multiple buildfarm failures, which
occurred this month, on master only, caused by "could not open shared
memory segment ...: No such file or directory" errors.
First such errors were produced on 2024-12-16 by:
leafhopper
Amazon L
Hi!
On 09.12.2024 11:03, Bertrand Drouvot wrote:
There is a missing space. I think that should be " at server..." or "...%llu ".
Thanks for pointing this out. In the other code the elog messages are all on
one line,
regardless of their length. Did the same in v3.
On 10.12.2024 09:42, Bertra
Hi,
On Tue, Dec 10, 2024 at 09:54:36AM +0900, Michael Paquier wrote:
> On Mon, Dec 09, 2024 at 08:03:54AM +, Bertrand Drouvot wrote:
> > Right. OTOH I think that could help the tap test added in da99fedf8c to not
> > rely on assert enabled build (the tap test could "simply" check for the
> > W
On Mon, Dec 09, 2024 at 08:03:54AM +, Bertrand Drouvot wrote:
> Right. OTOH I think that could help the tap test added in da99fedf8c to not
> rely on assert enabled build (the tap test could "simply" check for the
> WARNING in the logfile instead).
That's true. Still, the coverage that we hav
Hi,
On Mon, Dec 09, 2024 at 02:39:58PM +0900, Michael Paquier wrote:
> On Sat, Dec 07, 2024 at 12:31:46PM +0300, Anton A. Melnikov wrote:
> > Completely agree that the original comment needs to be revised,
> > since it implies that it is normal for deleted entries to be here,
> > but it is not the
On Sat, Dec 07, 2024 at 12:31:46PM +0300, Anton A. Melnikov wrote:
> Completely agree that the original comment needs to be revised,
> since it implies that it is normal for deleted entries to be here,
> but it is not the case.
Yep, so applied v2-0001 to document that, and backpatched it as it is
Hi!
On 04.12.2024 18:24, Bertrand Drouvot wrote:
Thanks! I've the feeling that something has to be fixed, see my comments in
[1]. It might be that the failed assertion does not handle a "valid" scenario.
[1]:
https://www.postgresql.org/message-id/Z1BzI/eMTCOKA%2Bj6%40ip-10-97-1-34.eu-west-3.co
Hi,
On Thu, Dec 05, 2024 at 05:13:13PM +0900, Michael Paquier wrote:
> On Thu, Dec 05, 2024 at 07:37:27AM +, Bertrand Drouvot wrote:
> > That said, I think that's worth to update the comment a bit (like in the
> > attached?) as I think that answers a legitimate question someone could have
> >
On Thu, Dec 05, 2024 at 07:37:27AM +, Bertrand Drouvot wrote:
> That said, I think that's worth to update the comment a bit (like in the
> attached?) as I think that answers a legitimate question someone could have
> while
> reading this code.
>
> - /* we may have some "dropped"
Hi,
On Thu, Dec 05, 2024 at 02:43:43PM +0900, Michael Paquier wrote:
> On Wed, Dec 04, 2024 at 03:24:55PM +, Bertrand Drouvot wrote:
> > Thanks! I've the feeling that something has to be fixed, see my comments in
> > [1]. It might be that the failed assertion does not handle a "valid"
> > sce
On Wed, Dec 04, 2024 at 03:24:55PM +, Bertrand Drouvot wrote:
> Thanks! I've the feeling that something has to be fixed, see my comments in
> [1]. It might be that the failed assertion does not handle a "valid" scenario.
>
> [1]:
> https://www.postgresql.org/message-id/Z1BzI/eMTCOKA%2Bj6%40ip
Hi,
On Wed, Dec 04, 2024 at 04:00:53AM +0300, Anton A. Melnikov wrote:
>
> On 03.12.2024 18:07, Andres Freund wrote:
> > Hi,
> >
> > On 2024-12-03 13:37:48 +0300, Anton A. Melnikov wrote:
> > > Found a place in the code of this patch that is unclear to me:
> > > https://github.com/postgres/postg
On 03.12.2024 18:07, Andres Freund wrote:
Hi,
On 2024-12-03 13:37:48 +0300, Anton A. Melnikov wrote:
Found a place in the code of this patch that is unclear to me:
https://github.com/postgres/postgres/blob/1acf10549e64c6a52ced570d712fcba1a2f5d1ec/src/backend/utils/activity/pgstat.c#L1658
Owi
Hi,
On 2024-12-03 13:37:48 +0300, Anton A. Melnikov wrote:
> Found a place in the code of this patch that is unclear to me:
> https://github.com/postgres/postgres/blob/1acf10549e64c6a52ced570d712fcba1a2f5d1ec/src/backend/utils/activity/pgstat.c#L1658
>
> Owing assert() the next if() should never
Hi!
Found a place in the code of this patch that is unclear to me:
https://github.com/postgres/postgres/blob/1acf10549e64c6a52ced570d712fcba1a2f5d1ec/src/backend/utils/activity/pgstat.c#L1658
Owing assert() the next if() should never be performed, but the comment above
says the opposite.
Is thi
On 29/07/2024 21:10, Robert Haas wrote:
On Mon, Jul 29, 2024 at 5:57 AM Rui Zhao wrote:
Prior to PG16, postmaster children would manually detach from shared memory
if it was not needed. However, this behavior was removed in fork mode in
commit aafc05d.
Oh. The commit message makes no mention
On Mon, Jul 29, 2024 at 5:57 AM Rui Zhao wrote:
> Prior to PG16, postmaster children would manually detach from shared memory
> if it was not needed. However, this behavior was removed in fork mode in
> commit aafc05d.
Oh. The commit message makes no mention of that. I wonder wheth
Thanks for your reply.
> Thanks for the patch. How do you estimate its performance impact?
In my patch, ony child processes that set
(child_process_kinds[child_type].shmem_attach == false)
will detach from shared memory.
Child processes with B_STANDALONE_BACKEND and B_INVALID don
Hi Rui,
> Prior to PG16, postmaster children would manually detach from shared memory
> if it was not needed. However, this behavior was removed in fork mode in
> commit aafc05d.
>
> Detaching shared memory when it is no longer needed is beneficial, as
> postmaster children (lik
Prior to PG16, postmaster children would manually detach from shared memory
if it was not needed. However, this behavior was removed in fork mode in
commit aafc05d.
Detaching shared memory when it is no longer needed is beneficial, as
postmaster children (like syslogger) don't wish to tak
”.
During “ambuild”, I use “ShmemInitStruct” to initialize a segment of shared
memory and save the pointer to this location in my static, global pointer. I
then set some values of the structure that the pointer points to, which I
believe works correctly. I have ensured to acquire, and later release
Committed.
--
nathan
Nathan Bossart writes:
> The only thing stopping me from committing this right now is Tom's upthread
> objection about adding more GUCs that just expose values that you can't
> actually set. If that objection still stands, I'll withdraw this patch
> (and maybe try introducing a new way to surface
On Sun, Jun 09, 2024 at 02:04:17PM -0500, Nathan Bossart wrote:
> Here's a new version of the patch with the GUC renamed to
> num_os_semaphores.
The only thing stopping me from committing this right now is Tom's upthread
objection about adding more GUCs that just expose values that you can't
actua
100644
--- a/src/backend/storage/ipc/ipci.c
+++ b/src/backend/storage/ipc/ipci.c
@@ -372,11 +372,12 @@ InitializeShmemGUCs(void)
Sizesize_b;
Sizesize_mb;
Sizehp_size;
+ int num_semas;
/*
* Ca
On Thu, Jun 06, 2024 at 03:31:53PM -0400, Robert Haas wrote:
> I don't really like making this a GUC, but what's the other option?
> It's reasonable for people to want to ask the server how many
> resources it will need to start, and -C is the only tool we have for
> that right now. So I feel like
On Thu, Jun 6, 2024 at 3:21 PM Nathan Bossart wrote:
> Here is a rebased version of the patch for v18 that adds a runtime-computed
> GUC. As I noted earlier, there still isn't a consensus on this approach.
I don't really like making this a GUC, but what's the other option?
It's reasonable for pe
ipci.c
@@ -372,11 +372,12 @@ InitializeShmemGUCs(void)
Sizesize_b;
Sizesize_mb;
Sizehp_size;
+ int num_semas;
/*
* Calculate the shared memory size and round up to the nearest
megabyte.
On Mon, Jun 03, 2024 at 02:04:19PM -0500, Nathan Bossart wrote:
> Of course, as soon as I committed this, I noticed another missing reference
> to max_wal_senders in the paragraph about POSIX semaphores. I plan to
> commit/back-patch the attached patch within the next couple days.
Committed.
--
On Mon, Jun 03, 2024 at 12:18:21PM -0500, Nathan Bossart wrote:
> On Tue, May 21, 2024 at 11:15:14PM +, Imseih (AWS), Sami wrote:
>> As far as backpatching the present inconsistencies in the docs,
>> [0] looks good to me.
>
> Committed.
Of course, as soon as I committed this, I noticed anothe
On Tue, May 21, 2024 at 11:15:14PM +, Imseih (AWS), Sami wrote:
>> Any concerns with doing something like this [0] for the back-branches? The
>> constant would be 6 instead of 7 on v14 through v16.
>
> As far as backpatching the present inconsistencies in the docs,
> [0] looks good to me.
Com
> Any concerns with doing something like this [0] for the back-branches? The
> constant would be 6 instead of 7 on v14 through v16.
As far as backpatching the present inconsistencies in the docs,
[0] looks good to me.
[0]
https://postgr.es/m/attachment/160360/v1-0001-fix-kernel-resources-docs-on
Sizesize_mb;
Sizehp_size;
+ int num_semas;
/*
* Calculate the shared memory size and round up to the nearest
megabyte.
*/
- size_b = CalculateShmemSize(NULL);
+ size_b = CalculateShmemSize(&nu
> postgres -D pgdev-dev -c shared_buffers=16MB -C
> shared_memory_size_in_huge_pages
> 13
> postgres -D pgdev-dev -c shared_buffers=16MB -c huge_page_size=1GB -C
> shared_memory_size_in_huge_pages
> 1
> Which is very useful to be able to actually configure that number of huge
> pages. I don't t
Hi,
On 2024-05-17 18:30:08 +, Imseih (AWS), Sami wrote:
> > The advantage of the GUC is that its value could be seen before trying to
> > actually start the server.
>
> Only if they have a sample in postgresql.conf file, right?
> A GUC like shared_memory_size_in_huge_pages will not be.
You ca
On Fri, May 17, 2024 at 06:30:08PM +, Imseih (AWS), Sami wrote:
>> The advantage of the GUC is that its value could be seen before trying to
>> actually start the server.
>
> Only if they have a sample in postgresql.conf file, right?
> A GUC like shared_memory_size_in_huge_pages will not be.
On Fri, May 17, 2024 at 12:48:37PM -0500, Nathan Bossart wrote:
> On Fri, May 17, 2024 at 01:09:55PM -0400, Tom Lane wrote:
>> Nathan Bossart writes:
>>> At a bare minimum, we should probably fix the obvious problems, but I
>>> wonder if we could simplify this section a bit, too.
>>
>> Yup. "The
>>> If the exact values
>>> are important, maybe we could introduce more GUCs like
>>> shared_memory_size_in_huge_pages that can be consulted (instead of
>>> requiring users to break out their calculators).
>>
>> I don't especially like shared_memory_size_in_huge_pages, and I don't
>> want to intro
On Fri, May 17, 2024 at 01:09:55PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> [ many, many problems in documented formulas ]
>
>> At a bare minimum, we should probably fix the obvious problems, but I
>> wonder if we could simplify this section a bit, too.
>
> Yup. "The definition of ins
Nathan Bossart writes:
> [ many, many problems in documented formulas ]
> At a bare minimum, we should probably fix the obvious problems, but I
> wonder if we could simplify this section a bit, too.
Yup. "The definition of insanity is doing the same thing over and
over and expecting different r
(moving to a new thread)
On Thu, May 16, 2024 at 09:16:46PM -0500, Nathan Bossart wrote:
> On Thu, May 16, 2024 at 04:37:10PM +, Imseih (AWS), Sami wrote:
>> Also, Not sure if I am mistaken here, but the "+ 5" in the existing docs
>> seems wrong.
>>
>> If it refers to NUM_AUXILIARY_PROCS def
On 2024-Mar-05, Hayato Kuroda (Fujitsu) wrote:
> Basically sounds good. My concerns are:
>
> * GetNamedDSMSegment() does not returns a raw pointer to dsm_segment. This
> means
> that it may be difficult to do dsm_unpin_segment on the caller side.
Maybe we don't need a "named" DSM segment at a
Dear Alvaro,
Thanks for giving comments!
> > I agreed it sounds good, but I don't think it can be implemented by
> > current interface. An interface for dynamically allocating memory is
> > GetNamedDSMSegment(), and it returns the same shared memory region if
>
t.
> I agreed it sounds good, but I don't think it can be implemented by
> current interface. An interface for dynamically allocating memory is
> GetNamedDSMSegment(), and it returns the same shared memory region if
> input names are the same. Therefore, there is no way to re-a
About the suggetion, you imagined AutoVacuumRequestWork() and brininsert(),
right? I agreed it sounds good, but I don't think it can be implemented by
current
interface. An interface for dynamically allocating memory is
GetNamedDSMSegment(),
and it returns the same shared memory region if input names are
On 2024-Mar-04, Hayato Kuroda (Fujitsu) wrote:
> However, the second idea is still valid, which allows the allocation
> of shared memory dynamically. This is a bit efficient for the system
> which tuples won't be frozen. Thought?
I think it would be worth allocating AutoVacuumShmem
ed by the
configuration parameter autovacuum_freeze_max_age. (This will happen even
if autovacuum is disabled.)
```
This means that my first idea won't work well. Even if the postmaster does not
initially allocate shared memory, backends may request to start auto vacuum and
use the region. However, the second
On 2024-Mar-04, Hayato Kuroda (Fujitsu) wrote:
> Dear hackers,
>
> While reading codes, I found that ApplyLauncherShmemInit() and
> AutoVacuumShmemInit() are always called even if they would not be
> launched.
Note that there are situations where the autovacuum launcher is started
even though au
Dear Tom,
Thanks for replying!
> "Hayato Kuroda (Fujitsu)" writes:
> > While reading codes, I found that ApplyLauncherShmemInit() and
> AutoVacuumShmemInit()
> > are always called even if they would not be launched.
> > It may be able to reduce the start time to avoid the unnecessary allocation.
"Hayato Kuroda (Fujitsu)" writes:
> While reading codes, I found that ApplyLauncherShmemInit() and
> AutoVacuumShmemInit()
> are always called even if they would not be launched.
> It may be able to reduce the start time to avoid the unnecessary allocation.
Why would this be a good idea? It wou
/launcher.c
@@ -962,6 +962,9 @@ ApplyLauncherShmemInit(void)
{
boolfound;
+if (max_logical_replication_workers == 0 || IsBinaryUpgrade)
+return;
+
```
2)
Dynamically allocate the shared memory. This was allowed by recent commit [1].
I made a small PoC only for logical launcher
On Mon, Jan 22, 2024 at 05:00:48PM +0530, Bharath Rupireddy wrote:
> On Mon, Jan 22, 2024 at 3:43 AM Nathan Bossart
> wrote:
>> Oops. I've attached an attempt at fixing this. I took the opportunity to
>> clean up the surrounding code a bit.
>
> The code looks cleaner and readable with the patc
On Mon, Jan 22, 2024 at 3:43 AM Nathan Bossart wrote:
>
> Oops. I've attached an attempt at fixing this. I took the opportunity to
> clean up the surrounding code a bit.
The code looks cleaner and readable with the patch. All the call sites
are taking care of dsm_attach returning NULL value. So
On Sun, Jan 21, 2024 at 04:13:20PM -0600, Nathan Bossart wrote:
> Oops. I've attached an attempt at fixing this. I took the opportunity to
> clean up the surrounding code a bit.
Thanks for the patch. Your proposed attempt looks correct to me with
an ERROR when no segments are found..
--
Michael
isting segment")));
}
- else if (!dsm_find_mapping(entry->handle))
+ else
{
- /* Attach to existing segment. */
- dsm_segment *seg = dsm_attach(entry->handle);
+ dsm_segment *seg = dsm_find_mapping(entry->handle);
+
+ /* If the existing segment is not already attached, attach it now.
Nathan Bossart writes:
> Committed. Thanks everyone for reviewing!
Coverity complained about this:
*** CID 1586660: Null pointer dereferences (NULL_RETURNS)
/srv/coverity/git/pgsql-git/postgresql/src/backend/storage/ipc/dsm_registry.c:
185 in GetNamedDSMSegment()
179 }
180
On Wed, Jan 17, 2024 at 08:00:00AM +0530, Bharath Rupireddy wrote:
> The v8 patches look good to me.
Committed. Thanks everyone for reviewing!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Jan 17, 2024 at 06:48:37AM +0530, Bharath Rupireddy wrote:
> LGTM.
Committed. Thanks for reviewing!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Jan 16, 2024 at 9:37 PM Nathan Bossart wrote:
>
> The autoprewarm change (0003) does use this variable. I considered making
> it optional (i.e., you could pass in NULL if you didn't want it), but I
> didn't feel like the extra code in GetNamedDSMSegment() to allow this was
> worth it so t
On Tue, Jan 16, 2024 at 9:22 PM Nathan Bossart wrote:
>
> I fixed this in v4.
LGTM.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
om
>From 402eaf87776fb6a9d212da66947f47c63bd53f2a Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 11 Jan 2024 21:55:25 -0600
Subject: [PATCH v8 1/3] reorganize shared memory and lwlocks documentation
---
doc/src/sgml/xfunc.sgml | 184 +---
1 file c
7f47c63bd53f2a Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 11 Jan 2024 21:55:25 -0600
Subject: [PATCH v4 1/1] reorganize shared memory and lwlocks documentation
---
doc/src/sgml/xfunc.sgml | 184 +---
1 file changed, 115 insertions(+), 69 deletions(-
On Tue, Jan 16, 2024 at 10:02:15AM +0530, Bharath Rupireddy wrote:
> The v3 patch looks good to me except for a nitpick: the input
> parameter for RequestAddinShmemSpace is 'Size' not 'int'
>
>
> void RequestAddinShmemSpace(int size)
>
Hah, I think this mistake is nearly old enough to vote (
but in production (without the
assertion), I'm seeing the following errors.
2024-01-16 04:49:28.961 UTC client backend[864369]
pg_regress/test_dsm_registry ERROR: could not resize shared memory
segment "/PostgreSQL.3701090278" to 0 bytes: Invalid argument
2024-01-16 04:49:29.264 UT
On Sun, Jan 14, 2024 at 2:58 AM Nathan Bossart wrote:
>
> Great. I've attached a v3 with a couple of fixes suggested in the other
> thread [0]. I'll wait a little while longer in case anyone else wants to
> take a look.
The v3 patch looks good to me except for a nitpick: the input
parameter for
On Fri, Jan 12, 2024 at 01:45:55PM -0600, Nathan Bossart wrote:
> On Fri, Jan 12, 2024 at 11:13:46PM +0530, Abhijit Menon-Sen wrote:
>> At 2024-01-12 11:21:52 -0600, nathandboss...@gmail.com wrote:
>>> + Each backend sould obtain a pointer to the reserved shared memo
: https://aws.amazon.com
>From b56931edc4488a7376b27ba0e5519cc3a61b4899 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 11 Jan 2024 21:55:25 -0600
Subject: [PATCH v3 1/1] reorganize shared memory and lwlocks documentation
---
doc/src/sgml/xfunc.sgml | 182 +---
1 file changed, 114 ins
ute the registered shmem_startup_hook shortly
> > after it attaches to shared memory.
That's much better, thanks.
I think the patch could use another pair of eyes, ideally from a
native English speaker. But if no one will express any objections for
a while I suggest merging it.
--
Best regards,
Aleksander Alekseev
1 - 100 of 655 matches
Mail list logo
