Re: Improving connection scalability: GetSnapshotData()

On 3/1/20 3:36 AM, Andres Freund wrote: I think these are pretty nice results. Indeed they are. Is the target version PG13 or PG14? It seems like a pretty big patch to go in the last commitfest for PG13. Regards, -- -David da...@pgmasters.net

Re: Some improvements to numeric sqrt() and ln()

Hi Dean, On 2/28/20 3:15 AM, Dean Rasheed wrote: Attached is a WIP patch to improve the performance of numeric sqrt() and ln(), which also makes a couple of related improvements to div_var_fast(), all of which have knock-on benefits for other numeric functions. The actual impact varies greatly

Re: Retiring support for pre-7.3 FK constraint triggers

On 3/5/20 9:42 AM, Tom Lane wrote: Alvaro Herrera writes: On 2020-Mar-05, Daniel Gustafsson wrote: While looking at the tg_updatedcols patch I happened to notice that we still support pre-7.3 constraint triggers by converting them on the fly. AFAICT this requires a pre-7.3 dump to hit. I

Re: doc: vacuum full, fillfactor, and "extra space"

On 1/30/20 6:54 AM, Amit Kapila wrote: On Wed, Jan 29, 2020 at 9:10 PM Peter Eisentraut wrote: On 2020-01-20 06:30, Justin Pryzby wrote: Rebased against 40d964ec997f64227bc0ff5e058dc4a5770a70a9 I'm not sure that description of parallel vacuum in the middle of non-full vs. full vacuum is

Re: Psql patch to show access methods info

Hi Alexander, On 1/21/20 5:37 PM, Alvaro Herrera wrote: On 2020-Jan-21, Alvaro Herrera wrote: c) it would be damn handy if \dAf (maybe \dAf+) lists the datatypes that each opfamily has opclasses for. Maybe make the output an array, like {int4,int8,numeric,...} Something like [*] but

Re: Fastpath while arranging the changes in LSN order in logical decoding

Hi Dilip, On 2/18/20 7:30 PM, David Zhang wrote: After manually applied the patch, a diff regenerated is attached. David's updated patch applies but all logical decoding regression tests are failing on cfbot. Do you know when you will be able to supply an updated patch? Regards, -- -David

Re: row filtering for logical replication

Hi Euler, On 1/21/20 2:32 AM, Craig Ringer wrote: On Fri, 17 Jan 2020 at 07:58, Euler Taveira wrote: Em qui., 16 de jan. de 2020 às 18:57, Tomas Vondra escreveu: Euler, this patch is still in "waiting on author" since 11/25. Do you plan to review changes made by Amit in the patches he

PG14 target version?

Anybody know how to add 14 to the "Target version" dropdown in the CF app? I haven't needed it yet but I'd like it to be there when I do. Thanks! -- -David da...@pgmasters.net

Re: [HACKERS] [PATCH] Generic type subscripting

Hi Dmitry, On 2/13/20 8:12 AM, Dmitry Dolgov wrote: Yep, I wasn't paying much attention recently to this patch, will post rebased and fixed version soon. The last CF for PG13 has begun. Do you know when you'll have a rebased and updated patch available? The current patch no longer

Re: WIP: System Versioned Temporal Table

Hi Surafel, On 1/3/20 5:57 AM, Surafel Temesgen wrote: Rebased and conflict resolved i hope it build clean this time This patch no longer applies according to cfbot and there are a number of review comments that don't seem to have been addressed yet. The patch is not exactly new for this

Re: Option to dump foreign data in pg_dump

Hi Luis, On 1/29/20 11:05 AM, Peter Eisentraut wrote: On 2020-01-21 10:36, Luis Carril wrote: Yes we can support --include-foreign-data without parallel option and later add support for parallel option as a different patch. Hi, I've attached a new version of the patch in which an error

Re: [PATCH] Incremental sort

James and Tomas, On 1/21/20 10:03 AM, James Coleman wrote: On Tue, Jan 21, 2020 at 9:58 AM Tomas Vondra wrote: On Tue, Jan 21, 2020 at 09:37:01AM -0500, James Coleman wrote: On Tue, Jan 21, 2020 at 9:25 AM Tomas Vondra wrote: Hi, This patch has been marked as WoA since end of November,

Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master

On 3/2/20 10:33 AM, Juan José Santamaría Flecha wrote: On Fri, Feb 21, 2020 at 8:15 PM Palamadai, Eka > wrote: Please, do not top post on this list. Thanks a lot for the feedback. Please let me know if you have any further comments. Meanwhile, I have also

Cast to uint16 in pg_checksum_page()

Hackers, The current code in checksum_impl.h does not play nice with -Wconversion on gcc: warning: conversion to 'uint16 {aka short unsigned int}' from 'uint32 {aka unsigned int}' may alter its value [-Wconversion] return (checksum % 65535) + 1;

Re: [PATCH v1] pg_ls_tmpdir to show directories

Hi Fabien, On 1/16/20 9:38 AM, Justin Pryzby wrote: On Thu, Jan 16, 2020 at 09:34:32AM +0100, Fabien COELHO wrote: Also, I'm not fully sure why ".*" files should be skipped, maybe it should be an option? Or the user can filter it with SQL if it does not want them? I think if someone wants

Re: More tests to stress directly checksum_impl.h

On 3/6/20 2:52 AM, Michael Paquier wrote: As of the thread which led to addd034 (please see https://www.postgresql.org/message-id/e1j9ioh-0005kn...@gemulon.postgresql.org, and sorry about that), it happens that we don't have any tests which validate the internal data checksum implementation

Re: making the backend's json parser work in frontend code

On 1/23/20 11:05 AM, Robert Haas wrote: > On Thu, Jan 23, 2020 at 12:49 PM Bruce Momjian wrote: >> Another idea is to use base64 for all non-ASCII file names, so we don't >> need to check if the file name is valid UTF8 before outputting --- we >> just need to check for non-ASCII, which is much

Re: making the backend's json parser work in frontend code

On 1/24/20 10:00 AM, Alvaro Herrera wrote: On 2020-Jan-24, David Steele wrote: It might be nice to have a strict mode where non-ASCII/UTF8 characters will error instead, but that can be added on later. "your backup failed because you have a file we don't like" is not great behavior

Re: libxml2 is dropping xml2-config

On 1/23/20 7:09 AM, Christoph Berg wrote: > Re: David Steele 2020-01-21 <95349047-31dd-c7dc-df17-b488c2d34...@pgmasters.net> >> Yes -- at least Ubuntu < 18.04 does not install pkg-config for libxml2. I >> have not checked Debian yet, but I imagine <

Re: making the backend's json parser work in frontend code

On 1/24/20 9:27 AM, Tom Lane wrote: Peter Eisentraut writes: On 2020-01-23 18:04, Robert Haas wrote: Now, you might say "well, why don't we just do an encoding conversion?", but we can't. When the filesystem tells us what the file names are, it does not tell us what encoding the person who

Re: Don't try fetching future segment of a TLI.

On 1/28/20 8:02 PM, Kyotaro Horiguchi wrote: > At Tue, 28 Jan 2020 19:13:32 +0300, Pavel Suderevsky >> Regading influence: issue is not about the large amount of WALs to apply >> but in searching for the non-existing WALs on the remote storage, each such >> search can take 5-10 seconds while

Re: [Patch] Make pg_checksums skip foreign tablespace directories

On 2/20/20 12:55 AM, Michael Paquier wrote: On Wed, Feb 19, 2020 at 12:37:00PM -0600, David Steele wrote: As far as I can see, the pg_internal.init.XX will not be cleaned up by PostgreSQL on startup. I've only tested this in 9.6 so far, but I don't see any differences in the code since

Re: [Patch] Make pg_checksums skip foreign tablespace directories

named files. Do you know of any backup solutions which could be impacted by that? I am adding David Steele and Stephen Frost in CC so as they can comment based on their experience in this area. I recall that backrest stuff uses the replication protocol, but I may be wrong. I'm really not a fan of

Re: [Patch] Make pg_checksums skip foreign tablespace directories

On 1/31/20 3:59 AM, Michael Banck wrote: Hi, Am Freitag, den 31.01.2020, 13:53 +0900 schrieb Michael Paquier: On Thu, Jan 30, 2020 at 06:11:22PM +0100, Michael Banck wrote: Having a past tablespace version left around after an upgrade is a pilot error in my opinion because pg_upgrade generates

Re: [Patch] Make pg_checksums skip foreign tablespace directories

Hi Michael, On 2/20/20 11:07 PM, Michael Paquier wrote: > On Thu, Feb 20, 2020 at 07:37:15AM -0600, David Steele wrote: >> But since the name includes the backend's pid you would need to get lucky >> and have a new backend with the same pid create the file after a restar

Re: [Patch] Make pg_checksums skip foreign tablespace directories

On 2/21/20 1:36 AM, Michael Paquier wrote: > On Thu, Feb 20, 2020 at 05:38:15PM +0100, Bernd Helmle wrote: >> So i propose a different approach like the attached patch tries to >> implement: instead of just blindly iterating over directory contents >> and filter them out, reference the tablespace

Re: Does recovery write to backup_label ?

On 2/7/20 8:06 PM, Fujii Masao wrote: On Sat, Feb 8, 2020 at 5:05 AM Chapman Flack wrote: On 2/7/20 2:55 PM, Andres Freund wrote: If the file needs to have 0600 permissions, should there be a note in the nonexclusive-mode backup docs to say so? I'm not convinced that that's useful. The

Re: backup manifests

Hi Tom, On 1/14/20 9:47 PM, Tom Lane wrote: David Steele writes: I'm happy to work up a prototype unless the consensus is that we absolutely don't want a second JSON parser in core. How much code are we talking about? If the answer is "a few hundred lines", it's a lot easier

Re: backup manifests

Hi Stephen, On 1/14/20 1:35 PM, Stephen Frost wrote: My thought, which I had expressed to David (though he obviously didn't entirely agree with me since he suggested the other options), was to adapt the pgBackRest JSON parser, which isn't really all that much code. It's not that I didn't

Re: making the backend's json parser work in frontend code

On 1/15/20 7:39 PM, Robert Haas wrote: > On Wed, Jan 15, 2020 at 6:40 PM Andres Freund wrote: >> It's not obvious why the better approach here wouldn't be to just have a >> very simple ereport replacement, that needs to be explicitly included >> from frontend code. It'd not be meaningfully

Re: making the backend's json parser work in frontend code

Hi Robert, On 1/15/20 2:02 PM, Robert Haas wrote: > The discussion on the backup manifest thread has gotten bogged down on > the issue of the format that should be used to store the backup > manifest file. I want something simple and ad-hoc; David Steele and > Stephen Frost

Re: making the backend's json parser work in frontend code

On 1/15/20 4:40 PM, Andres Freund wrote: > > I'm not sure where I come down between using json and a simple ad-hoc > format, when the dependency for the former is making the existing json > parser work in the frontend. But if the alternative is to add a second > json parser, it very clearly

Re: making the backend's json parser work in frontend code

Hi Robert, On 1/16/20 11:37 AM, David Steele wrote: The next question in my mind is given the caveat that the error handing is questionable in the front end, can we at least render/parse valid JSON with the code? Hrm, this bit was from an earlier edit. I meant: The next question in my

Re: making the backend's json parser work in frontend code

On 1/16/20 12:26 PM, Andres Freund wrote: Hi, On 2020-01-16 14:20:28 -0500, Tom Lane wrote: David Steele writes: The way we handle this in pgBackRest is to put a TRY ... CATCH block in main() to log and exit on any uncaught THROW. That seems like a reasonable way to start here. Without

Re: making the backend's json parser work in frontend code

Hi Robert, On 1/16/20 11:51 AM, Robert Haas wrote: On Thu, Jan 16, 2020 at 1:37 PM David Steele wrote: The next question in my mind is given the caveat that the error handing is questionable in the front end, can we at least render/parse valid JSON with the code? That's a real good

Re: making the backend's json parser work in frontend code

Hi Robert, On 1/16/20 11:51 AM, Robert Haas wrote: On Thu, Jan 16, 2020 at 1:37 PM David Steele wrote: So the idea here is that json.c will have the JSON SQL functions, jsonb.c the JSONB SQL functions, and jsonapi.c the parser, and jsonfuncs.c the utility functions? Uh, I think roughly

Re: making the backend's json parser work in frontend code

Hi Robert, On 1/17/20 2:33 PM, Robert Haas wrote: > On Fri, Jan 17, 2020 at 12:36 PM David Steele wrote: > >> I used the callbacks because that's the first method I found but it >> seems like json_lex() might be easier to use in practice. > > Ugh, really? That do

Re: backup manifests

Hi Robert, On 1/7/20 6:33 PM, Stephen Frost wrote: > These are issues that we've thought > about and worried about over the years of pgbackrest and with that > experience we've come down on the side that a JSON-based format would be > an altogether better design. That's why we're advocating

Re: backup manifests

On 12/31/19 10:43 AM, David Fetter wrote: On Tue, Dec 31, 2019 at 01:30:01PM +0100, Tels wrote: Moin, sorry for the very late reply. There was a discussion about the specific format of the backup manifests, and maybe that was already discussed and I just overlooked it: 1) Why invent your own

Re: recovery_target_action=pause with confusing hint

Hi Sergei, On 1/30/20 12:00 PM, Fujii Masao wrote: - check for standby triggers only for recovery_target_action - I am not sure this would be safe for pg_wal_replay_pause() call case Agreed. Basically I think that recoveryPausesHere() should the promotion trigger whether recovery target is

Re: POC: rational number type (fractions)

Hi Joe, On 2/7/20 11:25 PM, Joe Nelson wrote: Hi hackers, attached is a proof of concept patch adding a new base type called "rational" to represent fractions. I have set the target version for this patch to PG14 because it is POC and this is the first CF it has appeared in. Regards, --

Re: bad logging around broken restore_command

Hi Jeff, On 2/6/20 9:23 AM, Fujii Masao wrote: I've attached a patch which emits a LOG message for ENOENT. Isn't it better to use "could not stat file" message even in ENOENT case? If yes, something like message that you used in the patch should be logged as DETAIL or HINT message. So, what

Re: More tests to stress directly checksum_impl.h

On 3/7/20 1:22 PM, Tom Lane wrote: Michael Paquier writes: Another way would be variant output files, which could be a sane solution if we put this in its own test script. I think this way could work; see attached. I'm not sure if it's actually worth providing the variants for non-8K block

Re: WIP: System Versioned Temporal Table

On 3/10/20 9:00 AM, Surafel Temesgen wrote: On Tue, Mar 3, 2020 at 9:33 PM David Steele <mailto:da...@pgmasters.net>> wrote: The patch is not exactly new for this CF but since the first version was posted 2020-01-01 and there have been no updates (except a rebase)

Re: [PATCH] Connection time for \conninfo

Hi Rodrigo, On 2/27/20 4:21 AM, Peter Eisentraut wrote: My opinion is that this is not particularly useful and not appropriate to piggy-back onto \conninfo.  Connection information including host, port, database, user name is a well-established concept in PostgreSQL programs and tools and it

Re: improve transparency of bitmap-only heap scans

Hi Jeff, On 2/7/20 10:22 AM, Alexey Bashtanov wrote: I've changed it all to "unfetched" for at least not to call the same thing differently in the code and in the output, and also rebased it and fit in 80 lines width limit. What do you think of Alexey's updates? Regards, -- -David

Re: [PATCH] Incremental sort

On 4/8/20 11:13 AM, James Coleman wrote: James, can you verify it that's still true? I marked this entry as committed in the 2020-03 CF but it's not clear to me if that's entirely true. I'll leave it up to you (all) to move it to the 2020-07 CF if there is remaining work (other than making

Re: Resume vacuum and autovacuum from interruption and cancellation

On 2/28/20 8:56 AM, Masahiko Sawada wrote: According to those results, it's thought that the more we resume vacuum from the tail of the table, the efficiency is good. Since the table is being updated uniformly even during autovacuum it was more efficient to restart autovacuum from last position

Re: Verify true root on replicas with amcheck

On 1/16/20 7:40 PM, Peter Geoghegan wrote: On Thu, Jan 9, 2020 at 12:55 AM godjan • wrote: I heard that amcheck has an invariant about locking no more than 1 page at a moment for avoiding deadlocks. Is there possible a deadlock situation? This is a conservative principle that I came up

Re: Function to track shmem reinit time

On 2/24/20 10:57 PM, Robert Haas wrote: On Sat, Feb 22, 2020 at 10:31 PM Tom Lane wrote: I'm still going to object to it, on the grounds that (1) it's exposing an implementation detail that clients should not be concerned with, and that we might change in future. The name isn't even well

Re: Commitfest 2020-03 Now in Progress

On 4/1/20 10:09 AM, David Steele wrote: On 3/17/20 8:10 AM, David Steele wrote: On 3/1/20 4:10 PM, David Steele wrote: The last Commitfest for v13 is now in progress! Current stats for the Commitfest are: Needs review: 192 Waiting on Author: 19 Ready for Committer: 4 Total: 215 Halfway

Re: Conflict handling for COPY FROM

On Fri, Mar 27, 2020 at 3:27 PM Tom Lane > wrote: I took a quick look at this patch, since it was marked "ready for committer", but I don't see how it can possibly be considered committable. Based on Tom's review I've marked this patch Returned with

Re: Online checksums patch - once again

On 4/1/20 11:30 AM, David Steele wrote: On 1/18/20 6:18 PM, Daniel Gustafsson wrote: Attached is a v16 rebased on top of current master which addresses the above commented points, and which I am basing the concurrency work on. This patch no longer applies cleanly: http://cfbot.cputube.org

Re: documenting the backup manifest file format

On 4/14/20 3:55 PM, Andrew Dunstan wrote: OK, but I think if we're putting a timestamp string in ISO-8601 format in the manifest it should be in UTC / Zulu time, precisely to avoid these issues. If that's too much trouble then yes an epoch time will probably do. Happily ISO-8601 is always

Re: documenting the backup manifest file format

On 4/14/20 4:11 PM, Alvaro Herrera wrote: On 2020-Apr-14, David Steele wrote: Happily ISO-8601 is always UTC. Uh, it is not -- https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators Whoops, you are correct. I've just never seen non-UTC in the wild yet. -- -David da...@pgmasters.net

Re: documenting the backup manifest file format

On 4/14/20 3:03 PM, Andrew Dunstan wrote: On 4/14/20 1:33 PM, David Steele wrote: On 4/14/20 1:27 PM, Alvaro Herrera wrote: On 2020-Apr-14, David Steele wrote: On 4/14/20 12:56 PM, Robert Haas wrote: Hmm, did David suggest that before? I don't recall for sure. I think he had some

Re: documenting the backup manifest file format

On 4/15/20 6:43 PM, Jehan-Guillaume de Rorthais wrote: On Wed, 15 Apr 2020 12:03:28 -0400 Robert Haas wrote: On Wed, Apr 15, 2020 at 11:23 AM Jehan-Guillaume de Rorthais wrote: But for backup_manifest, it's kind of shame we have to check the checksum against an transformed version of the

Re: Don't try fetching future segment of a TLI.

On 4/7/20 3:48 AM, Kyotaro Horiguchi wrote: At Tue, 7 Apr 2020 12:15:00 +0900, Fujii Masao wrote in This doesn't seem a bug, so I'm thinking to merge this to next *major* version release, i.e., v13. Not a bug, perhaps, but I think we do consider back-patching performance problems. The rise

Re: pgsql: Generate backup manifests for base backups, and validate them.

On 4/7/20 12:44 PM, Robert Haas wrote: On Tue, Apr 7, 2020 at 5:51 AM Peter Eisentraut wrote: On 2020-04-03 21:07, Robert Haas wrote: A new tool called pg_validatebackup can validate a backup against the manifest. In software engineering, "verify" and "validate" have standardized distinct

Re: Allow cluster owner to bypass authentication

On 4/5/20 6:15 AM, Peter Eisentraut wrote: On 2020-03-27 15:58, David Steele wrote: Hi Peter, On 12/27/19 3:22 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: I think it'd be great if this behavior could be implemented within the notation, because we could then just set up

Re: archive recovery fetching wrong segments

Hi Grigory, On 4/5/20 8:02 PM, Grigory Smolkin wrote: Hello, hackers! I`m investigating a complains from our clients about archive recovery speed been very slow, and I`ve noticed a really strange and, I think, a very dangerous recovery behavior. When running multi-timeline archive

Re: Don't try fetching future segment of a TLI.

On 4/6/20 1:43 PM, Fujii Masao wrote: On 2020/03/19 22:22, Pavel Suderevsky wrote: Hi, I've tested patch provided by Kyotaro and do confirm it fixes the issue. The patch looks good to me. Attached is the updated version of the patch. I updated only comments. Barring any objection, I will

Re: archive recovery fetching wrong segments

On 4/6/20 3:23 PM, Grigory Smolkin wrote: On 4/6/20 9:17 PM, David Steele wrote: Hi Grigory, Hello! On 4/5/20 8:02 PM, Grigory Smolkin wrote: Hello, hackers! I`m investigating a complains from our clients about archive recovery speed been very slow, and I`ve noticed a really strange

Re: documenting the backup manifest file format

for the files instead of the manifest itself, but I also wonder what the use case would be for using a stronger checksum on the manifest. David Steele argued that strong checksums on the files could be useful to software that wants to rifle through all the backups you've ever taken and find another copy

Re: cleaning perl code

On 4/12/20 3:22 PM, Robert Haas wrote: On Sat, Apr 11, 2020 at 11:15 AM Tom Lane wrote: Noah Misch writes: In summary, among those warnings, I see non-negative value in "Code before warnings are enabled" only. While we're changing this, I propose removing Subroutines::RequireFinalReturn.

Re: pg_basebackup, manifests and backends older than ~12

On 4/10/20 4:09 AM, Michael Paquier wrote: I have noticed that attempting to use pg_basebackup from HEAD leads to failures when using it with backend versions from 12 and older: $ pg_basebackup -D hoge pg_basebackup: error: backup manifests are not supported by server version 12beta2

Re: pg_basebackup, manifests and backends older than ~12

On 4/10/20 4:41 PM, Stephen Frost wrote: Greetings, * David Steele (da...@pgmasters.net) wrote: On 4/10/20 4:09 AM, Michael Paquier wrote: I have noticed that attempting to use pg_basebackup from HEAD leads to failures when using it with backend versions from 12 and older: $ pg_basebackup -D

Re: pgbench - add pseudo-random permutation function

On 4/2/20 3:01 AM, Alvaro Herrera wrote: On 2020-Apr-02, Fabien COELHO wrote: I'm planning to mark this patch RwF on April 8 and I suggest you resubmit if you are able to get some consensus. People interested in non-uniform benchmarks would see the point. Why many people would be happy with

Re: cleaning perl code

On 4/12/20 6:24 PM, Andrew Dunstan wrote: On 4/12/20 4:12 PM, David Steele wrote: Just in case it is useful, I have attached our old policy file with exceptions and excuses (when we had one). That's a pretty short list for --brutal, well done. I agree there is value in keeping documented

Re: where should I stick that backup?

On 4/12/20 6:37 PM, Andres Freund wrote: Hi, On 2020-04-12 17:57:05 -0400, David Steele wrote: On 4/12/20 3:17 PM, Andres Freund wrote: [proposal outline[ This is pretty much what pgBackRest does. We call them "local" processes and they do most of the work during backup/restore/a

Re: where should I stick that backup?

On 4/12/20 3:17 PM, Andres Freund wrote: More generally, can you think of any ideas for how to structure an API here that are easier to use than "write some C code"? Or do you think we should tell people to write some C code if they want to compress/encrypt/relocate their backup in some

Re: where should I stick that backup?

On 4/12/20 11:04 AM, Robert Haas wrote: On Sun, Apr 12, 2020 at 10:09 AM Magnus Hagander wrote: There are certainly cases for it. It might not be they have to be the same connection, but still be the same session, meaning before the first time you perform some step of authentication, get a

Re: pg_validatebackup -> pg_verifybackup?

On 4/10/20 11:37 AM, Tom Lane wrote: Robert Haas writes: Over at https://www.postgresql.org/message-id/172c9d9b-1d0a-1b94-1456-376b1e017...@2ndquadrant.com Peter Eisentraut suggests that pg_validatebackup should be called pg_verifybackup, with corresponding terminology changes throughout the

Re: pg_validatebackup -> pg_verifybackup?

On 4/10/20 3:27 PM, Tom Lane wrote: David Steele writes: Having said that, I'm +1 on verify. Me too, if only because it's shorter. I also think it is (probably) more correct but failing that it is *definitely* shorter! -- -David da...@pgmasters.net

Re: Allow auto_explain to log plans before queries are executed

On 3/5/20 8:46 AM, Julien Rouhaud wrote: On Thu, Feb 27, 2020 at 7:31 AM Julien Rouhaud wrote: On Thu, Feb 27, 2020 at 7:12 AM Pavel Stehule wrote: čt 27. 2. 2020 v 7:01 odesílatel Yugo NAGATA napsal: I think "query debugger" feature you proposed is out of scope of auto_explain module.

Re: NOT IN subquery optimization

On 3/26/20 4:58 PM, Li, Zheng wrote: >BTW, so far as I can see, the only reason you're bothering with the whole thing is to compare the size of the subquery output with work_mem, because that's all that subplan_is_hashable does. I wonder whether that consideration is even

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

On 3/28/20 5:27 AM, Fabien COELHO wrote: Hello Tom, Thanks for your feedback, I'd be rather unclear about what the actual feedback is, though. I'd interpret it as "pg does not care much about code coverage". Most clients are in the red on coverage.postgresql.org. I'd like pgbench at least

Re: WIP: WAL prefetch (another approach)

On 4/8/20 8:12 AM, Thomas Munro wrote: Ok, so the following parts of this work have been committed: b09ff536: Simplify the effective_io_concurrency setting. fc34b0d9: Introduce a maintenance_io_concurrency setting. 3985b600: Support PrefetchBuffer() in recovery. d140f2f3: Rationalize

Re: [patch]socket_timeout in interfaces/libpq

On 3/24/20 10:58 AM, David Steele wrote: On 11/29/19 12:22 AM, nagaura.ryo...@fujitsu.com wrote: > I couldn't understand what you meant. Do you say that we shouldn't change pqWait() behavior? Or should I modify my patch to use pqDropConnection()? This patch no longer applies: h

Re: Parallel leader process info in EXPLAIN

Hi Thomas, On 1/26/20 7:03 PM, Thomas Munro wrote: Fair point. I will look into that. Are you still planning on looking at this patch for PG13? Based on the current state (002 abandoned, 001 needs total rework) I'd say it should just be Returned with Feedback or Closed for now. Regards,

Re: [PATCH] Connection time for \conninfo

On 3/14/20 3:16 PM, Rodrigo Ramírez Norambuena wrote: I forgot about that ... It passed a little time from my new pushed changes. So go ahead :) This patch has been returned with feedback. Please feel free to resubmit in a future CF when you believe the feedback has been addressed.

Re: Libpq support to connect to standby server as priority

On 2/28/20 11:05 AM, Alvaro Herrera wrote: MauMau, Greg, is any of you submitting a new patch for this? This patch has not had any updates in months and now we are halfway through the CF so I have marked it Returned with Feedback. If a patch arrives soon I'll be happy to revive the entry,

Re: VACUUM memory management

On 1/28/20 1:36 PM, Ibrar Ahmed wrote: On Wed, Jan 22, 2020 at 11:17 AM k.jami...@fujitsu.com I might have missed something more, but I'll continue reviewing after the rebased patch. Yes, I am working on that. I will send the rebased and updated patch. This patch has not had

Re: row filtering for logical replication

On 3/3/20 12:39 PM, David Steele wrote: Hi Euler, On 1/21/20 2:32 AM, Craig Ringer wrote: On Fri, 17 Jan 2020 at 07:58, Euler Taveira wrote: Em qui., 16 de jan. de 2020 às 18:57, Tomas Vondra escreveu: Euler, this patch is still in "waiting on author" since 11/25. Do you plan

Re: Option to dump foreign data in pg_dump

Hi Luis, Please don't top post. Also be careful to quote prior text when replying. Your message was pretty hard to work through -- i.e. figuring out what you said vs. what you were replying to. On 3/5/20 8:51 AM, Luis Carril wrote: At this point I would like to leave the patch as is, and

Re: [PATCH] Connection time for \conninfo

On 3/16/20 10:59 AM, Juan José Santamaría Flecha wrote: On Mon, Mar 16, 2020 at 1:24 PM David Steele <mailto:da...@pgmasters.net>> wrote: On 3/14/20 3:16 PM, Rodrigo Ramírez Norambuena wrote: > > I forgot about that ... It passed a little time from my new pushed

Re: backup manifests

On 3/26/20 11:37 AM, Robert Haas wrote: On Wed, Mar 25, 2020 at 4:54 PM Stephen Frost wrot > This is where I feel like I'm trying to make decisions in a vacuum. If we had a few more people weighing in on the thread on this point, I'd be happy to go with whatever the consensus was. If most

Re: Asymmetric partition-wise JOIN

Hi Thomas, On 12/27/19 2:34 AM, Kohei KaiGai wrote: > This crash was reproduced on our environment also. It looks to me adjust_child_relids_multilevel() didn't expect a case when supplied 'relids' (partially) indicate normal and non-partitioned relation. It tries to build a new 'parent_relids'

Re: Allow cluster owner to bypass authentication

Hi Peter, On 12/27/19 3:22 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: I think it'd be great if this behavior could be implemented within the notation, because we could then just set up a non-empty default pg_ident.conf with useful behavioral examples in the form of prefab

Re: backup manifests

On 4/2/20 1:04 PM, Robert Haas wrote: > There are still some things that not everybody is happy about. In particular, Stephen and David are unhappy about using CRC-32C as the default algorithm, but Andres and Noah both think it's a reasonable choice, even if not as robust as everybody will want.

Re: backup manifests

On 4/2/20 3:47 PM, Andres Freund wrote: On 2020-04-02 15:42:48 -0400, Robert Haas wrote: I suspect I'm not doing quite what you had in mind here... thoughts? I have some ideas, but I think it's complicated enough that I'd not put it in the "pre commit path" for now. +1. These would be great

Re: Columns correlation and adaptive query optimization

On 3/25/20 6:57 AM, Konstantin Knizhnik wrote: On 24.03.2020 20:12, David Steele wrote: On 12/24/19 3:15 AM, Konstantin Knizhnik wrote: New version of patch implicitly adding multicolumn statistic in auto_explain extension and using it in optimizer for more precise estimation of join

Re: [Patch] Invalid permission check in pg_stats for functional indexes

Hi Pierre, On 12/26/19 6:46 PM, Tom Lane wrote: Awhile back I wrote: Actually ... maybe we don't need to change the view definition at all, but instead just make has_column_privilege() do something different for indexes than it does for other relation types. It's dubious that applying that

Re: pgbench - rework variable management

On 3/27/20 6:25 PM, Fabien COELHO wrote: Patch v5 is a rebase with some adjustements. This patch is failing on the Windows build: https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.85698 I'm not sure if this had been fixed in v3 and this is a new issue or if it has

Re: backup manifests

On 3/27/20 3:20 PM, Robert Haas wrote: On Fri, Mar 27, 2020 at 2:29 AM Andres Freund wrote: Hm. Is it a great choice to include the checksum for the manifest inside the manifest itself? With a cryptographic checksum it seems like it could make a ton of sense to store the checksum somewhere

Re: backup manifests

On 3/27/20 3:55 PM, Stephen Frost wrote: * Robert Haas (robertmh...@gmail.com) wrote: I think that what we have seen so far is that all of the SHA-n algorithms that PostgreSQL supports are about equally slow, so it doesn't really matter which one you pick there from a performance point of view.

Re: backup manifests

On 3/27/20 3:29 PM, Robert Haas wrote: On Fri, Mar 27, 2020 at 11:26 AM Stephen Frost wrote: Seems better to (later?) add support for generating manifests for WAL files, and then have a tool that can verify all the manifests required to restore a base backup. I'm not trying to expand on the

Re: pgbench - refactor init functions with buffers

On 3/27/20 6:13 PM, Fabien COELHO wrote: Hello David, I'd prefer not to expand the use of pqexpbuffer in more places, and instead rather see this use StringInfo, now that's also available to frontend programs. Franckly, one or the other does not matter much to me. FWIW, I agree with

Re: backup manifests

On 3/27/20 6:07 PM, Andres Freund wrote: Hi, On 2020-03-27 16:57:46 -0400, Stephen Frost wrote: I really don't know what to say to this. WAL is absolutely critical to a backup being valid. pgBackRest doesn't have a way to *just* validate a backup today, unfortunately, but we're planning to

Re: backup manifests

On 3/27/20 1:53 PM, Robert Haas wrote: On Thu, Mar 26, 2020 at 4:37 PM David Steele wrote: I know you and Stephen have agreed on a number of doc changes, would it be possible to get a new patch with those included? I finally have time to do a review of this tomorrow. I saw some mistakes

<    1   2   3   4   5   6   7   8   9   >