| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | Re: replication slot stats memory bug |
| Date: | 2021-03-18 01:51:05 |
| Message-ID: | 20210318015105.dcfa4ceybdjubf2i@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-03-17 19:36:46 -0400, Tom Lane wrote:
> > But it seems like we just shouldn't allocate it dynamically at all?
> > max_replication_slots doesn't change during postmaster lifetime, so it
> > seems like it should just be allocated once?
>
> Meh. I don't see a need to wire in such an assumption here.
It does make it easier for the shared memory stats patch, because if
there's a fixed number + location, the relevant stats reporting doesn't
need to go through a hashtable with the associated locking. I guess
that may have colored my perception that it's better to just have a
statically sized memory allocation for this. Noteworthy that SLRU stats
are done in a fixed size allocation as well...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Japin Li | 2021-03-18 01:51:09 | Re: EXPLAIN/EXPLAIN ANALYZE REFRESH MATERIALIZED VIEW |
| Previous Message | Andres Freund | 2021-03-18 01:48:12 | Re: Permission failures with WAL files in 13~ on Windows |