On Fri, May 27, 2022 at 10:52 AM Imseih (AWS), Sami wrote:
>
> >Another idea I came up with is that we can wait for all index vacuums
> >to finish while checking and updating the progress information, and
> >then calls WaitForParallelWorkersToFinish after confirming all index
> >
Please find below my review comments for patch v17-0002:
==
1. Commit message
This patch adds a new SUBSCRIPTION parameter "origin". It Specifies whether
the subscription will request the publisher to only send changes that
originated locally, or to send any changes regardless of origin.
Please find below my review comments for patch v17-0001:
==
1. Commit message
Add a missing test to verify only-local option in test_decoding plugin.
"option" -> "parameter"
==
2. contrib/test_decoding/sql/replorigin.sql
2a.
+-- Verify that remote origin data is not returned with
On Thu, Jun 2, 2022 at 9:24 PM John Naylor wrote:
> I had heard of it but not looked into it deeply. I did read that Java
> 7 uses dual pivot quicksort for primitives and timsort for objects. I
> wasn't sure if dual pivot was not good for objects (which could have
> possibly-complex comparators)
On Fri, Jun 3, 2022 at 10:44 AM Peter Geoghegan wrote:
>
> What about dual-pivot quicksort, which is used in Java 7+? That is the
> defacto successor to Bentley & McIlroy. In fact, Jon Bentley himself
> collaborated with its author, and provided benchmarking input. The
> underlying philosophy is
On Fri, Jun 3, 2022 at 10:14 AM David Rowley wrote:
>
> On Wed, 1 Jun 2022 at 03:09, Tom Lane wrote:
> > Right now my vote would be to leave things as they stand for v15 ---
> > the performance loss that started this thread occurs in a narrow
> > enough set of circumstances that I don't feel too
On 2022-06-03 12:29:04 +0900, Michael Paquier wrote:
> On Thu, Jun 02, 2022 at 05:17:34PM -0400, Andrew Dunstan wrote:
> > I hope we fix the original issue soon - it's apparently been the cause
> > of numerous buildfarm failures that it was on my list to investigate
> > e.g.
> >
On Thu, Jun 2, 2022 at 8:33 PM John Naylor wrote:
> Attached is a draft series that implements some but not all features
> of pattern-defeating quicksort, namely the ones I thought were
> interesting for us. Recently this quicksort variant got committed for
> the next release of the Go language
On Thu, Jun 02, 2022 at 05:17:34PM -0400, Andrew Dunstan wrote:
> I hope we fix the original issue soon - it's apparently been the cause
> of numerous buildfarm failures that it was on my list to investigate
> e.g.
>
On Wed, 1 Jun 2022 at 03:09, Tom Lane wrote:
> Right now my vote would be to leave things as they stand for v15 ---
> the performance loss that started this thread occurs in a narrow
> enough set of circumstances that I don't feel too much angst about
> it being the price of winning in most other
Hi,
On 2022-06-02 19:30:16 -0700, Andres Freund wrote:
> On 2021-03-16 18:48:08 +, Stephen Frost wrote:
> > Use pre-fetching for ANALYZE
> >
> > When we have posix_fadvise() available, we can improve the performance
> > of an ANALYZE by quite a bit by using it to inform the kernel of the
> >
Hi,
On 2021-03-16 18:48:08 +, Stephen Frost wrote:
> Use pre-fetching for ANALYZE
>
> When we have posix_fadvise() available, we can improve the performance
> of an ANALYZE by quite a bit by using it to inform the kernel of the
> blocks that we're going to be asking for. Similar to bitmap
On Thu, Jun 2, 2022 at 05:12:49PM +1000, Peter Smith wrote:
> On Thu, Jun 2, 2022 at 12:03 AM Bruce Momjian wrote:
> >
> > On Wed, Jun 1, 2022 at 10:27:27AM +0530, Amit Kapila wrote:
> ...
>
> > My big point is that you should not be showing up with a patch but
> > rather have these
On Thu, Jun 02, 2022 at 09:48:25AM -0700, Andres Freund wrote:
> On 2022-06-01 13:59:06 +0900, Michael Paquier wrote:
>> So, this leads to something like the attached. Does that sound fine
>> to you?
>
> That looks reasonable to me. Do you want to apply it or will you?
Thanks for
On Thu, Jun 02, 2022 at 03:56:28PM -0700, Jacob Champion wrote:
> All right, here's the full list of previous suggestions, I think:
>
> - SharedPort
> - MyProcShared
> - ProcParallelInfo
> - ProcInfoParallel
> - ParallelProcInfo
> - ParallelPortInfo
>
> I have a few new proposals:
>
> -
Hi,
BF animal margay (a newly started Solaris 11.4/Sparc/GCC 11.2 box) is
sometimes failing with:
TRAP: FailedAssertion("seg->mapped_address != NULL", File: "dsm.c",
Line: 1069, PID: 9038)
I can't immediately see why it's doing this, but my tool that looks
for assertion failures hasn't seen
On Thu, Jun 2, 2022 at 5:37 PM David Rowley wrote:
> I had a quick look at that for the problem case and we're very close
> in terms of work_mem size to better performance. A work_mem of just
> 64.3MB brings the performance back to better than PG14.
This is one of the things that I find
On Thu, Jun 2, 2022 at 6:52 AM Robert Haas wrote:
> I'm not sure what it SHOULD be called, exactly: that's one of the hard
> problems in computer science.[1]
Yeah...
All right, here's the full list of previous suggestions, I think:
- SharedPort
- MyProcShared
- ProcParallelInfo
-
Hello,
I was using an object access hook for oat_post_create access while creating
an extension and expected that I would be able to query for the newly
created extension with get_extension_oid(), but it was returning
InvalidOid. However, the same process works for triggers, so I was
wondering
On Thu, Jun 2, 2022 at 6:30 AM Aleksander Alekseev
wrote:
> > I saw there was some previous discussion about dictionary size. It
> > looks like this approach would put all dictionaries into a shared OID
> > pool. Since I don't know what a "standard" use case is, is there any
> > risk of OID
On Thu, Jun 2, 2022 at 9:31 PM David Geier wrote:
> We recently encountered the same bug in the field. Oleksii Kozlov managed to
> come up with reproduction steps, which reliably trigger it. Interestingly,
> the bug does not only manifest as failing assertion, but also as segmentation
> fault;
On Thu, Jun 02, 2022 at 11:12:46AM +0200, Thibaud W. wrote:
> Attached is a small patch to add a description to the meta commands
> regarding
> large objects.
This seems reasonable to me. Your patch wasn't applying for some reason,
so I created a new one with a commit message and some small
On Thu, 2 Jun 2022 at 20:20, John Naylor wrote:
> If anything, changing work_mem is an
> easy to understand (although sometimes not practical) workaround.
I had a quick look at that for the problem case and we're very close
in terms of work_mem size to better performance. A work_mem of just
On 2022-06-01 We 20:37, Michael Paquier wrote:
> On Wed, Jun 01, 2022 at 02:11:12PM -0700, Andres Freund wrote:
>> Until recently TESTDIR needed to point to the build directory containing the
>> binaries. But I'd like to be able to separate test log output from the build
>> tree, so that it's
Hi,
On 2022-06-02 15:53:50 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Oh. I executed maintainer-clean inside src/backend/parser/, and thus didn't
> > see it getting cleaned up.
>
> > It seems pretty darn grotty that src/backend/parser/Makefile explicitly
> > states
> > that gram.c ...
On 2022-06-02 Th 14:06, Robert Haas wrote:
> On Thu, Jun 2, 2022 at 1:17 PM Tom Lane wrote:
>> Point 2 would cause every existing pg_dumpall script to fail, which
>> seems like kind of a large gotcha. Less unpleasant alternatives
>> could include
>>
>> * Continue to accept the syntax, but
On 2022-06-01 We 21:37, Michael Paquier wrote:
> On Thu, Jun 02, 2022 at 04:22:52AM +0300, Anton A. Melnikov wrote:
>> Found out that test for pg_upgrade (test.sh for 11-14 and 002_pg_upgrade.pl
>> for 15+) doesn't work from 10th versions to higher ones due to incompatible
>> options for initdb
On Thu, Jun 2, 2022 at 3:51 PM Tom Lane wrote:
> > I sort of thought http://postgr.es/m/3981966.1646429...@sss.pgh.pa.us
> > constituted a completed investigation of this sort. No?
>
> I didn't think so. It's clear that the spec expects us to track the
> grantor, but I didn't chase down what it
On Thu, Jun 02, 2022 at 03:37:34PM -0400, Robert Haas wrote:
> On Thu, Jun 2, 2022 at 2:07 PM Nathan Bossart
> wrote:
>> I think we should also consider replacing role attributes with predefined
>> roles. I'm not sure that this proposal totally prepares us for such a
>> change, given role
Andres Freund writes:
> Oh. I executed maintainer-clean inside src/backend/parser/, and thus didn't
> see it getting cleaned up.
> It seems pretty darn grotty that src/backend/parser/Makefile explicitly states
> that gram.c ... aren't cleaned "here", but then src/backend/Makefile does
> clean
Robert Haas writes:
> On Thu, Jun 2, 2022 at 3:15 PM Tom Lane wrote:
>> Maybe. What I was pointing out is that this is SQL-standard syntax
>> and there are SQL-standard semantics that it ought to be implementing.
>> Probably those semantics match what you describe here, but we ought
>> to dive
On Thu, Jun 2, 2022 at 3:15 PM Tom Lane wrote:
> Maybe. What I was pointing out is that this is SQL-standard syntax
> and there are SQL-standard semantics that it ought to be implementing.
> Probably those semantics match what you describe here, but we ought
> to dive into the spec and make sure
On Thu, Jun 2, 2022 at 2:07 PM Nathan Bossart wrote:
> I think we should also consider replacing role attributes with predefined
> roles. I'm not sure that this proposal totally prepares us for such a
> change, given role attributes apply only to the specific role for which
> they are set and
Hi,
On 2022-06-02 15:05:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-06-02 13:33:51 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> (*) do we really not have a target that removes bison / flex output?
>
> >> maintainer-clean
>
> > Don't think so:
>
> See about line
Robert Haas writes:
> On Fri, Mar 4, 2022 at 4:34 PM Tom Lane wrote:
>> If we are not tracking the grantors of role authorizations,
>> then we are doing it wrong and we ought to fix that.
> So let's talk about how we could fix this. In a vacuum I'd say this is
> just a feature that never got
Andres Freund writes:
> On 2022-06-02 13:33:51 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> (*) do we really not have a target that removes bison / flex output?
>> maintainer-clean
> Don't think so:
See about line 300 in src/backend/Makefile. In any case, it's
easy to show by
On Fri, Mar 4, 2022 at 4:34 PM Tom Lane wrote:
> If we are not tracking the grantors of role authorizations,
> then we are doing it wrong and we ought to fix that.
We are definitely doing it wrong. It's not that we aren't doing it at
all, but we are doing it incorrectly. If user foo executes
On Thu, Jun 02, 2022 at 12:26:48PM -0400, Robert Haas wrote:
> On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
>> > It seems to me that the INHERIT role flag isn't very well-considered.
>> > Inheritance, or the lack of it, ought to be decided separately for
>> > each inherited role. However,
On Thu, Jun 2, 2022 at 1:17 PM Tom Lane wrote:
> Point 2 would cause every existing pg_dumpall script to fail, which
> seems like kind of a large gotcha. Less unpleasant alternatives
> could include
>
> * Continue to accept the syntax, but ignore it, maybe with a WARNING
> for the alternative
Hi,
On 2022-06-02 13:33:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > (*) do we really not have a target that removes bison / flex output?
>
> maintainer-clean
Don't think so:
# gram.c, gram.h, and scan.c are in the distribution tarball, so they
# are not cleaned here.
clean distclean
Andres Freund writes:
> (*) do we really not have a target that removes bison / flex output?
maintainer-clean
regards, tom lane
Hi,
On 2022-06-02 13:08:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm not quite sure what the proper behaviour is when doing an out-of-tree
> > build with meson (all builds are out-of-tree), with a pre-existing flex /
> > bison output in the source tree that is out of date.
>
>
Robert Haas writes:
> Is this a kind of change people would support? Here's a quick sketch:
> 1. Extend the GRANT role_name TO role_name [ WITH ADMIN OPTION ] with
> a new, optional clause, something like WITH NO INHERIT or WITH
> NOINHERIT or WITHOUT INHERIT.
> 2. Remove the INHERIT | NOINHERIT
Andres Freund writes:
> I'm not quite sure what the proper behaviour is when doing an out-of-tree
> build with meson (all builds are out-of-tree), with a pre-existing flex /
> bison output in the source tree that is out of date.
Definitely sounds like a gotcha.
On the one hand, there's been
Hi,
On 2022-06-01 13:59:06 +0900, Michael Paquier wrote:
> On Tue, May 31, 2022 at 01:58:25PM +0900, Michael Paquier wrote:
> > Why don't you just use src/interfaces/ instead of adding a direct
> > path to libpq?
>
> So, this leads to something like the attached. Does that sound fine
> to you?
Hi,
On 2022-05-29 10:18:50 -0500, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> > On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not
> > > to?
> >
> > Pushed.
>
> If I'm not
Hi,
On 2022-06-01 12:39:50 +0300, Aleksander Alekseev wrote:
> > > ```
> > > ../src/include/parser/kwlist.h:332:25: error: ‘PARAMETER’ undeclared here
> > > (not
> > > in a function)
> > > 332 | PG_KEYWORD("parameter", PARAMETER, UNRESERVED_KEYWORD, BARE_LABEL)
> > >
> > >
Andres Freund writes:
> I tried to use -Og many times, but in the end mostly gave up, because it still
> makes debugging harder compared to -O0.
Yeah. My own habit is to build with -O2 normally. If I'm trying to
debug some bit of code and find that I can't follow things adequately
in gdb, I
On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
> > It seems to me that the INHERIT role flag isn't very well-considered.
> > Inheritance, or the lack of it, ought to be decided separately for
> > each inherited role. However, that would be a major architectural
> > change.
>
> Agreed -- that
On Thu, Jun 2, 2022 at 5:08 AM Etsuro Fujita
wrote:
> On Wed, Apr 6, 2022 at 3:58 PM Etsuro Fujita
> wrote:
> > I have committed the patch after modifying it as such.
>
> The patch calls trivial_subqueryscan() during create_append_plan() to
> determine the triviality of a SubqueryScan that is a
Hi,
On 2022-06-02 15:34:23 +0300, Aleksander Alekseev wrote:
> Hi Andres,
>
> > Cool. I think I pushed a fix/workaround for the issue now. Still can't
> > decide
> > whether it's apple's or meson's fault.
>
> Many thanks! The fix solved the problem, I can compile with -Dldap=enabled
> now.
>
Hi,
On 2022-06-02 01:09:58 -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > forking: <20220302205058.gj15...@telsasoft.com>: Re: Adding CI to our tree
> > On Wed, Mar 02, 2022 at 02:50:58PM -0600, Justin Pryzby wrote:
> >> BTW (regarding the last patch), I just noticed that -Og optimization
Hi,
On 2022-06-02 10:33:52 -0400, Tom Lane wrote:
> Matthias van de Meent writes:
> > On Thu, 2 Jun 2022, 07:10 Tom Lane, wrote:
> >> I'm a little dubious about whether -Og is a case we should pay special
> >> attention to?
>
> > The "Developer FAQ" page on the wiki suggests that when you
Hi,
On 2022-06-02 13:24:28 +0900, Michael Paquier wrote:
> On Wed, Jun 01, 2022 at 09:42:44PM -0500, Justin Pryzby wrote:
> > Today's "warnings" thread suggests to me that these are worth fixing - it
> > seems
> > reasonable to compile postgres 14 on centos7 (as I sometimes have done), and
> >
On Tue, 31 May 2022 at 12:00, Vladimir Sitnikov
wrote:
>
> Please, do not suggest me avoid 65535 parameters. What I wanted was just to
> test that the driver was able to handle 65535 parameters.
I don't think we have regression tests to cover things at these
limits, that might be worth adding
Matthias van de Meent writes:
> On Thu, 2 Jun 2022, 07:10 Tom Lane, wrote:
>> I'm a little dubious about whether -Og is a case we should pay special
>> attention to?
> The "Developer FAQ" page on the wiki suggests that when you develop
> with gcc that you use CFLAGS="-ggdb -Og -g3
On Thu, 2 Jun 2022, 07:10 Tom Lane, wrote:
>
> Justin Pryzby writes:
> > forking: <20220302205058.gj15...@telsasoft.com>: Re: Adding CI to our tree
> > On Wed, Mar 02, 2022 at 02:50:58PM -0600, Justin Pryzby wrote:
> >> BTW (regarding the last patch), I just noticed that -Og optimization can
>
On Tue, May 31, 2022 at 6:21 PM Jacob Champion wrote:
> v10 is rebased over latest; I've also added a PGDLLIMPORT to the new global.
I took a quick look at this and it doesn't seem crazy to me, except
that I think ParallelProcInfo is a bad name for it. It's kind of
generic, because neither
> On 2 Jun 2022, at 07:09, Tom Lane wrote:
> I'm a little dubious about whether -Og is a case we should pay special
> attention to? Our standard optimization setting for gcc is -O2, and
> once you go away from that there are any number of weird cases that
> may or may not produce warnings.
I
Hi Jacob,
Many thanks for your feedback!
> I saw there was some previous discussion about dictionary size. It
> looks like this approach would put all dictionaries into a shared OID
> pool. Since I don't know what a "standard" use case is, is there any
> risk of OID exhaustion for larger
Hi Andres,
> Cool. I think I pushed a fix/workaround for the issue now. Still can't decide
> whether it's apple's or meson's fault.
Many thanks! The fix solved the problem, I can compile with -Dldap=enabled now.
The code passes the tests too.
> > $ meson configure -Dldap=disabled
> > $ meson
On Wed, Apr 6, 2022 at 3:58 PM Etsuro Fujita wrote:
> I have committed the patch after modifying it as such.
The patch calls trivial_subqueryscan() during create_append_plan() to
determine the triviality of a SubqueryScan that is a child of an
Append node. Unlike when calling it from
On Fri, May 27, 2022 at 1:04 PM houzj.f...@fujitsu.com
wrote:
>
> On Friday, May 27, 2022 1:54 PM Justin Pryzby wrote:
> >
> > On Fri, May 27, 2022 at 11:17:00AM +0530, Amit Kapila wrote:
> > > On Tue, May 24, 2022 at 11:03 AM houzj.f...@fujitsu.com
> > wrote:
> > > >
> > > > On Friday, May 20,
On Thu, May 5, 2022 at 4:30 PM Richard Guo wrote:
> On Thu, May 5, 2022 at 7:03 AM Tom Lane wrote:
>> 1015 improvements to 14 disimprovements isn't a bad score. I'm
>> a bit surprised there are that many removable SubqueryScans TBH;
>> maybe that's an artifact of all the "SELECT *" queries.
>
Fr, 27/05/2022 в 10:51 -0400, Tom Lane writes:
> Yura Sokolov writes:
> > В Вт, 24/05/2022 в 17:39 -0700, Andres Freund пишет:
> > > A variation on your patch would be to only store the offset to the block
> > > header - that should always fit into 32bit (huge allocations being their
> > > own
>
On Thu, Jun 2, 2022 at 6:14 PM Etsuro Fujita wrote:
> On Thu, Jun 2, 2022 at 10:23 AM Amit Langote wrote:
> > On Wed, Jun 1, 2022 at 6:15 PM Etsuro Fujita
> > wrote:
> > > On Tue, May 31, 2022 at 9:35 PM Robert Haas wrote:
> > > > I would probably just update the synopsis. It's not very hard
On Sun, May 29, 2022 8:25 PM osumi.takami...@fujitsu.com
wrote:
> Hi,
>
>
> Some review comments on the new patches from v6-0001 to v6-0004.
Thanks for your comments.
>
>
> (1) create_subscription.sgml
>
> + the transaction is committed. Note that if an error happens when
> +
On Mon, May 30, 2022 7:38 PM Amit Kapila wrote:
> Few comments/suggestions for 0001 and 0003
> =
> 0001
>
Thanks for your comments.
> 1.
> + else
> + snprintf(bgw.bgw_name, BGW_MAXLEN,
> + "logical replication apply worker for subscription %u",
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Hi all,
We recently encountered the same bug in the field.
On Thu, Jun 2, 2022 at 10:23 AM Amit Langote wrote:
> On Wed, Jun 1, 2022 at 6:15 PM Etsuro Fujita wrote:
> > On Tue, May 31, 2022 at 9:35 PM Robert Haas wrote:
> > > I would probably just update the synopsis. It's not very hard to
> > > figure out what's likely to happen even without clicking
Hello,
Attached is a small patch to add a description to the meta commands
regarding
large objects.
the actual description when using psql --help=commands is :
Large Objects
\lo_export LOBOID FILE
\lo_import FILE [COMMENT]
\lo_list
\lo_unlink LOBOID large object operations
I ran a shorter version of David's script with just 6-9 attributes to
try to reproduce the problem area (spreadsheet with graph attached).
My test is also different in that I compare HEAD with just reverting
40af10b57. This shows a 60% increase in HEAD in runtime for 64MB
workmem and 64 byte
Hi Nathan,
> > NVMe devices have a maximum queue length of 64k:
[..]
> > but our effective_io_concurrency maximum is 1,000:
[..]
> > Should we increase its maximum to 64k? Backpatched? (SATA has a
> > maximum queue length of 256.)
>
> If there are demonstrable improvements with higher values,
On Thu, Jun 2, 2022 at 12:03 AM Bruce Momjian wrote:
>
> On Wed, Jun 1, 2022 at 10:27:27AM +0530, Amit Kapila wrote:
...
> My big point is that you should not be showing up with a patch but
> rather have these discussions to get agreement that this is the
> direction the community wants to go.
On Tue, 10 May 2022 18:49:54 +0530
Ashutosh Bapat wrote:
> If we add that information to EXPLAIN output, the user won't need
> access to server logs.
>
> May be we need it in both the places.
That sounds a nice idea. But I don't think that postgres shows in the
EXPLAIN output why the plan is
On Wed, Jun 1, 2022 at 7:33 PM Bruce Momjian wrote:
>
> On Wed, Jun 1, 2022 at 10:27:27AM +0530, Amit Kapila wrote:
> > On Tue, May 31, 2022 at 7:36 PM Bruce Momjian wrote:
> > > Uh, thinking some more, why would anyone set things up this way ---
> > > having part of a table being primary on
76 matches
Mail list logo
