On Mon, Oct 02, 2023 at 10:22:06AM +0200, Jakub Wartak wrote:
> I've attached v4 that covers your suggestions.
Hmm. I was looking at all that and pondered quite a bit about the
addition of the restriction when starting up the server, particularly
why there would be any need to include it in the s
On Fri, Sep 29, 2023 at 4:00 AM Michael Paquier wrote:
>
> On Thu, Sep 28, 2023 at 11:01:14AM +0200, Jakub Wartak wrote:
> > v3 attached. I had a problem coming out with a better error message,
> > so suggestions are welcome. The cast still needs to be present as per
> > above suggestion as 3GB i
On Thu, Sep 28, 2023 at 11:01:14AM +0200, Jakub Wartak wrote:
> v3 attached. I had a problem coming out with a better error message,
> so suggestions are welcome. The cast still needs to be present as per
> above suggestion as 3GB is still valid buf size and still was causing
> integer overflow. W
On Thu, Sep 28, 2023 at 12:53 AM Michael Paquier wrote:
>
> On Wed, Sep 27, 2023 at 10:29:25AM -0700, Andres Freund wrote:
> > I don't think going for size_t is a viable path for fixing this. I'm pretty
> > sure the initial patch would trigger a type mismatch from guc_tables.c - we
> > don't have
Hi,
On 2023-09-28 07:53:45 +0900, Michael Paquier wrote:
> On Wed, Sep 27, 2023 at 10:29:25AM -0700, Andres Freund wrote:
> > Frankly, it seems like a quite bad idea to have such a high limit for
> > pgstat_track_activity_query_size. The overhead such a high value has will
> > surprise people...
>
On Wed, Sep 27, 2023 at 10:29:25AM -0700, Andres Freund wrote:
> I don't think going for size_t is a viable path for fixing this. I'm pretty
> sure the initial patch would trigger a type mismatch from guc_tables.c - we
> don't have infrastructure for size_t GUCs.
Nothing marked as PGDLLIMPORT uses
Hi,
On 2023-09-27 15:42:15 +0100, Peter Eisentraut wrote:
> On 27.09.23 09:08, Michael Paquier wrote:
> > On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote:
> > > Attached patch adjusts pgstat_track_activity_query_size to be of
> > > size_t from int and fixes the issue.
> >
> > This ca
On 27.09.23 09:08, Michael Paquier wrote:
On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote:
Attached patch adjusts pgstat_track_activity_query_size to be of
size_t from int and fixes the issue.
This cannot be backpatched, and using size_t is not really needed as
track_activity_quer
On Wed, Sep 27, 2023 at 10:08 AM Michael Paquier wrote:
>
> On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote:
> > Attached patch adjusts pgstat_track_activity_query_size to be of
> > size_t from int and fixes the issue.
>
> This cannot be backpatched, and using size_t is not really nee
On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote:
> Attached patch adjusts pgstat_track_activity_query_size to be of
> size_t from int and fixes the issue.
This cannot be backpatched, and using size_t is not really needed as
track_activity_query_size is capped at 1MB. Why don't you ju
Hi -hackers,
We've got customer report that high max_connections (3k) with high
pgstat_track_activity_query_size (1MB) ends up with:
postgres=# select * from pg_stat_get_activity(NULL);
ERROR: invalid memory alloc request size 18446744072590721024
postgres=# select version();
11 matches
Mail list logo
