Hello!
On 19.04.2022 18:46, Nathan Bossart wrote:
Okay, I did it this way in v5.
Recently i ran into a problem that it would be preferable in our
extended pg_stat_statements to use MaxBackEnds in _PG_Init() but it's
equal to zero here.
And i was very happy to find this patch and this thread
Pavel Stehule writes:
> Breakpoint 1, build_hash_table (size=4369066, mstate=0xfc7f08) at
> nodeMemoize.c:268
> 268 if (size == 0)
> (gdb) p size
> $1 = 4369066
Uh-huh
regards, tom lane
pá 6. 5. 2022 v 1:19 odesílatel David Rowley napsal:
> On Thu, 5 May 2022 at 19:26, Pavel Stehule
> wrote:
> >
> > čt 5. 5. 2022 v 8:51 odesílatel Jakub Wartak
> napsal:
> >> > Breakpoint 1, 0x7f557f0c16c0 in mmap64 () from /lib64/libc.so.6
> >> > (gdb) bt
> >> > #0 0x7f557f0c16c0 in m
pá 6. 5. 2022 v 1:28 odesílatel David G. Johnston <
david.g.johns...@gmail.com> napsal:
> On Mon, May 2, 2022 at 10:02 PM Pavel Stehule
> wrote:
>
>>
>>
>> út 3. 5. 2022 v 6:57 odesílatel Tom Lane napsal:
>>
>>> Pavel Stehule writes:
>>> > there is really something strange (see attached file).
Andres Freund writes:
> On 2022-05-05 23:36:22 -0400, Tom Lane wrote:
>> So I reluctantly vote for removing 031_recovery_conflict.pl in the
>> back branches for now, with the expectation that we'll fix the
>> infrastructure and put it back after the current release round
>> is done.
> What about
Hi,
On 2022-05-05 23:36:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-05-05 22:07:40 -0400, Tom Lane wrote:
> >> May I ask where we're at on this? Next week's back-branch release is
> >> getting uncomfortably close, and I'm still seeing various buildfarm
> >> animals erratically
Andres Freund writes:
> On 2022-05-05 22:07:40 -0400, Tom Lane wrote:
>> May I ask where we're at on this? Next week's back-branch release is
>> getting uncomfortably close, and I'm still seeing various buildfarm
>> animals erratically failing on 031_recovery_conflict.pl.
> Looks like the proble
On Tuesday, May 3, 2022 11:31 AM Amit Kapila wrote:
>
> On Tue, May 3, 2022 at 12:10 AM Tomas Vondra
> wrote:
> >
> > On 5/2/22 19:51, Alvaro Herrera wrote:
> > >> Why would we need to know publications replicated by other
> walsenders?
> > >> And what if the subscriber is not connected at the m
Hi,
On 2022-05-05 22:07:40 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Attached is a fix for the test that I think should avoid the problem.
> > Couldn't
> > repro it with it applied, under both rr and valgrind.
>
> May I ask where we're at on this? Next week's back-branch release is
>
On Thu, Apr 28, 2022 at 9:32 PM Amit Kapila wrote:
>
...
>
> Another idea that occurred to me today for tables this is as follows:
> 1. Allow to mention except during create publication ... For All Tables.
> CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT TABLE t1,t2;
> 2. Allow to Reset it. This ne
On Thu, May 05, 2022 at 12:21:41PM +, Godfrin, Philippe E wrote:
>
> Thanks very much for looking closely at this. To answer your questions:
> I misspoke the query file at the time of the queries above was around 1GB.
Ah, that's clearly big enough to lead to some slowdown.
> I don't believe I
Andres Freund writes:
> Attached is a fix for the test that I think should avoid the problem. Couldn't
> repro it with it applied, under both rr and valgrind.
May I ask where we're at on this? Next week's back-branch release is
getting uncomfortably close, and I'm still seeing various buildfarm
On Wed, May 4, 2022 at 7:18 PM Amit Kapila wrote:
>
> On Mon, May 2, 2022 at 8:07 AM Masahiko Sawada wrote:
> >
> > On Mon, May 2, 2022 at 11:32 AM Amit Kapila wrote:
> > >
> > >
> > > So, shall we go back to the previous approach of using a separate
> > > function update_replication_progress?
>
On Mon, May 2, 2022 at 10:02 PM Pavel Stehule
wrote:
>
>
> út 3. 5. 2022 v 6:57 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > there is really something strange (see attached file). Looks so this
>> issue
>> > is much more related to planning time than execution time
>>
>> You sure
On Thu, 5 May 2022 at 19:26, Pavel Stehule wrote:
>
> čt 5. 5. 2022 v 8:51 odesílatel Jakub Wartak napsal:
>> > Breakpoint 1, 0x7f557f0c16c0 in mmap64 () from /lib64/libc.so.6
>> > (gdb) bt
>> > #0 0x7f557f0c16c0 in mmap64 () from /lib64/libc.so.6
>> > #1 0x7f557f04dd91 in sysmalloc
I've completed the first draft of the 14.3 release notes, see
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=66ca1427a4963012fd565b922d0a67a8a8930d1f
As usual, please send comments/corrections by Sunday.
regards, tom lane
Dear Shinya,
Too bad there's no --comment parameter to do COMMENT ON ROLE name IS
'Comment';
As you already make such changes in createuser, I would like to ask for
an additional --comment parameter
that will allow sysadmins to set a comment with additional information
about the new DB user.
Tom Lane wrote on 5/4/2022 5:32 PM:
Peter Eisentraut writes:
On 28.04.22 18:50, Przemysław Sztoch wrote:
Current unnaccent dictionary does not include many popular numeric symbols,
in example: "m²" -> "m2"
Seems reasonable.
It kinda feels like this is outside the charter of an "unaccent"
dic
Peter Eisentraut wrote on 5/4/2022 5:17 PM:
On 28.04.22 18:50, Przemysław Sztoch wrote:
Current unnaccent dictionary does not include many popular numeric
symbols,
in example: "m²" -> "m2"
Seems reasonable.
Can you explain what your patch does to achieve this?
I used an existing python imple
Thank you for the feedback!
>I think we can pass the progress update function to
> WaitForParallelWorkersToFinish(), which seems simpler. And we can call
Directly passing the callback to WaitForParallelWorkersToFinish
will require us to modify the function signature.
To me, it seemed simpl
Hi!
During work on 64-bit XID patch [1] we found handy to have initdb options
to set initial xid/mxid/mxoff values to arbitrary non default values. It
helps test different scenarios: related to wraparound, pg_upgrade from
32-bit XID to 64-bit XID, etc.
We realize, this patch can be singled out as
On Wed, 2022-05-04 at 15:53 +0200, Peter Eisentraut wrote:
> Just saying that cutting it off appears to be acceptable. A bit more
> than 63 bytes should be okay for the log.
Gotcha.
> In terms of aligning what is printed, I meant that pg_stat_ssl uses the
> issuer plus serial number to identify
From: Julien Rouhaud
Sent: Wednesday, May 4, 2022 10:24 PM
To: Godfrin, Philippe E
Cc: pgsql-hackers@lists.postgresql.org
Subject: [EXTERNAL] Re: pg_stat_statements
Hi,
On Tue, May 03, 2022 at 01:30:32PM +, Godfrin, Philippe E wrote:
>
> I wasn't exactly clear about the queries. The value
On Thu, May 5, 2022 at 2:41 PM Alvaro Herrera wrote:
>
> On 2022-May-04, vignesh C wrote:
>
> > On Mon, May 2, 2022 at 5:49 AM Peter Smith wrote:
>
> > > 1. Commit message
> > >
> > > In another thread using the terminology "multi-master" seems to be
> > > causing some problems. Maybe you should
On Mon, May 02, 2022 at 04:06:13PM -0700, Nathan Bossart wrote:
> Here is a new patch set. For now, I've only removed the file existence
> check in writeTimeLineHistoryFile(). I don't know if I'm totally convinced
> that there isn't a problem here (e.g., due to concurrent .ready file
> creation),
On Fri, Apr 29, 2022 at 4:02 PM Alvaro Herrera wrote:
>
> If I read the code right, this patch emits logs when
> pg_logical_slot_get_changes and pg_replication_slot_advance SQL
> functions are called. Is this desirable/useful, for the use case you
> stated at start of thread? I think it is most
On 2022-May-04, vignesh C wrote:
> On Mon, May 2, 2022 at 5:49 AM Peter Smith wrote:
> > 1. Commit message
> >
> > In another thread using the terminology "multi-master" seems to be
> > causing some problems. Maybe you should choose different wording in
> > this commit message to avoid having th
On 2022-May-05, Bharath Rupireddy wrote:
> On Fri, Apr 29, 2022 at 4:11 PM Alvaro Herrera
> wrote:
> >
> > Did we ever consider the idea of using a new pg_stat_wal_activity_progress
> > view or something like that, using the backend_progress.c functionality?
> > I don't see it mentioned in the t
On Fri, Apr 29, 2022 at 4:11 PM Alvaro Herrera wrote:
>
> Did we ever consider the idea of using a new pg_stat_wal_activity_progress
> view or something like that, using the backend_progress.c functionality?
> I don't see it mentioned in the thread.
IMO, progress reporting works well on a running
On Thu, May 5, 2022 at 7:03 AM Tom Lane wrote:
> I wrote:
> > I instrumented the code in setrefs.c, and found that during the
> > core regression tests this patch estimates correctly in 2103
> > places while guessing wrongly in 54, so that seems like a pretty
> > good step forward.
>
> On second
čt 5. 5. 2022 v 8:51 odesílatel Jakub Wartak
napsal:
> Hi Pavel,
>
> > I have not debug symbols, so I have not more details now
> > Breakpoint 1 at 0x7f557f0c16c0
> > (gdb) c
> > Continuing.
>
> > Breakpoint 1, 0x7f557f0c16c0 in mmap64 () from /lib64/libc.so.6
> > (gdb) bt
> > #0 0x7f557
Thanks for making changes from all my past reviews.
1. I checked the cfbot result is OK
2. Both patches apply cleanly in my VM
3. Patch changes
V13-0001 - No diffs; it is identical to v12-0001
V13-0002 - only changed for pg docs. So I rebuilt v13 docs and checked
the HTML rendering. Looked OK.
32 matches
Mail list logo
