Re: Supply restore_command to pg_rewind via CLI argument

On Thu, Nov 04, 2021 at 01:55:43PM +0100, Daniel Gustafsson wrote: >> On 14 Sep 2021, at 16:05, Andrey Borodin wrote: >>> Do we actually need --target-restore-command at all? It seems to me >>> that we have all we need with --restore-target-wal, and that's not >>> really instinctive to pass down

Re: pg_dump new feature: exporting functions only. Bad or good idea ?

On Sat, Mar 26, 2022 at 09:53:19AM +0100, Laetitia Avrot wrote: > I think it's time to sum up what we want to do: > > - We'd like to use switches to export objects according to a pattern. > - For each object type we will have an --object=PATTERN flag and a > --exclude-object=PATTERN > - Having a

Re: Change the csv log to 'key:value' to facilitate the user to understanding and processing of logs

On Tue, Mar 15, 2022 at 10:33:42AM -0400, Jan Wieck wrote: > Also, the CSV format, while human readable to a degree, wasn't meant for > direct, human consumption. It was meant to be read by programs and at the > time, CSV made the most sense. FWIW, I have noticed that this patch was still listed

Re: suboverflowed subtransactions concurrency performance optimize

On Mon, Mar 07, 2022 at 10:17:41PM +0800, Julien Rouhaud wrote: > On Mon, Mar 07, 2022 at 01:27:40PM +, Simon Riggs wrote: >> The patch was posted because TransactionLogFetch() has a cache, yet >> SubTransGetTopmostTransaction() does not, yet the argument should be >> identical in both cases.

Re: Logical replication timeout problem

On Wed, Apr 6, 2022 at 6:30 PM wangw.f...@fujitsu.com wrote: > > On Wed, Apr 6, 2022 at 1:59 AM Amit Kapila wrote: > On Wed, Apr 6, 2022 at 4:32 AM Amit Kapila wrote: > > > Thanks for your comments. > > > typedef void (*LogicalOutputPluginWriterUpdateProgress) (struct > >

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

On Thu, 31 Mar 2022 at 06:36, Greg Stark wrote: > > This patch is now failing in the sqljson regression test. It looks > like it's just the ordering of the elements in json_arrayagg() calls > which may actually be a faulty test that needs more ORDER BY clauses > rather than any issues with the

Re: Handle infinite recursion in logical replication setup

FYI, here is a test script that is using the current patch (v6) to demonstrate a way to share table data between different numbers of nodes (up to 5 of them here). The script starts off with just 2-way sharing (nodes N1, N2), then expands to 3-way sharing (nodes N1, N2, N3), then 4-way sharing

Re: Speed up transaction completion faster after many relations are accessed in a transaction

On Wed, 6 Apr 2022 at 03:40, Yura Sokolov wrote: > I'm looking on patch and don't get some moments. > > `GrantLockLocal` allocates `LOCALLOCKOWNER` and links it into > `locallock->locallockowners`. It links it regardless `owner` could be > NULL. But then `RemoveLocalLock` does

Re: Window Function "Run Conditions"

On Wed, Apr 6, 2022 at 7:36 PM David Rowley wrote: > On Wed, 6 Apr 2022 at 00:59, Andy Fan wrote: > > > > On Tue, Apr 5, 2022 at 7:49 PM David Rowley > wrote: > >> Yeah, there is more performance to be had than even what you've done > >> there. There's no reason really for spool_tuples() to

Re: How about a psql backslash command to show GUCs?

I also find myself querying pg_settings all too often. More typing than I'd like. On Thu, 7 Apr 2022 at 06:40, Tom Lane wrote: > I do agree that \show might be a bad choice, the reason being that > the adjacent \set command is for psql variables not GUCs; if we > had a \show I'd sort of expect

RE: Data is copied twice when specifying both child and parent table in publication

On Thur, Mar 10, 2021 at 10:08 AM houzj.f...@fujitsu.com wrote: > Hi, > > When reviewing some logical replication related features. I noticed another > possible problem if the subscriber subscribes multiple publications which > publish parent and child table. > > For example: > > pub >

Re: How about a psql backslash command to show GUCs?

"Jonathan S. Katz" writes: > +1 for \dconf Here's a draft patch using \dconf. No tests or docs yet. regards, tom lane diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 079f4a1a76..bbf4a5a44e 100644 --- a/src/bin/psql/command.c +++

Re: Skipping logical replication transactions on subscriber side

On Wed, Apr 6, 2022 at 10:01 AM Amit Kapila wrote: > > On Wed, Apr 6, 2022 at 9:25 AM Masahiko Sawada wrote: > > > > On Wed, Apr 6, 2022 at 12:21 PM Noah Misch wrote: > > > > Right. I've attached an updated patch. > > > > Thanks, this looks good to me as well. Noah, would you like to commit it?

Re: Window Function "Run Conditions"

On Wed, 6 Apr 2022 at 00:59, Andy Fan wrote: > > On Tue, Apr 5, 2022 at 7:49 PM David Rowley wrote: >> Yeah, there is more performance to be had than even what you've done >> there. There's no reason really for spool_tuples() to do >> tuplestore_puttupleslot() when we're not in run mode. > > >

Re: Last day of commitfest

Hi, On Wed, Apr 06, 2022 at 09:32:31PM -0400, Greg Stark wrote: > I won't touch the Ready for Committer stuff until after the end of the > commitfest anyways. I did put those two in that state already. > > Right now I'm trying to get a bit ahead of the game by going through > the "Waiting on

Re: shared-memory based stats collector - v70

Hi, On 2022-04-07 10:36:30 +0900, Kyotaro Horiguchi wrote: > At Wed, 6 Apr 2022 09:04:09 -0700, Andres Freund wrote > in > > > + * Don't define an INVALID value so switch() statements can warn if some > > > + * cases aren't covered. But define the first member to 1 so that > > > + *

Re: Should pg_dumpall dump ALTER SYSTEM settings?

On Wed, Apr 6, 2022 at 2:26 PM Tom Lane wrote: > Thoughts? I'm a little bit skeptical about this proposal, mostly because it seems like it has the end result that values that are configured in postgresql.conf and postgresql.auto.conf end up being handled differently: one file has to be copied by

Re: shared-memory based stats collector - v70

At Wed, 6 Apr 2022 09:04:09 -0700, Andres Freund wrote in > > +* Don't define an INVALID value so switch() statements can warn if some > > +* cases aren't covered. But define the first member to 1 so that > > +* uninitialized values can be detected more easily. > > > > FWIW, I like

Re: Last day of commitfest

I won't touch the Ready for Committer stuff until after the end of the commitfest anyways. I did put those two in that state already. Right now I'm trying to get a bit ahead of the game by going through the "Waiting on Author" patches. The documented process[*] is that they get Returned with

Re: How about a psql backslash command to show GUCs?

On 4/6/22 9:18 PM, David G. Johnston wrote: On Wed, Apr 6, 2022 at 6:16 PM Tom Lane I agree that \d-something makes the most sense from a functionality standpoint.  But I don't want to make the name too long, even if we do have tab completion to help. \dconf maybe? I don't

Re: How about a psql backslash command to show GUCs?

On Wed, Apr 6, 2022 at 6:16 PM Tom Lane wrote: > "Jonathan S. Katz" writes: > > I am a bit torn between "\dcp" (or \dsetting / \dconfig? we don't > > necessarily need for it to be super short) and "\sc". Certainly with > > pattern matching the interface for the "\d" commands would fit that > >

Re: How about a psql backslash command to show GUCs?

"Jonathan S. Katz" writes: > I am a bit torn between "\dcp" (or \dsetting / \dconfig? we don't > necessarily need for it to be super short) and "\sc". Certainly with > pattern matching the interface for the "\d" commands would fit that > pattern. "\sc" would make sense for a thorough

Re: simplifying foreign key/RI checks

There were rebase conflicts with the recently committed execPartition.c/h changes. While fixing them, I thought maybe find_leaf_part_for_key() doesn't quite match in style with its neighbors in execPartition.h, so changed it to ExecGetLeafPartitionForKey(). -- Amit Langote EDB:

Re: shared-memory based stats collector - v70

Hi, On 2022-04-06 17:01:17 -0700, David G. Johnston wrote: > On Wed, Apr 6, 2022 at 4:12 PM Andres Freund wrote: > > The fact there is just the one outlier here suggests that this is indeed the > better option. FWIW, the outlier also uses pgstat_reset(), just with a small wrapper doing the

Re: [PATCH] Expose port->authn_id to extensions and triggers

On Wed, Apr 06, 2022 at 07:16:43PM +, Jacob Champion wrote: > I assumed that we would follow the existing model of "(de)serialize a > whole struct", rather than pulling it apart into many separate keys. If > it got too complicated then we could consider introducing a >

Re: shared-memory based stats collector - v70

On Wed, Apr 6, 2022 at 4:12 PM Andres Freund wrote: > > On 2022-04-06 15:32:39 -0700, David G. Johnston wrote: > > On Wednesday, April 6, 2022, Andres Freund wrote: > > > > > > I like having the SQL function paired with a matching implementation in > > this scheme. > > It would have gotten

Re: Mark all GUC variable as PGDLLIMPORT

On Wed, Apr 06, 2022 at 12:57:29AM +0700, John Naylor wrote: > For these two patches, I'd say a day or two after feature freeze is a > reasonable goal. Yeah. For patches as invasive as the PGDLLIMPORT business and the frontend error refactoring, I am also fine to have two exceptions with the

Re: PATCH: add "--config-file=" option to pg_rewind

On Wed, Apr 06, 2022 at 02:32:44PM +0200, Gunnar "Nick" Bluth wrote: > Ta! Sorry, been ridiculously busy these days, and I do confess that I've > been struggling a bit with those tests before ;-) No problem. Double-checked this morning and applied, then. -- Michael signature.asc Description:

Re: shared-memory based stats collector - v70

Hi, On 2022-04-06 15:32:39 -0700, David G. Johnston wrote: > On Wednesday, April 6, 2022, Andres Freund wrote: > > > > > > > I'd go for > > pgstat_reset_slru_counter() -> pgstat_reset_slru() > > pgstat_reset_subscription_counter() -> pgstat_reset_subscription() > >

Re: Add spin_delay() implementation for Arm in s_lock.h

"Blake, Geoff" writes: > Hi Tom, Andres, > Any additional feedback for this patch? I did some more research and testing: * Using a Mac with the M1 Pro chip (marginally beefier than the M1 I was testing on before), I think I can see some benefit in the test case I proposed upthread. It's

Re: How about a psql backslash command to show GUCs?

> On Apr 6, 2022, at 2:34 PM, Jonathan S. Katz wrote: > > "\sc" would make sense I originally wrote the command as \dcp (describe configuration parameter) because \dp (describe parameter) wasn't available. The thing we're showing is a "parameter", not a "config". If we're going to use a

Re: shared-memory based stats collector - v70

On Wednesday, April 6, 2022, Andres Freund wrote: > > > I'd go for > pgstat_reset_slru_counter() -> pgstat_reset_slru() > pgstat_reset_subscription_counter() -> pgstat_reset_subscription() > pgstat_reset_subscription_counters() -> pgstat_reset_all_subscriptions() >

Re: shared-memory based stats collector - v70

Hi, On 2022-04-05 20:00:08 -0700, Andres Freund wrote: > It'll be a few hours to get to the main commit - but except for 0001 it > doesn't make sense to push without intending to push later changes too. I > might squash a few commits togther. I just noticed an existing incoherency that I'm

Re: How about a psql backslash command to show GUCs?

On 4/6/22 2:40 PM, Tom Lane wrote: Joe Conway writes: No as sure about \show though. That seems like it could be confused with showing other stuff. Maybe consistent with \sf[+] and \sv[+] we could add \sc[+]? Hmm ... my first reaction to that was "no, it should be \sp for 'parameter'". But

Re: Add index scan progress to pg_stat_progress_vacuum

>At the beginning of a parallel operation, we allocate a chunk of> >dynamic shared memory which persists even after some or all workers >have exited. It's only torn down at the end of the parallel operation. >That seems like the appropriate place to be storing any kind of data >

Re: trigger example for plsample

On Wed, Apr 6, 2022 at 5:44 PM Mark Wong wrote: > > On Thu, Mar 10, 2022 at 06:36:44PM -0500, Chapman Flack wrote: > > On 03/02/22 15:12, Mark Wong wrote: > > > > > I've attached v2, which reduces the output: > > > > > > * Removing the notices for the text body, and the "compile" message. > > > *

Re: buildfarm failures, src/test/recovery

On 4/6/22 13:42, Mark Dilger wrote: > Hi Andrew, > > It appears to me that 2ef6f11b0c77ec323c688ddfd98ffabddb72c11d broke > src/test/recovery. > > It looks like the following fixes it. Care to review and push? Or perhaps > just revert that commit? Fixed here

Re: trigger example for plsample

On Thu, Mar 10, 2022 at 06:36:44PM -0500, Chapman Flack wrote: > On 03/02/22 15:12, Mark Wong wrote: > > > I've attached v2, which reduces the output: > > > > * Removing the notices for the text body, and the "compile" message. > > * Replaced the notice for "compile" message with a comment as a

Re: New compiler warning from btree dedup code

That approach seems fine. Thanks.-- Peter Geoghegan

New compiler warning from btree dedup code

I just noticed that if I build without asserts on my Mac laptop (using Apple's latest clang, 13.1.6) I get nbtdedup.c:68:8: warning: variable 'pagesaving' set but not used [-Wunused-but-set-variable] Sizepagesaving = 0; ^ 1 warning generated.

Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file

On Wed, Apr 06, 2022 at 03:29:15PM -0400, Stephen Frost wrote: > This has now been committed- thanks again to everyone for their help! Thanks! -- Nathan Bossart Amazon Web Services: https://aws.amazon.com

Re: shared-memory based stats collector - v70

On Wed, Apr 6, 2022 at 12:34 PM Justin Pryzby wrote: > On Wed, Apr 06, 2022 at 12:27:34PM -0700, Andres Freund wrote: > > > > + next use of statistical information will cause a new snapshot to > be built > > > > + or accessed statistics to be cached. > > > > > > I believe this should be an

Re: shared-memory based stats collector - v70

On Wed, Apr 06, 2022 at 12:27:34PM -0700, Andres Freund wrote: > > > + next use of statistical information will cause a new snapshot to be > > > built > > > + or accessed statistics to be cached. > > > > I believe this should be an "and", not an "or". (next access builds both a > > new

Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file

Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > On Tue, 2022-04-05 at 13:06 -0700, Nathan Bossart wrote: > > On Tue, Apr 05, 2022 at 11:25:36AM -0400, Stephen Frost wrote: > > > Please find attached an updated patch + commit message.  Mostly, I just > > > went through and did a bit

Re: shared-memory based stats collector - v70

Hi, On 2022-04-06 12:14:35 -0700, Lukas Fittl wrote: > On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote: > > > Here comes v70: > > > > Some small nitpicks on the docs: Thanks! > > From 13090823fc4c7fb94512110fb4d1b3e86fb312db Mon Sep 17 00:00:00 2001 > > From: Andres Freund > > Date: Sat,

Re: Kerberos delegation support in libpq and postgres_fdw

Greetinsg, * Jacob Champion (pchamp...@vmware.com) wrote: > On Fri, 2022-03-11 at 19:39 -0500, Stephen Frost wrote: > > On Fri, Mar 11, 2022 at 18:55 Jacob Champion wrote: > > > [5] says we have to free the proxy credential with GSS_Release_cred(); > > > I don't see that happening anywhere, but

Re: [PATCH] Expose port->authn_id to extensions and triggers

On Wed, 2022-04-06 at 20:09 +0900, Michael Paquier wrote: > > The current patch already handles NULL with a byte of overhead; is > > there any advantage to using noError? (It might make things messier > > once a second member gets added to the struct.) My concern was directed > > at the GUC

Re: shared-memory based stats collector - v70

On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote: > Here comes v70: > Some small nitpicks on the docs: > From 13090823fc4c7fb94512110fb4d1b3e86fb312db Mon Sep 17 00:00:00 2001 > From: Andres Freund > Date: Sat, 2 Apr 2022 19:38:01 -0700 > Subject: [PATCH v70 14/27] pgstat: update docs. >

Re: How about a psql backslash command to show GUCs?

On Wed, 6 Apr 2022 at 13:50, Tom Lane wrote: > > when I want to see some related parameters, or when I'm a bit > fuzzy on the exact name of the parameter. Not only is this > a lot of typing, but unless I'm willing to type even more to > avoid using "*", I'll get a wall of mostly unreadable text,

Re: How about a psql backslash command to show GUCs?

Joe Conway writes: > No as sure about \show though. That seems like it could be confused with > showing other stuff. Maybe consistent with \sf[+] and \sv[+] we could > add \sc[+]? Hmm ... my first reaction to that was "no, it should be \sp for 'parameter'". But with the neighboring \sf for

Re: How about a psql backslash command to show GUCs?

On 4/6/22 13:58, Alvaro Herrera wrote: On 2022-Apr-06, Tom Lane wrote: However, I very often find myself resorting to the much more tedious select * from pg_settings where name like '%foo%'; when I want to see some related parameters, or when I'm a bit fuzzy on the exact name of the

Should pg_dumpall dump ALTER SYSTEM settings?

Commit a0ffa885e included some code that makes "pg_dumpall -g" dump GRANT commands for any GUCs that have had nondefault privileges granted on them. I pushed that without complaint, but it feels a little weird to me that we are worrying about preserving grants for GUCs when we don't worry about

Re: SQL/JSON: JSON_TABLE

Hi, On 2022-04-06 11:11:42 -0400, Stephen Frost wrote: > Maybe we should add --no-unlogged-table-data to those pg_dumpall runs? Yes, I think we should. And then we should explicitly add an unlogged table that isn't dropped. That way we get pg_upgrade testing etc. Thomas, what do you think?

Re: How about a psql backslash command to show GUCs?

> On Apr 6, 2022, at 10:48 AM, Tom Lane wrote: > > So does anyone else like this idea? Privileges on targets other than parameters have a \d command to show the privileges, as listed in doc/src/sgml/ddl.sgml. There isn't an obvious reason for omitting parameters from the list so covered.

Re: How about a psql backslash command to show GUCs?

On 2022-Apr-06, Tom Lane wrote: > However, I very often find myself resorting to the much more tedious > > select * from pg_settings where name like '%foo%'; > > when I want to see some related parameters, or when I'm a bit > fuzzy on the exact name of the parameter. Been there many times, so

Re: SQL/JSON: JSON_TABLE

On 4/6/22 12:59, Andres Freund wrote: > Hi, > > On 2022-04-06 11:50:11 -0400, Andrew Dunstan wrote: >> It does work, but Tom prefers not to have the test at all, so I'll just >> rip it out. > If I understand correctly the reason a large table is needed is to test > parallelism, right? Wouldn't

Re: How about a psql backslash command to show GUCs?

hi st 6. 4. 2022 v 19:49 odesílatel Tom Lane napsal: > It's not difficult to get psql to show you the current value > of a single GUC --- "SHOW" does that fine, and it has tab > completion support for the GUC name. However, I very often > find myself resorting to the much more tedious > >

How about a psql backslash command to show GUCs?

It's not difficult to get psql to show you the current value of a single GUC --- "SHOW" does that fine, and it has tab completion support for the GUC name. However, I very often find myself resorting to the much more tedious select * from pg_settings where name like '%foo%'; when I want to see

Re: [Proposal] vacuumdb --schema only

Le 30/03/2022 à 23:22, Nathan Bossart a écrit : > I took a look at the v4 patch. > > 'git-apply' complains about whitespace errors: Fixed. > + > +To clean all tables in the Foo and > bar schemas > +only in a database named xyzzy: > + > +$ vacuumdb --schema='"Foo"' --schema='bar' >

buildfarm failures, src/test/recovery

Hi Andrew, It appears to me that 2ef6f11b0c77ec323c688ddfd98ffabddb72c11d broke src/test/recovery. It looks like the following fixes it. Care to review and push? Or perhaps just revert that commit? diff --git a/src/test/regress/expected/jsonb_sqljson.out

Re: Granting SET and ALTER SYSTE privileges for GUCs

I wrote: > Here's v17 rebased up to HEAD. Pushed after fooling around with the docs. I have a couple of followup ideas in mind (\dcp and another one), which I'll start separate threads about. regards, tom lane

Re: psql - add SHOW_ALL_RESULTS option - pg_regress output

Hi, On 2022-04-06 10:37:29 +0200, Peter Eisentraut wrote: > On 06.04.22 04:06, Andres Freund wrote: > > On 2022-04-04 23:32:50 +0200, Peter Eisentraut wrote: > > > This has been committed. > > > > It's somewhat annoying that made pg_regress even more verbose than before: > > > > ==

Re: SQL/JSON: JSON_TABLE

Hi, On 2022-04-06 11:50:11 -0400, Andrew Dunstan wrote: > It does work, but Tom prefers not to have the test at all, so I'll just > rip it out. If I understand correctly the reason a large table is needed is to test parallelism, right? Wouldn't the better fix be to just tweak the parallelism

Re: [PATCH] pg_stat_toast

Hi, On 2022-04-06 12:24:20 -0400, Robert Haas wrote: > On Wed, Apr 6, 2022 at 12:01 PM Gunnar "Nick" Bluth > wrote: > > Fair enough. At that point, a lot of things become unexpectedly painful. > > How many % of the installed base may that be though? > > I don't have statistics on that, but it's

Re: Mingw task for Cirrus CI

Hi, On 2022-04-06 11:03:37 -0400, Andrew Dunstan wrote: > On 3/30/22 20:26, Andres Freund wrote: > > Could you try using dash to invoke configure here, and whether it makes > > configure faster? > I got weird failures re libxml/parser.h when I tried with dash. Hm. Hadn't enabled that when I

Re: [PATCH] pg_stat_toast

On Wed, Apr 6, 2022 at 12:01 PM Gunnar "Nick" Bluth wrote: > Fair enough. At that point, a lot of things become unexpectedly painful. > How many % of the installed base may that be though? I don't have statistics on that, but it's large enough that the expense associated with the statistics

Re: shared-memory based stats collector - v70

Hi, On 2022-04-06 16:24:28 +0700, John Naylor wrote: > On Wed, Apr 6, 2022 at 10:00 AM Andres Freund wrote: > > - while working on the above point, I noticed that hash_bytes() showed up > > noticeably in profiles, so I replaced it with a fixed-width function > > I'm curious about this --

Re: [PATCH] pg_stat_toast

Am 06.04.22 um 17:49 schrieb Robert Haas: > I feel like if you want to know whether externalization made a > difference, you can look at the size of the TOAST table. And by > selecting directly from that table, you can even see how many chunks > it contains, and how many are full-sized chunks vs.

Re: shared-memory based stats collector - v70

Hi, On 2022-04-06 13:31:31 +0200, Alvaro Herrera wrote: > Just skimming a bit here ... Thanks! > On 2022-Apr-05, Andres Freund wrote: > > > From 0532b869033595202d5797b148f22c61e4eb4969 Mon Sep 17 00:00:00 2001 > > From: Andres Freund > > Date: Mon, 4 Apr 2022 16:53:16 -0700 > > Subject:

Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

I already rebased this in a local branch, so here it's. I don't expect it to survive the day. This should be updated to use the tuplestore helper. >From bc4afef0bf0cb34d90fb6c029ab4c5ff1a6d033d Mon Sep 17 00:00:00 2001 From: Melanie Plageman Date: Mon, 11 Oct 2021 16:15:06 -0400 Subject: [PATCH

Re: pg14 psql broke \d datname.nspname.relname

> On Mar 29, 2022, at 8:20 AM, Robert Haas wrote: > > In describe.c, why are the various describeWhatever functions > returning true when validateSQLNamePattern returns false? It seems to > me that they should return false. That would cause exec_command_d() to > set status = PSQL_CMD_ERROR,

Re: SQL/JSON: JSON_TABLE

Andrew Dunstan writes: >> I think we should, but I think here the obvious solution is to drop the >> table when we're done with it. I'll test that. > It does work, but Tom prefers not to have the test at all, so I'll just > rip it out. Perhaps moving it to some other place

Re: shared-memory based stats collector - v70

Hi, On 2022-04-06 18:11:04 +0900, Kyotaro Horiguchi wrote: > 0004: > > I can see padding_pgstat_send and fun:pgstat_send in valgrind.supp Those shouldn't be affected by the patch, I think? But I did indeed forget to remove those in 0010. > 0006: > > I'm fine with the categorize for now. > >

Re: Last day of commitfest

Greg Stark writes: > The commitfest ends with the feature freeze in less than 48 hours. Just to clarify --- I think what has been agreed to is that we'll close the CF as of the announced time (noon UTC Friday), but Robert and I will push in our two wide-ranging patches after that. You might as

Re: [PATCH] pg_stat_toast

Am 06.04.22 um 17:22 schrieb Robert Haas: > On Tue, Apr 5, 2022 at 10:34 PM Andres Freund wrote: >>> Anyway, my (undisputed up to now!) understanding still is that only >>> backends _looking_ at these stats (so, e.g., accessing the pg_stat_toast >>> view) actually read the data. So, the 10-15%

Last day of commitfest

The commitfest ends with the feature freeze in less than 48 hours. I'm going to start moving patches that are Waiting On Author and haven't received comment in more than a few days out of the commitfset. If the patch has received a review or good feedback then I'll mark it Returned With Feedback.

Re: [PATCH] pg_stat_toast

On Wed, Apr 6, 2022 at 11:49 AM Alvaro Herrera wrote: > On 2022-Apr-06, Robert Haas wrote: > > Now if we're only incurring that overhead when this feature is > > enabled, then in fairness that problem is a lot less of an issue, > > especially if this is also disabled by default. People who want

Re: SQL/JSON: JSON_TABLE

On 4/6/22 11:33, Andrew Dunstan wrote: > On 4/6/22 11:11, Stephen Frost wrote: >> Greetings, >> >> * Andrew Dunstan (and...@dunslane.net) wrote: >>> On 4/6/22 09:20, Andrew Dunstan wrote: On 4/5/22 22:21, Andres Freund wrote: > On 2022-03-27 16:53:57 -0400, Andrew Dunstan wrote: >>

Re: [PATCH] pg_stat_toast

On Tue, Apr 5, 2022 at 6:08 PM Gunnar "Nick" Bluth wrote: > At the end of the day, one could argue like you did there for almost all > (non-attribute) stats. "Why track function execution times? Just set up > a benchmark and call the function 1 mio times and you'll know how long > it takes on

Re: [PATCH] pg_stat_toast

On 2022-Apr-06, Robert Haas wrote: > Now if we're only incurring that overhead when this feature is > enabled, then in fairness that problem is a lot less of an issue, > especially if this is also disabled by default. People who want the > data can get it and pay the cost, and others aren't much

Re: SQL/JSON: JSON_TABLE

On 4/6/22 11:11, Stephen Frost wrote: > Greetings, > > * Andrew Dunstan (and...@dunslane.net) wrote: >> On 4/6/22 09:20, Andrew Dunstan wrote: >>> On 4/5/22 22:21, Andres Freund wrote: On 2022-03-27 16:53:57 -0400, Andrew Dunstan wrote: > I'm therefore going to commit this series

Re: Practical Timing Side Channel Attacks on Memory Compression

On Wed, 6 Apr 2022 at 10:29, Robert Haas wrote: > > I think that the paper shows that, under the right set of > circumstances, a timing-based attack is possible here. Generally any argument that an attack is infeasible is risky and usually leads to security professionals showing that

Re: [PATCH] pg_stat_toast

On Tue, Apr 5, 2022 at 10:34 PM Andres Freund wrote: > > Anyway, my (undisputed up to now!) understanding still is that only > > backends _looking_ at these stats (so, e.g., accessing the pg_stat_toast > > view) actually read the data. So, the 10-15% more space used for pg_stat > > only affect

Re: SQL/JSON: JSON_TABLE

Greetings, * Andrew Dunstan (and...@dunslane.net) wrote: > On 4/6/22 09:20, Andrew Dunstan wrote: > > On 4/5/22 22:21, Andres Freund wrote: > >> On 2022-03-27 16:53:57 -0400, Andrew Dunstan wrote: > >>> I'm therefore going to commit this series > >> The new jsonb_sqljson test is, on my machine,

Re: REINDEX blocks virtually any queries but some prepared queries.

On Wed, Apr 6, 2022 at 7:49 AM Frédéric Yhuel wrote: > From the documentation > (https://www.postgresql.org/docs/current/sql-reindex.html#id-1.9.3.162.7), > it sounds like REINDEX won't block read queries that don't need the > index. But it seems like the planner wants to take an ACCESS SHARE

Re: Mingw task for Cirrus CI

On 3/30/22 20:26, Andres Freund wrote: > Could you try using dash to invoke configure here, and whether it makes > configure faster? > > I got weird failures re libxml/parser.h when I tried with dash. See (It would be nice if we could see

Re: SQL/JSON: JSON_TABLE

On 4/6/22 09:20, Andrew Dunstan wrote: > On 4/5/22 22:21, Andres Freund wrote: >> Hi, >> >> On 2022-03-27 16:53:57 -0400, Andrew Dunstan wrote: >>> I'm therefore going to commit this series >> The new jsonb_sqljson test is, on my machine, the slowest test in the main >> regression tests: >> >>

REINDEX blocks virtually any queries but some prepared queries.

Hello, From the documentation (https://www.postgresql.org/docs/current/sql-reindex.html#id-1.9.3.162.7), it sounds like REINDEX won't block read queries that don't need the index. But it seems like the planner wants to take an ACCESS SHARE lock on every indexes, regardless of the query, and

Re: Practical Timing Side Channel Attacks on Memory Compression

On Wed, Apr 6, 2022 at 10:14 AM Tom Lane wrote: > Robert Haas writes: > > One last thought: I don't think it's right to suppose that every > > security vulnerability is the result of some design flaw and every > > security vulnerability must be patched. > > As far as Postgres is concerned, I'm

Re: Practical Timing Side Channel Attacks on Memory Compression

Robert Haas writes: > One last thought: I don't think it's right to suppose that every > security vulnerability is the result of some design flaw and every > security vulnerability must be patched. As far as Postgres is concerned, I'm kind of unimpressed by timing-based attacks. There are

Re: logical decoding and replication of sequences

On 4/5/22 12:06, Amit Kapila wrote: > On Mon, Apr 4, 2022 at 3:10 AM Tomas Vondra > wrote: >> >> I did some experiments over the weekend, exploring how to rework the >> sequence decoding in various ways. Let me share some WIP patches, >> hopefully that can be useful for trying more stuff and

Re: OpenSSL deprectation warnings in Postgres 10-13

В Wed, 6 Apr 2022 15:01:42 +0200 Peter Eisentraut пишет: > On 06.04.22 11:55, Victor Wagner wrote: > > And found out that versions 10-13 produce a lot of warnings about > > deprecated OpenSSL functions. > > > > I've found discussion about this problem > > > >

Re: Practical Timing Side Channel Attacks on Memory Compression

On Wed, Apr 6, 2022 at 7:18 AM Filip Janus wrote: > A few months ago a group of researchers published a paper about LZ77 > vulnerability[1]. And it also affects PGLZ. From my point of view, it could > be a really dangerous issue for some kind of application. If I understand it > correctly

Re: SQL/JSON: JSON_TABLE

On 4/5/22 22:21, Andres Freund wrote: > Hi, > > On 2022-03-27 16:53:57 -0400, Andrew Dunstan wrote: >> I'm therefore going to commit this series > The new jsonb_sqljson test is, on my machine, the slowest test in the main > regression tests: > > 4639 ms jsonb_sqljson > 2401 ms btree_index > 2166

Re: BufferAlloc: don't take two simultaneous locks

Good day, Kyotaoro-san. Good day, hackers. В Вс, 20/03/2022 в 12:38 +0300, Yura Sokolov пишет: > В Чт, 17/03/2022 в 12:02 +0900, Kyotaro Horiguchi пишет: > > At Wed, 16 Mar 2022 14:11:58 +0300, Yura Sokolov > > wrote in > > > В Ср, 16/03/2022 в 12:07 +0900, Kyotaro Horiguchi пишет: > > > > At

logical replication of identity sequences

Identity sequences shouldn't be addressed directly by name in normal use. Therefore, requiring them to be added directly to publications is a faulty interface. I think they should be considered included in a publication automatically when their owning table is. See attached patch for a

Re: OpenSSL deprectation warnings in Postgres 10-13

On 06.04.22 11:55, Victor Wagner wrote: And found out that versions 10-13 produce a lot of warnings about deprecated OpenSSL functions. I've found discussion about this problem https://www.postgresql.org/message-id/flat/FEF81714-D479-4512-839B-C769D2605F8A%40yesql.se and commit

RE: Logical replication timeout problem

On Wed, Apr 6, 2022 at 1:59 AM Amit Kapila wrote: On Wed, Apr 6, 2022 at 4:32 AM Amit Kapila wrote: > Thanks for your comments. > typedef void (*LogicalOutputPluginWriterUpdateProgress) (struct > LogicalDecodingContext *lr, > XLogRecPtr Ptr, > TransactionId xid, > - bool skipped_xact > +

Re: Unit tests for SLRU

Hi hackers, > OK, here is an updated version of the patch. Changes comparing to v1: > > * Tests are moved to regress.c, as asked by the majority; > * SimpleLruInit() returns void as before, per Daniel's feedback; > * Most of the initial refactorings were reverted in order to keep the patch > as

Re: PATCH: add "--config-file=" option to pg_rewind

Am 06.04.22 um 14:04 schrieb Michael Paquier: > On Tue, Apr 05, 2022 at 11:10:30AM +0900, Michael Paquier wrote: >> In the tests, the only difference between the modes "archive_cli" and >> "archive" is the extra option given to the pg_rewind command, and >> that's a simple redirect to what

  1   2   >