Re: Privileges on PUBLICATION

Peter Eisentraut wrote: > The CF entry is about privileges on publications. Please rebase that patch > and repost it so that the CF app and the CF bot are up to date. The rebased patch (with regression tests added) is attached here. There's still one design issue that I haven't mentioned yet:

Re: Incorrect include file order in guc-file.l

On Wed, Nov 2, 2022 at 1:01 PM Julien Rouhaud wrote: > > Hi, > > On Wed, Nov 02, 2022 at 02:29:50PM +0900, Michael Paquier wrote: > > > > While reviewing a different patch, I have noticed that guc-file.l > > includes sys/stat.h in the middle of the PG internal headers. The > > usual practice is

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Mon, Oct 31, 2022 at 12:47 PM Masahiko Sawada wrote: > > I've attached v8 patches. 0001, 0002, and 0003 patches incorporated > the comments I got so far. 0004 patch is a DSA support patch for PoC. Thanks for the new patchset. This is not a full review, but I have some comments: 0001 and 0002

Re: [BUG] Logical replica crash if there was an error in a function.

On Wed, Nov 2, 2022 at 11:32 PM Tom Lane wrote: > > So I'm now good with the idea of just not failing. I don't like > the patch as presented though. First, the cfbot is quite rightly > complaining about the "uninitialized variable" warning it draws. > Second, I don't see a good reason to tie

Re: proposal: possibility to read dumped table's name from file

Hi, On Wed, Oct 26, 2022 at 06:26:26AM +0200, Pavel Stehule wrote: > > út 18. 10. 2022 v 11:33 odesílatel Julien Rouhaud > napsal: > > > > > I'm wondering if psql's parse_identifier() could be exported and reused > > here > > rather than creating yet another version. > > > > I looked there, and

Re: Commit fest 2022-11

2022年11月2日(水) 19:10 Greg Stark : > > On Tue, 1 Nov 2022 at 06:56, Michael Paquier wrote: > > > Two people showing up to help is really great, thanks! I'll be around > > as well this month, so I'll do my share of patches, as usual. > > Fwiw I can help as well -- starting next week. I can't do

Re: Improve logging when using Huge Pages

On Wed, Aug 3, 2022 at 8:42 PM Shinoda, Noriyoshi (PN Japan FSIP) wrote: > > As discussed in [1], we're taking this opportunity to return some patchsets > > that don't appear to be getting enough reviewer interest. > Thank you for your helpful comments. > As you say, my patch doesn't seem to be

Re: perl 5.36, C99, -Wdeclaration-after-statement -Wshadow=compatible-local

Hi, On 2022-11-02 19:57:45 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2022-11-01 17:00:27 -0400, Peter Eisentraut wrote: > >> Python has the same issues. There are a few other Python-embedding > >> projects > >> that use -Wdeclaration-after-statement and complain if the Python

Re: perl 5.36, C99, -Wdeclaration-after-statement -Wshadow=compatible-local

Andres Freund writes: > On 2022-11-01 17:00:27 -0400, Peter Eisentraut wrote: >> Python has the same issues. There are a few other Python-embedding projects >> that use -Wdeclaration-after-statement and complain if the Python headers >> violate it. But it's getting tedious. -isystem would be a

Re: perl 5.36, C99, -Wdeclaration-after-statement -Wshadow=compatible-local

Hi, On 2022-11-01 17:00:27 -0400, Peter Eisentraut wrote: > On 01.11.22 19:01, Andres Freund wrote: > > I don't know how much longer we can rely on headers being > > -Wdeclaration-after-statement clean, my impression is that people don't > > have a > > lot of patience for C89isms anymore. > > >

Re: spinlock support on loongarch64

On 2022-11-02 17:37:04 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2022-11-02 14:55:04 -0400, Tom Lane wrote: > >> After actually testing (by removing the ARM stanza on a macOS machine), > >> it seems that placement doesn't work, because of the default definition > >> of S_UNLOCK at the

Re: spinlock support on loongarch64

Andres Freund writes: > On 2022-11-02 14:55:04 -0400, Tom Lane wrote: >> After actually testing (by removing the ARM stanza on a macOS machine), >> it seems that placement doesn't work, because of the default definition >> of S_UNLOCK at the bottom of the "#if defined(__GNUC__)" stuff. Putting

Re: pg_dump: Refactor code that constructs ALTER ... OWNER TO commands

On 01.11.22 13:59, Corey Huinker wrote: On Mon, Oct 24, 2022 at 5:54 AM Peter Eisentraut > wrote: Avoid having to list all the possible object types twice.  Instead, only _getObjectDescription() needs to know about specific object types. 

Re: spinlock support on loongarch64

Hi, On 2022-11-02 14:55:04 -0400, Tom Lane wrote: > I wrote: > > So about like this, then. > > After actually testing (by removing the ARM stanza on a macOS machine), > it seems that placement doesn't work, because of the default definition > of S_UNLOCK at the bottom of the "#if

Re: create subscription - improved warning message

On Wed, Nov 2, 2022 at 9:02 PM Amit Kapila wrote: > > On Wed, Oct 19, 2022 at 10:10 AM Peter Smith wrote: > > > > Thanks for your testing. > > > > LGTM so pushed with a minor change in one of the titles in the Examples > section. > Thanks for pushing. -- Kind Regards, Peter Smith. Fujitsu

Re: Prefetch the next tuple's memory during seqscans

Hi, On 2022-11-02 10:25:44 -0700, Andres Freund wrote: > server is started with > local: numactl --membind 1 --physcpubind 10 > remote: numactl --membind 0 --physcpubind 10 > interleave: numactl --interleave=all --physcpubind 10 Argh, forgot to say that this is with

Re: pg_basebackup's --gzip switch misbehaves

> On 16 Sep 2022, at 04:22, Michael Paquier wrote: > By the way, should we document PG_TEST_TIMEOUT_DEFAULT and > PG_TEST_NOCLEAN not only in src/test/perl/README but also doc/?. We > provide something in the docs about PROVE_FLAGS and PROVE_TESTS, for > example. I think that's a good idea,

Re: Check SubPlan clause for nonnullable rels/Vars

Richard Guo writes: > While wandering around the codes of reducing outer joins, I noticed that > when determining which base rels/Vars are forced nonnullable by given > clause, we don't take SubPlan into consideration. Does anyone happen to > know what is the concern behind that? Probably just

Re: ssl tests aren't concurrency safe due to get_free_port()

On 2022-10-17 Mo 10:59, Andrew Dunstan wrote: > On 2022-10-04 Tu 01:39, Andrew Dunstan wrote: >> On 2022-10-02 Su 12:49, Andres Freund wrote: >>> 2) Use a lockfile containing a pid to protect the choice of a port within a >>>build directory. Before accepting a port get_free_port() would check

Re: libpq support for NegotiateProtocolVersion

A few notes: > + else if (beresp == 'v') > + { > + if > (pqGetNegotiateProtocolVersion3(conn)) > + { > + /* We'll come back

Re: spinlock support on loongarch64

I wrote: > So about like this, then. After actually testing (by removing the ARM stanza on a macOS machine), it seems that placement doesn't work, because of the default definition of S_UNLOCK at the bottom of the "#if defined(__GNUC__)" stuff. Putting it inside that test works, and seems like

Re: spinlock support on loongarch64

Andres Freund writes: > On 2022-11-02 11:37:35 -0400, Tom Lane wrote: >> I wonder if we shouldn't just do that (ie, try to use >> __sync_lock_test_and_set) as a generic fallback on any unsupported >> architecture. We could get rid of the separate stanza for RISC-V >> that way. The main thing

Re: pg15 inherited stats expressions: cache lookup failed for statistics object

On Tue, Nov 01, 2022 at 02:35:43PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > I added a CF entry and marked RFC. > > This should be included in v15.1. > > Right, done. Thanks. Yesterday, I realized that the bug was exposed here after we accidentally recreated a table as relkind=r

Re: [BUG] Logical replica crash if there was an error in a function.

Michael Paquier writes: > Yeah, the query string is not available in this context, but it surely > looks wrong to me to assume that something as low-level as > function_parse_error_transpose() needs to be updated for the sake of a > logical worker, while we have other areas that would expect a

Re: Glossary and initdb definition work for "superuser" and database/cluster

On Tue, Nov 1, 2022 at 6:59 PM David G. Johnston wrote: > > P.S. I'm now looking at the very first paragraph to initdb more closely, > not liking "single server instance" all that much and wondering how to fit > in "cluster user" there - possibly by saying something like "...managed by > a

Re: spinlock support on loongarch64

Hi, On 2022-11-02 11:37:35 -0400, Tom Lane wrote: > =?gb2312?B?zuLRx7fJ?= writes: > > add spinlock support on loongarch64. > > I wonder if we shouldn't just do that (ie, try to use > __sync_lock_test_and_set) as a generic fallback on any unsupported > architecture. We could get rid of the

Re: Prefetch the next tuple's memory during seqscans

Hi, On 2022-11-01 20:00:43 -0700, Andres Freund wrote: > I suspect that prefetching in heapgetpage() would provide gains as well, at > least for pages that aren't marked all-visible, pretty common in the real > world IME. Attached is an experimental patch/hack for that. It ended up being more

Re: Error for row-level triggers with transition tables on partitioned tables

Etsuro Fujita writes: > We do not currently allow row-level triggers on partitions to have > transition tables either, and the error message for that is “ROW > triggers with transition tables are not supported on partitions.”. > How about changing the DETAIL message to something similar to this >

Re: Add index scan progress to pg_stat_progress_vacuum

Attached is v13-0001--Show-progress-for-index-vacuums.patch which addresses the latest comments. The main changes are: 1/ Call the parallel_vacuum_progress_report inside the AMs rather than vacuum_delay_point. 2/ A Boolean when set to True in vacuumparallel.c will be used to determine if

Re: Segfault on logical replication to partitioned table with foreign children

Since we're getting pretty close to the next set of back-branch releases, I went ahead and pushed a minimal fix along the lines suggested by Shi Yu. (I realized that there's a second ExecFindPartition call in worker.c that also needs a check.) We still can at leisure think about refactoring

Re: psql: Add command to use extended query protocol

On Wed, 02 Nov 2022 16:04:02 +0100 "Daniel Verite" wrote: > Jehan-Guillaume de Rorthais wrote: > > > As I wrote in my TCE review, would it be possible to use psql vars to set > > some named parameters for the prepared query? This would looks like: > > > > \set p1 foo > > \set p2 bar >

Re: spinlock support on loongarch64

=?gb2312?B?zuLRx7fJ?= writes: > add spinlock support on loongarch64. I wonder if we shouldn't just do that (ie, try to use __sync_lock_test_and_set) as a generic fallback on any unsupported architecture. We could get rid of the separate stanza for RISC-V that way. The main thing that an

Re: Check return value of pclose() correctly

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hi Peter, This is a review of the pclose return value check

Re: psql: Add command to use extended query protocol

Jehan-Guillaume de Rorthais wrote: > As I wrote in my TCE review, would it be possible to use psql vars to set > some > named parameters for the prepared query? This would looks like: > > \set p1 foo > \set p2 bar > SELECT :'p1', :'p2' \gp As I understand the feature, variables would

Re: restoring user id and SecContext before logging error in ri_PlanCheck

Looking down in ri_PerformCheck(), I see there may be case where error from SPI_execute_snapshot() would skip restoring UID. Please look at patch v2 which tried to handle such case. Thanks v2-restore-uid-trigger.patch Description: Binary data

Re: Support logical replication of DDLs

On Mon, 31 Oct 2022 at 16:17, vignesh C wrote: > > On Thu, 27 Oct 2022 at 16:02, vignesh C wrote: > > > > On Thu, 27 Oct 2022 at 02:09, Zheng Li wrote: > > > > > > > Adding support for deparsing of CREATE/ALTER/DROP LANGUAGE for ddl > > > > replication. > > > > > > Adding support for deparsing

restoring user id and SecContext before logging error in ri_PlanCheck

Hi, I was looking at the code in ri_PlanCheck of src/backend/utils/adt/ri_triggers.c starting at line 2289. When qplan is NULL, we log an error. This would skip calling SetUserIdAndSecContext(). I think the intention of the code should be restoring user id and SecContext regardless of the

Re: Temporary tables versus wraparound... again

On Sun, 8 Nov 2020 at 18:19, Greg Stark wrote: > > We had an outage caused by transaction wraparound. And yes, one of the > first things I did on this site was check that we didn't have any > databases that were in danger of wraparound. Fwiw this patch has been in "Ready for Committer" state

Re: Add LZ4 compression in pg_dump

Checking if you'll be able to submit new patches soon ?

Re: Allow file inclusion in pg_hba and pg_ident files

On Wed, Nov 02, 2022 at 04:46:48PM +0900, Michael Paquier wrote: > On Fri, Oct 28, 2022 at 11:49:54AM +0800, Julien Rouhaud wrote: > > To be honest I'd rather not to. It's excessively annoying to work on those > > tests (I spent multiple days trying to make it as clean and readable as > >

Re: psql: Add command to use extended query protocol

st 2. 11. 2022 v 13:43 odesílatel Jehan-Guillaume de Rorthais < j...@dalibo.com> napsal: > Hi, > > On Fri, 28 Oct 2022 08:52:51 +0200 > Peter Eisentraut wrote: > > > This adds a new psql command \gp that works like \g (or semicolon) but > > uses the extended query protocol. Parameters can also

Re: psql: Add command to use extended query protocol

Hi, On Fri, 28 Oct 2022 08:52:51 +0200 Peter Eisentraut wrote: > This adds a new psql command \gp that works like \g (or semicolon) but > uses the extended query protocol. Parameters can also be passed, like > > SELECT $1, $2 \gp 'foo' 'bar' As I wrote in my TCE review, would it be

spinlock support on loongarch64

add spinlock support on loongarch64. 0001-spinlock-support-on-loongarch64.patch Description: 0001-spinlock-support-on-loongarch64.patch

Re: Make ON_ERROR_STOP stop on shell script failure

On Fri, Sep 16, 2022 at 03:55:33PM +0900, bt22nakamorit wrote: > Hi, > > """\set ON_ERROR_STOP on""" stops any subsequent incoming query that comes > after an error of an SQL, but does not stop after a shell script ran by > """\! """ returning values other than 0, -1, or 127, which > suggests a

Re: Commit fest 2022-11

On Tue, 1 Nov 2022 at 06:56, Michael Paquier wrote: > Two people showing up to help is really great, thanks! I'll be around > as well this month, so I'll do my share of patches, as usual. Fwiw I can help as well -- starting next week. I can't do much this week though. I would suggest starting

Re: create subscription - improved warning message

On Wed, Oct 19, 2022 at 10:10 AM Peter Smith wrote: > > Thanks for your testing. > LGTM so pushed with a minor change in one of the titles in the Examples section. -- With Regards, Amit Kapila.

Re: [PoC] Reducing planning time when tables have many partitions

Hello, I noticed that the previous patch does not apply to the current HEAD. I attached the rebased version to this email. -- Best regards, Yuya Watari v8-0001-Apply-eclass_member_speedup_v3.patch.patch Description: Binary data v8-0002-Revert-one-of-the-optimizations.patch Description:

Re: Split index and table statistics into different types of stats

Hi, On 11/1/22 1:30 AM, Andres Freund wrote: Hi, On 2022-10-31 14:14:15 +0100, Drouvot, Bertrand wrote: Please find attached a patch proposal to split index and table statistics into different types of stats. This idea has been proposed by Andres in a couple of threads, see [1] and [2].

Re: Adding doubly linked list type which stores the number of items in the list

Hi David, > Pushed. Thank you both for reviewing this. Thanks for applying the patch. >> Should we consider const'ifying the arguments of the dlist_*/dclist_* >> functions that don't change the arguments? >> [...] > You're right, both of them must be discussed separately. I would like to

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

Updated the patch: - Optimized and simplified logic of IGNORE_ERRORS - Changed variable names to more understandable ones - Added an analogue of MAX_BUFFERED_BYTES for safe buffer Regards, Damir Belyalov Postgres Professional > diff --git a/doc/src/sgml/ref/copy.sgml

Re: Allow file inclusion in pg_hba and pg_ident files

On Fri, Oct 28, 2022 at 11:49:54AM +0800, Julien Rouhaud wrote: > To be honest I'd rather not to. It's excessively annoying to work on those > tests (I spent multiple days trying to make it as clean and readable as > possible), and splitting it to only test the current infrastructure will need >

Re: Code checks for App Devs, using new options for transaction behavior

On Wed, 2 Nov 2022 at 03:52, Dilip Kumar wrote: > > On Mon, Oct 31, 2022 at 6:54 PM Simon Riggs > wrote: > > > > > > What is the behavior if "nested_transactions" value is changed within > > > > a transaction execution, suppose the value was on and we have created > > > > a few levels of nested

Re: Incorrect include file order in guc-file.l

On Wed, Nov 2, 2022 at 1:01 PM Julien Rouhaud wrote: > > Hi, > > On Wed, Nov 02, 2022 at 02:29:50PM +0900, Michael Paquier wrote: > > > > While reviewing a different patch, I have noticed that guc-file.l > > includes sys/stat.h in the middle of the PG internal headers. The > > usual practice is

remap the .text segment into huge pages at run time

It's been known for a while that Postgres spends a lot of time translating instruction addresses, and using huge pages in the text segment yields a substantial performance boost in OLTP workloads [1][2]. The difficulty is, this normally requires a lot of painstaking work (unless your OS does

Re: Improve description of XLOG_RUNNING_XACTS

On Tue, Nov 1, 2022 at 4:33 PM Amit Kapila wrote: > > On Tue, Nov 1, 2022 at 12:53 PM Michael Paquier wrote: > > > > On Mon, Oct 17, 2022 at 02:53:57PM +0900, Michael Paquier wrote: > > > No objections from here if you want to go ahead with v3 and print the > > > full set of subxids on top of

Re: Incorrect include file order in guc-file.l

Hi, On Wed, Nov 02, 2022 at 02:29:50PM +0900, Michael Paquier wrote: > > While reviewing a different patch, I have noticed that guc-file.l > includes sys/stat.h in the middle of the PG internal headers. The > usual practice is to have first postgres[_fe].h, followed by the > system headers and