Re: RLS makes COPY TO process child tables

Yugo NAGATA wrote: > On Wed, 01 Feb 2023 12:45:57 +0100 > Antonin Houska wrote: > > > While working on [1] I noticed that if RLS gets enabled, the COPY TO command > > includes the contents of child table into the result, although the > > documentation says it should not: > > > > "COPY TO

Re: RLS makes COPY TO process child tables

On Wed, 01 Feb 2023 11:47:23 -0500 Tom Lane wrote: > Yugo NAGATA writes: > > Antonin Houska wrote: > >> While working on [1] I noticed that if RLS gets enabled, the COPY TO > >> command > >> includes the contents of child table into the result, although the > >> documentation says it should

Re: run pgindent on a regular basis / scripted manner

Noah Misch writes: > Regarding the concern about a pre-receive hook blocking an emergency push, the > hook could approve every push where a string like "pgindent: no" appears in a > commit message within the push. You'd still want to make the tree clean > sometime the same week or so. It's

RE: Deadlock between logrep apply worker and tablesync worker

On Tuesday, January 31, 2023 1:07 AM vignesh C wrote: > On Mon, 30 Jan 2023 at 17:30, vignesh C wrote: > > > > On Mon, 30 Jan 2023 at 13:00, houzj.f...@fujitsu.com > > wrote: > > > > > > On Monday, January 30, 2023 2:32 PM Amit Kapila > wrote: > > > > > > > > On Mon, Jan 30, 2023 at 9:20 AM

Re: Add index scan progress to pg_stat_progress_vacuum

On Fri, Jan 20, 2023 at 11:38 PM Imseih (AWS), Sami wrote: > > >Number of indexes that will be vacuumed or cleaned up. This counter only > >advances when the phase is vacuuming indexes or cleaning up indexes. > > I agree, this reads better. > > --- > -/* Report that we are

Re: run pgindent on a regular basis / scripted manner

On Mon, Jan 30, 2023 at 03:42:09PM -0500, Bruce Momjian wrote: > On Sat, Jan 28, 2023 at 05:06:03PM -0800, Noah Misch wrote: > > On Tue, Jan 24, 2023 at 02:04:02PM -0500, Bruce Momjian wrote: > > > On Tue, Jan 24, 2023 at 09:54:57AM -0500, Tom Lane wrote: > > > > As another example, the mechanisms

Re: Add progress reporting to pg_verifybackup

On Thu, Feb 02, 2023 at 02:57:44PM +0900, Masahiko Sawada wrote: > It seems that the --progress option doesn't work with command_like() > since the progress information is written in stderr but command_like() > doesn't want it. What about command_checks_all()? It should check for stderr, stdout

Re: heapgettup refactoring

On Thu, 2 Feb 2023 at 10:12, Melanie Plageman wrote: > FWIW, I like setting rs_inited in heapgettup_initial_block() better in > the final refactor, but I agree with you that in this patch on its own > it is better in the body of heapgettup() and heapgettup_pagemode(). We can reconsider that when

Re: Add progress reporting to pg_verifybackup

On Wed, Feb 1, 2023 at 10:25 AM Michael Paquier wrote: > > On Fri, Jan 06, 2023 at 04:28:42PM +0900, Masahiko Sawada wrote: > > I've attached the simple patch to add the progress reporting option to > > pg_verifybackup. The progress information is displayed with --progress > > option only during

Re: Exposing the lock manager's WaitForLockers() to SQL

Here is a first attempt at a WIP patch. Sorry about the MIME type. It doesn't take any locks on the tables, but I'm not super confident that that's safe, so any input would be appreciated. I omitted view support for simplicity, but if that seems like a requirement I'll see about adding it. I

Re: Exit walsender before confirming remote flush in logical replication

On Thu, Feb 2, 2023 at 10:04 AM Kyotaro Horiguchi wrote: > > At Wed, 1 Feb 2023 14:58:14 +0530, Amit Kapila > wrote in > > On Wed, Feb 1, 2023 at 2:09 PM Masahiko Sawada > > wrote: > > > > > > Otherwise, we will end up terminating > > > the WAL stream without the done message. Which will lead

Re: Exit walsender before confirming remote flush in logical replication

On Thu, Feb 2, 2023 at 10:48 AM Masahiko Sawada wrote: > > On Wed, Feb 1, 2023 at 6:28 PM Amit Kapila wrote: > > > > > > > In a case where pq_is_send_pending() doesn't become false > > > for a long time, (e.g., the network socket buffer got full due to the > > > apply worker waiting on a lock),

Re: recovery modules

On Wed, Feb 01, 2023 at 01:23:26PM -0800, Nathan Bossart wrote: > Yeah, that's nicer. cfbot is complaining about a missing #include, so I > need to send a new revision anyway. Okay, the changes done here look straight-forward seen from here. I got one small-ish comment.

Re: Exit walsender before confirming remote flush in logical replication

On Wed, Feb 1, 2023 at 6:28 PM Amit Kapila wrote: > > On Wed, Feb 1, 2023 at 2:09 PM Masahiko Sawada wrote: > > > > On Fri, Jan 20, 2023 at 7:45 PM Amit Kapila wrote: > > > > > > On Tue, Jan 17, 2023 at 2:41 PM Amit Kapila > > > wrote: > > > > > > > > Let me try to summarize the discussion

Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl

On Wed, Feb 01, 2023 at 02:29:23PM +0900, Michael Paquier wrote: > As also mentioned upthread by Tom, I am not sure that this combination > makes much sense, actually, because I don't see why one would never > want to know what is the effective value loaded for a parameter stored > in a file when

Re: Exit walsender before confirming remote flush in logical replication

At Wed, 1 Feb 2023 14:58:14 +0530, Amit Kapila wrote in > On Wed, Feb 1, 2023 at 2:09 PM Masahiko Sawada wrote: > > > > Otherwise, we will end up terminating > > the WAL stream without the done message. Which will lead to an error > > message "ERROR: could not receive data from WAL stream:

Re: Weird failure with latches in curculio on v15

On Wed, Feb 01, 2023 at 09:34:44PM -0500, Tom Lane wrote: > Michael Paquier writes: >> Hmm. Isn't that something that we should also document in startup.c >> where both routines are defined? If we begin to use >> PreRestoreCommand() and PostRestoreCommand() in more code paths in the >> future,

Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication

On Wed, Feb 1, 2023 at 5:42 PM Melih Mutlu wrote: > > Hi Shveta, > > shveta malik , 1 Şub 2023 Çar, 15:01 tarihinde şunu > yazdı: >> >> On Wed, Feb 1, 2023 at 5:05 PM Melih Mutlu wrote: >> 2) I found a crash in the previous patch (v9), but have not tested it >> on the latest yet. Crash happens

Re: Time delayed LR (WAS Re: logical replication restrictions)

On Wed, Feb 1, 2023 at 3:10 PM shiy.f...@fujitsu.com wrote: > > On Mon, Jan 30, 2023 6:05 PM Takamichi Osumi (Fujitsu) > wrote: > > > > Kindly have a look at the attached v25. > > > > Thanks for your patch. Here are some comments. > > 1. > + /* > +* The min_apply_delay parameter

Re: [PATCH] New [relation] option engine

On Wed, 1 Feb 2023 at 14:49, Alvaro Herrera wrote: > > On 2023-Jan-31, vignesh C wrote: > > > On Tue, 3 Jan 2023 at 18:38, vignesh C wrote: > > > > The patch does not apply on top of HEAD as in [1], please post a rebased > > > patch: > > > === Applying patches on top of PostgreSQL commit ID > >

Re: Weird failure with latches in curculio on v15

Michael Paquier writes: > Hmm. Isn't that something that we should also document in startup.c > where both routines are defined? If we begin to use > PreRestoreCommand() and PostRestoreCommand() in more code paths in the > future, that could be again an issue. I was vaguely wondering about

Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?

On Thu, Feb 02, 2023 at 10:06:15AM +0900, Michael Paquier wrote: > Thanks for confirming. I am wondering what these animals may complain > about next, but based on some tests on this buildfarm host with the > same configuration, things are looking OK once this stuff is applied > on 11~14.

Re: Weird failure with latches in curculio on v15

On Wed, Feb 01, 2023 at 02:35:55PM -0800, Nathan Bossart wrote: > Here is a first draft for the proposed stopgap fix. If we want to proceed > with this, I can provide patches for the back branches. > + /* > + * PreRestoreCommand() is used to tell the SIGTERM handler for the > startup >

Fwd: pgsql: Remove over-optimistic Assert.

Resend this email to -hackers. Sorry for the noise. Thanks Richard -- Forwarded message - From: Richard Guo Date: Thu, Feb 2, 2023 at 9:51 AM Subject: Re: pgsql: Remove over-optimistic Assert. To: Tom Lane Cc: , PostgreSQL-development < pgsql-hack...@postgresql.org> On Thu,

Re: Weird failure with latches in curculio on v15

On Wed, Feb 01, 2023 at 10:18:27AM -0800, Andres Freund wrote: > On 2023-02-01 12:27:19 -0500, Tom Lane wrote: >> Andres Freund writes: >> The main thing that system() brings to the table is platform-specific >> knowledge of where the shell is. I'm not very sure that we want to >> wire in

Re: CI and test improvements

Thomas Munro writes: > Some observations: > * macOS has a new release every year in June[1] > * updates cease after three years[1] > * thus three releases are in support (by that definition) at a time > * we need an image on Cirrus; 13 appeared ~1 month later[2] > * we need Homebrew support; 13

Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux?

On Wed, Feb 01, 2023 at 03:06:16PM +1300, Thomas Munro wrote: > +1, go for it. It shouldn't affect Unix build releases, and on > Windows the function does nothing. Thanks for confirming. I am wondering what these animals may complain about next, but based on some tests on this buildfarm host

Re: pg_dump versus hash partitioning

David Rowley writes: > Digging into the history a bit, I found [2] and particularly [3] that > seem to indicate this option was thought about due to concerns about > hash functions not returning consistent results on different > architectures. I suspect it might have been defaulted to load into

Re: CI and test improvements

On Fri, Dec 30, 2022 at 4:59 PM Thomas Munro wrote: > On Wed, Nov 23, 2022 at 11:57 AM Justin Pryzby wrote: > > [PATCH 03/10] cirrus/macos: update to macos ventura > > I don't know any reason not to push this one too, but it's not time critical. Some observations: * macOS has a new release

Re: pg_dump versus hash partitioning

On Thu, 2 Feb 2023 at 11:38, Tom Lane wrote: > > Peter Geoghegan writes: > > You mentioned "minor releases" here. Who said anything about that? > > I did: I'd like to back-patch the fix if possible. I think changing > the default --load-via-partition-root choice could be back-patchable. > > If

Re: Perform streaming logical transactions by background workers and parallel apply

Some minor review comments for v91-0001 == doc/src/sgml/config.sgml 1. -Allows streaming or serializing changes immediately in logical decoding. -The allowed values of logical_replication_mode are -buffered and immediate. When set -to immediate,

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 2:49 PM Tom Lane wrote: > It's precisely because you want to analyze it in the same terms > as range/list partitioning that we have these issues. Or we could > have built it on some other infrastructure than hash index opclasses > ... but we didn't do that, and now we have

Re: pg_dump versus hash partitioning

Robert Haas writes: > On Wed, Feb 1, 2023 at 4:12 PM Tom Lane wrote: >> That being the case, I don't think moving the goalposts for hash >> function stability is going to lead to a workable solution. > I don't see that there is any easy, clean way to solve this in > released branches. The idea

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 3:38 PM Tom Lane wrote: > Peter Geoghegan writes: > > You mentioned "minor releases" here. Who said anything about that? > > I did: I'd like to back-patch the fix if possible. I think changing > the default --load-via-partition-root choice could be back-patchable. > > If

Re: pg_dump versus hash partitioning

Robert Haas writes: > On Wed, Feb 1, 2023 at 5:08 PM Tom Lane wrote: >> I can agree with that argument for range or list partitioning, where >> the partitions have some semantic meaning to the user. I don't buy it >> for hash partitioning. It was an implementation artifact to begin >> with

Re: pg_dump versus hash partitioning

Peter Geoghegan writes: > You mentioned "minor releases" here. Who said anything about that? I did: I'd like to back-patch the fix if possible. I think changing the default --load-via-partition-root choice could be back-patchable. If Robert is resistant to that but would accept it in master,

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 5:08 PM Tom Lane wrote: > > Here, you'd like to argue that it's perfectly > > fine if we instead insert some of the rows into different tables than > > where they were on the original system. > > I can agree with that argument for range or list partitioning, where > the

Re: Weird failure with latches in curculio on v15

On Wed, Feb 01, 2023 at 09:58:06AM -0800, Nathan Bossart wrote: > On Wed, Feb 01, 2023 at 08:58:01AM -0800, Andres Freund wrote: >> On 2023-02-01 10:12:26 -0500, Tom Lane wrote: >>> The fundamental issue is that we have no good way to break out >>> of system(), and I think the original idea was

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 2:12 PM Robert Haas wrote: > On Wed, Feb 1, 2023 at 4:44 PM Peter Geoghegan wrote: > > This is a misrepresentation of Tom's words. It isn't actually > > self-evident what "we end up with all of the same objects, each > > defined in the same way, and that all of the tables

Re: pg_dump versus hash partitioning

Robert Haas writes: > Tom, as I understand it, is arguing that the > --load-via-partition-root behavior has negligible downsides and is > almost categorically better than the current default behavior, and > thus making that the new default in some or all situations in a minor > release is totally

Re: MacOS: xsltproc fails with "warning: failed to load external entity"

Hi, Here are my two cents. > the minimum version appears to be newer than RHEL8's 1.8.2, > which I find pretty unfortunate. On RHEL8, it fails with > $ ninja > ninja: error: build.ninja:6771: multiple outputs aren't (yet?) supported by > depslog; bring this up on the mailing list if it

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 4:44 PM Peter Geoghegan wrote: > This is a misrepresentation of Tom's words. It isn't actually > self-evident what "we end up with all of the same objects, each > defined in the same way, and that all of the tables end up with all > the same contents that they had before"

Re: pg_dump versus hash partitioning

Robert Haas writes: > It seems to me that the job of pg_dump is to produce a dump that, when > reloaded on another system, recreates the same database state. That > means that we end up with all of the same objects, each defined in the > same way, and that all of the tables end up with all the

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 4:12 PM Tom Lane wrote: > > I don't think the fact that our *traditional* standard for how stable > > a hash function needs to be has been XYZ carries any water. > > Well, it wouldn't need to if we had a practical way of changing the > behavior of an existing hash function,

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 12:39 PM Robert Haas wrote: > I don't think the fact that our *traditional* standard for how stable > a hash function needs to be has been XYZ carries any water. Needs > change over time, and we adapt the code to meet the new needs. Since > we have no system for type

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 1:14 PM Robert Haas wrote: > It seems to me that the job of pg_dump is to produce a dump that, when > reloaded on another system, recreates the same database state. That > means that we end up with all of the same objects, each defined in the > same way, and that all of the

Re: recovery modules

On Wed, Feb 01, 2023 at 01:06:06PM -0800, Andres Freund wrote: > On 2023-02-01 12:15:29 -0800, Nathan Bossart wrote: >> Here's a new patch set in which I've attempted to address this feedback and >> Michael's feedback. > > Looks better! Thanks! >> @@ -25,12 +34,14 @@ extern PGDLLIMPORT char

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 3:34 PM Tom Lane wrote: > I spent a bit more time thinking about that, and while I agree that > it's an oddity, I don't see that it matters in the case of hash > partitioning. You would notice an issue if you tried to do a selective > restore of just one partition --- but

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 12:34 PM Tom Lane wrote: > > Also, and I think pretty > > significantly, using --load-via-partition-root forces you to pay the > > overhead of rerouting every tuple to the target partition whether you > > need it or not, which is potentially a large unnecessary expense. > >

Re: heapgettup refactoring

On Thu, Feb 02, 2023 at 12:21:20AM +1300, David Rowley wrote: > On Tue, 31 Jan 2023 at 12:18, Melanie Plageman > wrote: > > v7 attached > > I've been looking over the v7-0002 patch today and I did make a few > adjustments to heapgettup_initial_block() as I would prefer to see the > branching of

Re: pg_dump versus hash partitioning

Robert Haas writes: > On Wed, Feb 1, 2023 at 1:23 PM Tom Lane wrote: >> In the meantime, I think we need to recognize that hash values are >> not very portable. I do not think we do our users a service by >> letting them discover the corner cases the hard way. > I think you're not really

Re: recovery modules

Hi, On 2023-02-01 12:15:29 -0800, Nathan Bossart wrote: > Here's a new patch set in which I've attempted to address this feedback and > Michael's feedback. Looks better! > @@ -25,12 +34,14 @@ extern PGDLLIMPORT char *XLogArchiveLibrary; > * For more information about the purpose of each

Re: Non-superuser subscription owners

Hi, On 2023-01-30 15:32:34 -0500, Robert Haas wrote: > I had a long think about what to do with ALTER SUBSCRIPTION ... OWNER > TO in terms of permissions checks. The previous version required that > the new owner have permissions of pg_create_subscription, but there > seems to be no particular

Re: Add connection active, idle time to pg_stat_activity

Hello hackers, I've sketched the first version of a patch to add pg_stat_session. Please review this early version. Regards, Sergey. From 31f781ecd69fc42aaadd9bcdbebaf8f72449946c Mon Sep 17 00:00:00 2001 From: Sergey Dudoladov Date: Tue, 22 Nov 2022 09:23:32 +0100 Subject: [PATCH] Add

Re: [PATCH] CF app: add "Returned: Needs more interest"

On Wed, Jan 4, 2023 at 9:33 AM Jacob Champion wrote: > Is there a good way to remind people that, hey, this exists as a > patchset? (Other than me pinging the list every so often.) I've withdrawn this patchset for now, but if anyone has any ideas on where and how I can better propose features

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 1:23 PM Tom Lane wrote: > Well, that was what I thought too to start with, but I now think that > it is far too narrow-minded a view of the problem. The real issue > is something I said that you trimmed: > > >> In general, we've never thought that hash values are > >>

Re: Non-superuser subscription owners

Hi, On 2023-02-01 09:43:39 -0500, Robert Haas wrote: > On Tue, Jan 31, 2023 at 7:01 PM Andres Freund wrote: > > I don't really understand that - the run-as approach seems like a > > necessary piece of improving the security model. > > > > I think it's perfectly reasonable to want to replicate

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

On Mon, Jan 30, 2023 at 2:21 PM Robert Haas wrote: > On Mon, Jan 30, 2023 at 4:12 PM Jacob Champion > wrote: > > For our case, assuming that connections have side effects, one > > solution could be for the client to signal to the server that the > > connection should use in-band authentication

Re: pg_dump versus hash partitioning

Robert Haas writes: > ... I like the > fact that we have --load-via-partition-root, but it is a bit of a > hack. You don't get a single copy into the partition root, you get one > per child table -- and those COPY statements are listed as data for > the partitions where the data lives now, not

Re: recovery modules

On Wed, Feb 01, 2023 at 03:54:26AM -0800, Andres Freund wrote: > I'd make basic_archive's private data a struct, with a member for the > context, but it's not that important. > > I'd also be inclined to do the same for the private_state you're passing > around for each module. Even if it's just

Re: Introduce "log_connection_stages" setting.

Hi again, Justin, thank you for the fast review. The new version is attached. Regards, Sergey Dudoladov From 994a86e6ac3abb647d93bdaf0f42be76f42b83a8 Mon Sep 17 00:00:00 2001 From: Sergey Dudoladov Date: Tue, 8 Nov 2022 18:56:26 +0100 Subject: [PATCH] Introduce 'log_connection_messages' This

Re: MacOS: xsltproc fails with "warning: failed to load external entity"

Andres Freund writes: > On 2023-02-01 09:49:00 -0800, Andres Freund wrote: >> On 2023-02-01 12:23:27 -0500, Tom Lane wrote: >>> And the minimum version appears to be newer than RHEL8's 1.8.2, which >>> I find pretty unfortunate. > Unfortunately the test script accidentally pulled in ninja from

Re: MacOS: xsltproc fails with "warning: failed to load external entity"

Hi, On 2023-02-01 09:49:00 -0800, Andres Freund wrote: > On 2023-02-01 12:23:27 -0500, Tom Lane wrote: > > And the minimum version appears to be newer than RHEL8's 1.8.2, which > > I find pretty unfortunate. On RHEL8, it fails with > > $ ninja > > ninja: error: build.ninja:6771: multiple outputs

Re: MacOS: xsltproc fails with "warning: failed to load external entity"

Andres Freund writes: > On 2023-02-01 12:23:27 -0500, Tom Lane wrote: >> It's unlike what "make -C doc/src/sgml all" does in the Makefile >> system, and I don't find it to be an improvement. > Well, that'd actually build the manpages too, afaics :). But I get the > point. Ah, sorry, I too had

Re: Progress report of CREATE INDEX for nested partitioned tables

On Wed, 1 Feb 2023 at 18:51, Ilya Gladyshev wrote: > > 1 февр. 2023 г., в 20:27, Matthias van de Meent > написал(а): > >> In HEAD we set TOTAL to whatever number partitioned table we're >> currently processing has - regardless of whether we're the top level >> statement. >> With the patch we

Re: pg_dump versus hash partitioning

Robert Haas writes: > On Wed, Feb 1, 2023 at 11:18 AM Tom Lane wrote: >> Over at [1] we have a complaint that dump-and-restore fails for >> hash-partitioned tables if a partitioning column is an enum, >> because the enum values are unlikely to receive the same OIDs >> in the destination database

Re: Optimizing PostgreSQL with LLVM's PGO+LTO

On Mon, Jan 30, 2023 at 10:47 AM Andres Freund wrote: > For some reason my notes for using LTO include changing RANLIB to point to > gcc/llvm-ranlib of the appropriate version. Won't even be used on HEAD, but > before that it can make a difference. > I will try that. > Depending on how you

Re: Weird failure with latches in curculio on v15

Hi, On 2023-02-01 12:27:19 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2023-02-01 12:08:24 -0500, Robert Haas wrote: > >> I like the idea of not relying on system(). In most respects, doing > >> fork() + exec() ourselves seems superior. We can control where the > >> output goes, what

Re: Non-superuser subscription owners

> On Feb 1, 2023, at 6:43 AM, Robert Haas wrote: > The thing I'm > struggling to understand is: if you only want to replicate into tables > that Alice can write, why not just make Alice own the subscription? > For a run-as user to make sense, you need a scenario where we want the >

Re: Weird failure with latches in curculio on v15

On Wed, Feb 01, 2023 at 08:58:01AM -0800, Andres Freund wrote: > On 2023-02-01 10:12:26 -0500, Tom Lane wrote: >> The fundamental issue is that we have no good way to break out >> of system(), and I think the original idea was that >> in_restore_command would be set *only* for the duration of the

Re: Show various offset arrays for heap WAL records

On Wed, Feb 1, 2023 at 12:47 PM Peter Geoghegan wrote: > On Wed, Feb 1, 2023 at 5:20 AM Robert Haas wrote: > > If we're dumping a lot of details out of each WAL record, we might > > want to switch to a multi-line format of some kind. No one enjoys a > > 460-character wide line, let alone 46000.

Re: Progress report of CREATE INDEX for nested partitioned tables

> 1 февр. 2023 г., в 20:27, Matthias van de Meent > написал(а): > > On Wed, 1 Feb 2023 at 16:53, Justin Pryzby > wrote: >> >> On Wed, Feb 01, 2023 at 04:21:35PM +0100, Matthias van de Meent wrote: >>> On Wed, 1 Feb 2023 at 15:21, Ilya Gladyshev >>> wrote:

Re: MacOS: xsltproc fails with "warning: failed to load external entity"

Hi, On 2023-02-01 12:23:27 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2023-02-01 13:05:32 +0300, Aleksander Alekseev wrote: > >> It works. Perhaps we should add: > >> ninja -C build alldocs > > > FWIW, just 'docs' would build just the multi-page html/man pages, > > alldocs takes a

Re: Show various offset arrays for heap WAL records

On Wed, Feb 1, 2023 at 5:20 AM Robert Haas wrote: > If we're dumping a lot of details out of each WAL record, we might > want to switch to a multi-line format of some kind. No one enjoys a > 460-character wide line, let alone 46000. I generally prefer it when I can use psql without using

Re: pg_dump versus hash partitioning

On Wed, Feb 1, 2023 at 11:18 AM Tom Lane wrote: > Over at [1] we have a complaint that dump-and-restore fails for > hash-partitioned tables if a partitioning column is an enum, > because the enum values are unlikely to receive the same OIDs > in the destination database as they had in the source,

Re: Weird failure with latches in curculio on v15

Andres Freund writes: > On 2023-02-01 12:08:24 -0500, Robert Haas wrote: >> I like the idea of not relying on system(). In most respects, doing >> fork() + exec() ourselves seems superior. We can control where the >> output goes, what we do while waiting, etc. But system() runs the >> command

Re: MacOS: xsltproc fails with "warning: failed to load external entity"

Andres Freund writes: > On 2023-02-01 13:05:32 +0300, Aleksander Alekseev wrote: >> It works. Perhaps we should add: >> ninja -C build alldocs > FWIW, just 'docs' would build just the multi-page html/man pages, > alldocs takes a lot longer... Hmm ... why does 'docs' include the man pages, and

Re: Weird failure with latches in curculio on v15

Hi, On 2023-02-01 12:08:24 -0500, Robert Haas wrote: > On Wed, Feb 1, 2023 at 11:58 AM Andres Freund wrote: > > > 9a740f81e clearly made things a lot worse, but it wasn't great > > > before. Can we see a way forward to removing the problem entirely? > > > > Yea, I think we can - we should stop

Re: meson: pkgconfig difference

On 01.02.23 08:55, Andres Freund wrote: Hi, On January 31, 2023 11:40:52 PM PST, Peter Eisentraut wrote: I think there is a tiny typo in src/interfaces/ecpg/ecpglib/meson.build: diff --git a/src/interfaces/ecpg/ecpglib/meson.build b/src/interfaces/ecpg/ecpglib/meson.build index

Re: Weird failure with latches in curculio on v15

On Wed, Feb 1, 2023 at 11:58 AM Andres Freund wrote: > > 9a740f81e clearly made things a lot worse, but it wasn't great > > before. Can we see a way forward to removing the problem entirely? > > Yea, I think we can - we should stop relying on system(). If we instead > run the command properly as

Re: About PostgreSQL Core Team

Hi, Adherent! IMO "not liking" that you quote in the picture is just other words for expressing caution for the patch or for the general direction of some change. At least I never felt personal or arbitrary presumptions in relation to my patches. So if you can join a discussion with your

Re: Weird failure with latches in curculio on v15

Hi, On 2023-02-01 10:12:26 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2023-02-01 16:21:16 +1300, Thomas Munro wrote: > >> It's always in proc_exit() in StartupProcShutdownHandler(), a SIGTERM > >> handler which is allowed to call that while in_restore_command is > >> true. > > > Ugh,

Re: Timeline ID hexadecimal format

On 31/01/2023 20:16, Greg Stark wrote: The fact that the *filename* has it encoded in hex is an implementation detail and really gets exposed here because it's giving you the underlying system error that caused the problem. It's an implementation detail, but an exposed detail, so, people

Re: RLS makes COPY TO process child tables

Yugo NAGATA writes: > Antonin Houska wrote: >> While working on [1] I noticed that if RLS gets enabled, the COPY TO command >> includes the contents of child table into the result, although the >> documentation says it should not: > I think this is a bug because the current behaviour is

Re: Progress report of CREATE INDEX for nested partitioned tables

On Wed, 1 Feb 2023 at 16:53, Justin Pryzby wrote: > > On Wed, Feb 01, 2023 at 04:21:35PM +0100, Matthias van de Meent wrote: > > On Wed, 1 Feb 2023 at 15:21, Ilya Gladyshev > > wrote: > > > > 1 февр. 2023 г., в 16:01, Alvaro Herrera > > > > написал(а): > > > > Hmm, count_leaf_partitions has

pg_dump versus hash partitioning

Over at [1] we have a complaint that dump-and-restore fails for hash-partitioned tables if a partitioning column is an enum, because the enum values are unlikely to receive the same OIDs in the destination database as they had in the source, and the hash codes are dependent on those OIDs. So

Re: RLS makes COPY TO process child tables

On Wed, 01 Feb 2023 12:45:57 +0100 Antonin Houska wrote: > While working on [1] I noticed that if RLS gets enabled, the COPY TO command > includes the contents of child table into the result, although the > documentation says it should not: > > "COPY TO can be used only with plain tables,

Re: Weird failure with latches in curculio on v15

On Wed, Feb 01, 2023 at 10:12:26AM -0500, Tom Lane wrote: > Andres Freund writes: >> On 2023-02-01 16:21:16 +1300, Thomas Munro wrote: >>> It's always in proc_exit() in StartupProcShutdownHandler(), a SIGTERM >>> handler which is allowed to call that while in_restore_command is >>> true. > >>

Re: Progress report of CREATE INDEX for nested partitioned tables

On Wed, Feb 01, 2023 at 04:21:35PM +0100, Matthias van de Meent wrote: > On Wed, 1 Feb 2023 at 15:21, Ilya Gladyshev > wrote: > > > 1 февр. 2023 г., в 16:01, Alvaro Herrera > > > написал(а): > > > Hmm, count_leaf_partitions has to scan pg_inherits and do a syscache > > > lookup for every

Re: Progress report of CREATE INDEX for nested partitioned tables

On Wed, 1 Feb 2023 at 15:21, Ilya Gladyshev wrote: > > > 1 февр. 2023 г., в 16:01, Alvaro Herrera > > написал(а): > > > > Hmm, count_leaf_partitions has to scan pg_inherits and do a syscache > > lookup for every single element therein ... this sounds slow. > > > > In one of the callsites, we

Re: Weird failure with latches in curculio on v15

Andres Freund writes: > On 2023-02-01 16:21:16 +1300, Thomas Munro wrote: >> It's always in proc_exit() in StartupProcShutdownHandler(), a SIGTERM >> handler which is allowed to call that while in_restore_command is >> true. > Ugh, no wonder we're getting crashes. This whole business seems bogus

Re: Support for dumping extended statistics

Tomas Vondra writes: > On 1/7/23 03:39, Bruce Momjian wrote: >> There is certainly interest in allowing the optimizer statistics to be >> dumped and reloaded. This could be used by pg_restore and pg_upgrade. > Indeed, although I think it'd be better to deal with regular statistics > (which is

Re: Non-superuser subscription owners

On Tue, Jan 31, 2023 at 7:01 PM Andres Freund wrote: > I don't really understand that - the run-as approach seems like a > necessary piece of improving the security model. > > I think it's perfectly reasonable to want to replicate from one system > in another, but to not want to allow logical

Re: Progress report of CREATE INDEX for nested partitioned tables

> 1 февр. 2023 г., в 16:01, Alvaro Herrera написал(а): > > Hmm, count_leaf_partitions has to scan pg_inherits and do a syscache > lookup for every single element therein ... this sounds slow. > > In one of the callsites, we already have the partition descriptor > available. We could just

Performance issues with parallelism and LIMIT

Hi hackers, While migrating from PostgreSQL 14 to 15, we encountered the following performance degradation caused by commit 46846433a03dff: "shm_mq: Update mq_bytes_written less often", discussion in [1]. The batching can make queries with a LIMIT clause run significantly slower compared to

Re: Syncrep and improving latency due to WAL throttling

On Wed, Feb 1, 2023 at 2:14 PM Tomas Vondra wrote: > > Maybe we should avoid calling fsyncs for WAL throttling? (by teaching > > HandleXLogDelayPending()->XLogFlush()->XLogWrite() to NOT to sync when > > we are flushing just because of WAL thortting ?) Would that still be > > safe? > > It's not

Re: Support for dumping extended statistics

On 1/7/23 03:39, Bruce Momjian wrote: > On Thu, Jan 5, 2023 at 06:29:03PM +, Hari krishna Maddileti wrote: >> Hi Team, >> In order to restore dumped extended statistics (stxdndistinct, >> stxddependencies, stxdmcv) we need to provide input functions to parse >>

Re: recovery modules

Hi, On 2023-01-31 15:30:13 -0800, Nathan Bossart wrote: > +/* > + * basic_archive_startup > + * > + * Creates the module's memory context. > + */ > +void * > +basic_archive_startup(void) > +{ > + return (void *) AllocSetContextCreate(TopMemoryContext, > +

Re: Show various offset arrays for heap WAL records

On Tue, Jan 31, 2023 at 6:20 PM Peter Geoghegan wrote: > Actually the really wide output comes from COMMIT records. After I run > the regression tests, and execute some of my own custom pg_walinspect > queries, I see that some individual COMMIT records have a > length(description) of over 10,000

Re: Syncrep and improving latency due to WAL throttling

On 2/1/23 11:04, Jakub Wartak wrote: > On Mon, Jan 30, 2023 at 9:16 AM Bharath Rupireddy > wrote: > > Hi Bharath, thanks for reviewing. > >> I think measuring the number of WAL flushes with and without this >> feature that the postgres generates is great to know this feature >> effects on

  1   2   >