On Thu, May 18, 2023 at 01:36:30PM +0900, Michael Paquier wrote:
> The order looks fine seen from here, thanks!
Now that v17 is open for business, I have looked again at this patch.
perlcritic is formulating three complaints:
./src/backend/utils/activity/generate-waiteventtypes.pl: Loop iterator
On 20.06.23 05:46, Michael Paquier wrote:
On Thu, Jun 15, 2023 at 03:52:13PM +0900, Michael Paquier wrote:
It took some time to notice that, which makes me wonder how relevant
this stuff is these days.. Anyway, I would like to do like the others
and fix it, so I am proposing the attached.
Ple
On 14.06.23 20:41, Corey Huinker wrote:
So maybe we should make table_block_relation_estimate_size smarter to
also consider the fillfactor in the "no statistics" branch, per the
attached patch.
I like this a lot. The reasoning is obvious, the fix is simple,it
doesn't upset any make
On 11.04.23 07:58, Michael Paquier wrote:
While doing a few things on Windows with meson, I have noticed that,
while we output some information related to bison after a setup step,
there is nothing about flex.
I think that adding something about flex in the "Programs" section
would be pretty use
On Mon, Jul 3, 2023 at 6:13 PM Peter Eisentraut wrote:
> On 27.06.23 17:02, Tristan Partin wrote:
> > This is a patch which implements an issue discussed in bug #17946[0]. It
> > doesn't fix the overarching issue of the bug, but merely a consistency
> > issue which was found while analyzing code b
On 07.06.23 16:31, Tristan Partin wrote:
This patch is really not necessary from a functional point of view. It
is only necessary if we want to silence a compiler warning.
Tested on `gcc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2)`.
After silencing this warning, all I am left with (given my build
On 27.06.23 17:02, Tristan Partin wrote:
This is a patch which implements an issue discussed in bug #17946[0]. It
doesn't fix the overarching issue of the bug, but merely a consistency
issue which was found while analyzing code by Heikki. I had originally
submitted the patch within that thread, b
Hello,
On Mon, Jul 3, 2023 at 9:10 AM David Rowley wrote:
> Here's the patch which includes those Asserts. I also made some small
> tweaks to a comment.
Thank you for your reply. I am +1 to your change. I think these
assertions will help someone who changes the Bitmapset implementations
in the
On Mon, Jul 3, 2023 at 9:42 AM Amit Kapila wrote:
>
> On Wed, Jun 28, 2023 at 12:02 PM Hayato Kuroda (Fujitsu)
> wrote:
>
> > But in the later patch the tablesync worker tries to reuse the slot during
> > the
> > synchronization, so in this case the application_name should be same as
> > slotna
On Fri, Jun 30, 2023 at 11:00 PM Tom Lane wrote:
> Richard Guo writes:
> > I think it just makes these two assertions meaningless to skip it for
> > non-nestloop joins if the input paths are for otherrels, because paths
> > would never be parameterized by the member relations. So these two
> >
On 28.06.23 23:30, Tomas Vondra wrote:
On 6/28/23 16:52, Peter Eisentraut wrote:
Here are a few patches related to attstattarget:
- 0001: Change type of pg_statistic_ext.stxstattarget, to match
attstattarget. Maybe this should go into PG16, for consistency?
- 0002: Add macro for maximum stati
At Sun, 2 Jul 2023 11:31:56 -0700, Andres Freund wrote in
> The state I currently have is very hacky, but if there's interest in
> upstreaming something like this, I could clean it up.
I can't help voting +1.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On Fri, Jun 02, 2023 at 11:23:19PM +0200, Daniel Gustafsson wrote:
> Absolutely, let's keep these goalposts in place and deal with that separately.
I have not gone back to this part yet, though I plan to do so. As we
are at the beginning of the development cycle, I have applied the
patch to remov
On Fri, Jun 09, 2023 at 02:58:42PM +0900, Michael Paquier wrote:
> FWIW, I'm OK with the patch, without the need to worry about the
> performance. Even if that's the case, we could just mark all these as
> inline and move on..
I am attempting to get all that done for the beginning of the
developm
On Mon, Jun 5, 2023 at 9:48 AM Nikhil Benesch wrote:
>
> I took a look at 0002 because I attempted a similar but more surgical
> fix in [0].
>
> I spotted a few opportunities for further reducing state tracked by
> `ArrayCount`. You may not find all of these suggestions to be
> worthwhile.
I pull
On Wed, Jun 28, 2023 at 12:02 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > > I have analyzed how we handle this. Please see attached the patch (0003)
> > > which
> > > allows reusing connection.
> > >
> >
> > Why did you change the application name during the connection?
>
> It was because the lifetim
On Fri, Jun 30, 2023 at 11:35:46AM -0700, Nathan Bossart wrote:
> On Thu, Jun 29, 2023 at 10:09:21PM -0700, Nathan Bossart wrote:
> > On Thu, Jun 29, 2023 at 08:53:56PM -0400, Tom Lane wrote:
> >> I'm leaning to Robert's thought that we need to revert this for now,
> >> and think harder about how t
On Mon, Jul 3, 2023 at 11:55 AM Masahiko Sawada wrote:
>
> After further investigation, the performance degradation comes from
> calling posix_fallocate() (called via FileFallocate()) and pwritev()
> (called via FileZero) alternatively depending on how many blocks we
> extend by. And it happens on
Hi all,
While testing PG16, I observed that in PG16 there is a big performance
degradation in concurrent COPY into a single relation with 2 - 16
clients in my environment. I've attached a test script that measures
the execution time of COPYing 5GB data in total to the single relation
while changin
Hi,
Commit 89e46da5e5 allowed us to use indexes for searching on REPLICA
IDENTITY FULL tables. The documentation explains:
When replica identity full is specified,
indexes can be used on the subscriber side for searching the rows. Candidate
indexes must be btree, non-partial, and have at least o
At Mon, 03 Jul 2023 10:50:45 +0900 (JST), Kyotaro Horiguchi
wrote in
> For the record, if I understand Nathan correctly, it is what I
> suggested in my initial post. If this is correct, +1 for the suggestion.
>
> me> I think we might want to consider outright rejecting the
> me> estblishment of
At Fri, 30 Jun 2023 19:32:50 +0200, "Drouvot, Bertrand"
wrote in
> Hi,
>
> On 6/30/23 5:54 PM, Tom Lane wrote:
> > Nathan Bossart writes:
> >> After taking another look at this, I wonder if it'd be better to fail
> >> as
> >> soon as we see the database or user name is too long instead of
> >>
On Sun, Jul 2, 2023 at 4:25 AM Noah Misch wrote:
> On Wed, Jun 28, 2023 at 01:02:21PM +1200, Thomas Munro wrote:
> > On Wed, Jun 28, 2023 at 11:03 AM Thomas Munro
> > wrote:
> > > The GCC build farm has just received some SPARC hardware new enough to
> > > run modern Solaris (hostname gcc106), s
On Fri, Jun 23, 2023 at 12:39 PM Dilip Kumar wrote:
>
> On Fri, Jun 9, 2023 at 10:47 AM Masahiko Sawada wrote:
> >
> > Hi,
> >
> > In logical decoding, we don't need to collect decoded changes of
> > aborted transactions. While streaming changes, we can detect
> > concurrent abort of the (sub)tra
On Fri, Jun 30, 2023 at 09:42:13AM +0200, Daniel Gustafsson wrote:
> Agreed, I'd prefer all branches to work the same for this.
Thanks, done this way across all the branches, then.
> Reading the patch, only one thing stood out:
>
> -variable PG_TEST_NOCLEAN is set, data directories will be retai
On Mon, 12 Jun 2023 at 20:20, Richard Guo wrote:
> So now the v2 patch looks good to me.
Thank you for reviewing this. I've just pushed the patch.
David
On Mon, 3 Jul 2023 at 09:27, David Rowley wrote:
> If nobody else wants to take a look, then I plan to push the v4 + the
> asserts in the next day or so.
Here's the patch which includes those Asserts. I also made some small
tweaks to a comment.
I understand that Tom thought that the Asserts wer
Hi Nathan,
On Fri, Jun 30, 2023 at 2:39 PM Nathan Bossart
wrote:
>
> In v4, I've introduced a new BGW_LIBLEN macro and set it to the default
> value of MAXPGPATH (1024). This way, the value can live in bgworker.h like
> the other BGW_* macros do. Plus, this should make the assertion that
> che
On Mon, Jul 3, 2023 at 6:12 AM Tomas Vondra
wrote:
> On 7/2/23 04:09, Thomas Munro wrote:
> > When I added that new error I was thinking about that third case. We
> > generally expect to detect the end of WAL replay after a crash with an
> > error ("invalid record length ...: wanted 24, got 0" +
Andres Freund writes:
> On 2023-07-02 13:55:53 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> I'd like to propose that we do a configure test for __builtin_trap() and use
>>> it, if available, before the abort() in ExceptionalCondition(). Perhaps also
>>> for PANIC, but it's not as clear to
On 7/2/23 14:31, Andres Freund wrote:
Nice things about libbacktrace are that the generation of stack traces is
documented to be async signal safe on most platforms (with a #define to figure
that out, and a more minimal safe version always available) and that it
supports a wide range of platforms
On 6/23/23 08:03, Alexander Pyhalov wrote:
> Tomas Vondra писал 2023-06-22 17:16:
>> On 6/22/23 13:46, Tomas Vondra wrote:
>>> ...
>>>
>>> I haven't tried the reproducer, but I think I see the issue - we store
>>> the bitmap as part of the event to be executed later, but the bitmap is
>>> in per
On Sun, 2023-07-02 at 20:13 +0200, Tomas Vondra wrote:
> FWIW I've pushed the fix prepared by James a couple days ago. Thanks for
> the report!
Thanks, and sorry for being pushy.
Yours,
Laurenz Albe
ne 2. 7. 2023 v 20:32 odesílatel Andres Freund napsal:
> Hi,
>
> I like that we now have a builtin backtrace ability. Unfortunately I think
> the
> backtraces are often not very useful, because only externally visible
> functions are symbolized.
>
> E.g.:
>
> 2023-07-02 10:54:01.756 PDT [1398494]
Hi,
I like that we now have a builtin backtrace ability. Unfortunately I think the
backtraces are often not very useful, because only externally visible
functions are symbolized.
E.g.:
2023-07-02 10:54:01.756 PDT [1398494][client backend][:0][[unknown]] LOG: will
crash
2023-07-02 10:54:01.756
On 6/29/23 13:49, Laurenz Albe wrote:
> On Fri, 2023-06-16 at 00:34 +0200, Tomas Vondra wrote:
>> On 6/15/23 22:36, Tom Lane wrote:
>>> Tomas Vondra writes:
On 6/15/23 22:11, Tom Lane wrote:
> I see zero leakage in that example after applying the attached quick
> hack. (It might b
On 7/2/23 04:09, Thomas Munro wrote:
> On Sun, Jul 2, 2023 at 1:40 AM Tomas Vondra
> wrote:
>> I think there's some sort of bug in how dd38ff28ad deals with
>> contrecords. Consider something as simple as
>>
>> pgbench -i -s 100
>>
>> and then doing pg_waldump on the WAL segments, I get this
Hi,
On 2023-07-02 13:55:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'd like to propose that we do a configure test for __builtin_trap() and use
> > it, if available, before the abort() in ExceptionalCondition(). Perhaps also
> > for PANIC, but it's not as clear to me whether we should.
Andres Freund writes:
> I'd like to propose that we do a configure test for __builtin_trap() and use
> it, if available, before the abort() in ExceptionalCondition(). Perhaps also
> for PANIC, but it's not as clear to me whether we should.
Does that still result in the same process exit signal be
Hi,
When looking at Assert() failures and at PANICs, the number of "pointless"
stack entries at the top seems to have grown over the years. Here's an
example of a stacktrace (that I obviously intentionally triggered):
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementa
Hi,
I was rebasing my meson tree, which has more OSs added to CI, and noticed that
010_database.pl started failing on openbsd recently-ish, without the CI
environment for that having changed.
The tests passed on openbsd when my tree was based on 47b7051bc82
(2023-06-01), but failed after rebasing
Hi,
Improved tab completion for "ALTER DEFAULT PRIVILEGE" and "ALTER TABLE":
1) GRANT, REVOKE and FOR USER keyword was not displayed in tab
completion of alter default privileges like the below statement:
ALTER DEFAULT PRIVILEGES GRANT INSERT ON tables TO PUBLIC;
ALTER DEFAULT PRIVILEGES REVOKE IN
On Fri, Jun 23, 2023 at 12:21 PM Tom Lane wrote:
>
> Tommy Pavlicek writes:
> > I've added a single patch here: https://commitfest.postgresql.org/43/4389/
>
> > It wasn't obvious whether I should create a second commitfest entry
> > because I've included 2 patches so I've just done 1 to begin wit
On 7/2/23 15:23, Tom Lane wrote:
> Andres Freund writes:
>> On 2021-06-11 18:44:28 -0400, Tom Lane wrote:
>>> I suggest what we do is leave it in place for long enough to get
>>> a round of reports from those slow animals, and then (assuming
>>> those reports are positive) drop the test.
>
>> I t
Andres Freund writes:
> On 2021-06-11 18:44:28 -0400, Tom Lane wrote:
>> I suggest what we do is leave it in place for long enough to get
>> a round of reports from those slow animals, and then (assuming
>> those reports are positive) drop the test.
> I think two years later is long enough to hav
The buildfarm animal fairywren has been failing the tests for
pg_basebackup because it can't create a file with a path longer than 255
chars. This has just been tripped because for release 16 it's running
TAP tests, and the branch name is part of the file path, and
"REL_16_STABLE" is longer t
Hi, there...
drop table infomask_test;
CREATE TABLE infomask_test(acc_no integer PRIMARY KEY,amount
numeric,misc text);
INSERT INTO infomask_test VALUES (1, 100.00,default), (2,
200.00,repeat('abc',700));
BEGIN;
SELECT acc_no,ctid,xmin,xmax FROM infomask_test WHERE acc_no = 1 FOR KEY SHARE;
47 matches
Mail list logo
