Re: Skipping schema changes in publication

On Fri, May 20, 2022 at 11:23 AM Peter Smith wrote: > > Below are my review comments for v6-0002. > > == > > 1. Commit message. > The psql \d family of commands to display excluded tables. > > SUGGESTION > The psql \d family of commands can now display excluded tables. Modified > ~~~ > > 2.

Re: Skipping schema changes in publication

On Fri, May 20, 2022 at 5:49 AM Peter Smith wrote: > > FYI, although the v6-0002 patch applied cleanly, I found that the SGML > was malformed and so the pg docs build fails. > > ~~~ > e.g. > > [postgres@CentOS7-x64 sgml]$ make STYLE=website html > { \ > echo ""; \ > echo ""; \ > } >

Re: Skipping schema changes in publication

On Thu, May 19, 2022 at 1:49 PM Peter Smith wrote: > > Below are my review comments for v6-0001. > > == > > 1. General. > > The patch failed 'publication' tests in the make check phase. > > Please add this work to the commit-fest so that the 'cfbot' can report > such errors sooner. Added

Re: PG15 beta1 fix pg_stat_recovery_prefetch view manual

On Sat, May 21, 2022 at 4:07 PM Shinoda, Noriyoshi (PN Japan FSIP) wrote: > Thanks to all the developers. The attached patch updates the manual for the > pg_stat_recovery_prefetch view. > The current pg_stat_recovery_prefetch view definition is missing the > stats_reset column. The attached

PG15 beta1 fix pg_stat_recovery_prefetch view manual

Hi hackers, Thanks to all the developers. The attached patch updates the manual for the pg_stat_recovery_prefetch view. The current pg_stat_recovery_prefetch view definition is missing the stats_reset column. The attached patch adds information in the stats_reset column.

RE: PG15 beta1 fix pg_stat_statements view document

Hi, Thank you for your comment. I attached the fixed patch. -Original Message- From: Michael Paquier Sent: Saturday, May 21, 2022 12:33 PM To: Nathan Bossart Cc: Shinoda, Noriyoshi (PN Japan FSIP) ; PostgreSQL-development ; mag...@hagander.net Subject: Re: PG15 beta1 fix

Re: Build-farm - intermittent error in 031_column_list.pl

On Fri, May 20, 2022 at 4:01 PM Tomas Vondra wrote: > > On 5/20/22 05:58, Amit Kapila wrote: > > Are we really querying the publications (in get_rel_sync_entry) using > the historical snapshot? > Yes. > I haven't really realized this, but yeah, that > might explain the issue. > > The new TAP

Re: PG15 beta1 fix pg_stat_statements view document

On Fri, May 20, 2022 at 04:04:29PM -0700, Nathan Bossart wrote: > I think there is a typo in the change to the jit_optimization_time section, > but otherwise it looks good to me. Yes, as of "double precisiodouble precision". All these four fields are indeed doubles in the code, for what looks

Re: docs: mention "pg_read_all_stats" in "track_activities" description

On Fri, May 20, 2022 at 04:08:37PM -0700, Nathan Bossart wrote: > LGTM Indeed, it is a good idea to add this information. Will apply and backpatch accordingly. -- Michael signature.asc Description: PGP signature

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

On Fri, May 20, 2022 at 06:28:01PM -0700, Noah Misch wrote: > Looks successful. Thanks a lot for confirming. I have applied that on HEAD, then. -- Michael signature.asc Description: PGP signature

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

On Wed, May 18, 2022 at 06:20:08PM +0900, Michael Paquier wrote: > Attached is an updated patch to address your concerns. Looks successful.

Re: allow building trusted languages without the untrusted versions

Nathan Bossart writes: > Presently, if you want to only build trusted PL/Perl and PL/Tcl, you need > to make a couple of code changes to compile out the untrusted parts. I > suspect many users (e.g., anyone who wants to disallow file system access) > would benefit from a better supported way to

Re: Limiting memory allocation

On 5/20/22 21:50, Stephen Frost wrote: > Greetings, > > ... > >>> How exactly this would work is unclear to me; maybe one >>> process keeps an eye on it in an OS-specific manner, > > There seems to be a lot of focus on trying to implement this as "get the > amount of free memory from the OS and

Re: docs: mention "pg_read_all_stats" in "track_activities" description

On Fri, May 20, 2022 at 03:17:29PM +0900, Ian Lawrence Barwick wrote: > It seems reasonable to mention here that the information is also visible to > members of "pg_read_all_stats", similar to what is done in the > pg_stat_statements > docs [2]. > > [2] >

Re: PG15 beta1 fix pg_stat_statements view document

On Fri, May 20, 2022 at 12:46:03PM +, Shinoda, Noriyoshi (PN Japan FSIP) wrote: > The attached patch modifies the pg_stat_statements view documentation updated > in PostgreSQL 15 Beta 1. > The data type of the following columns in the pg_stat_statements view is > bigint in the current

allow building trusted languages without the untrusted versions

Hi hackers, Presently, if you want to only build trusted PL/Perl and PL/Tcl, you need to make a couple of code changes to compile out the untrusted parts. I suspect many users (e.g., anyone who wants to disallow file system access) would benefit from a better supported way to do this. Thus,

Re: Add --{no-,}bypassrls flags to createuser

On Thu, May 19, 2022 at 10:35:23AM +0900, Shinya Kato wrote: > I created a new patch to test the new options! Thanks for the new patch! I attached a new version with a few small changes. What do you think? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com >From

Re: CPU time for pg_stat_statement

Hello, Tom. > This is a pretty broad claim to make on the basis of one undocumented > test case on one unmentioned platform. I'll try to use pg_stat_kcache to check the difference between Wall and CPU for my case. > On what grounds do you claim getrusage will be better? One thing we > can be

Re: CPU time for pg_stat_statement

Hello, Thomas. > This might be interesting: > https://github.com/powa-team/pg_stat_kcache Oh, nice, looks like it could help me to reduce CPU and test my assumption (using exec_user_time and exec_system_time). BWT, do you know why extension is not in standard contrib (looks mature)? Best

Re: CPU time for pg_stat_statement

On Sat, May 21, 2022 at 6:50 AM Michail Nikolaev wrote: > But what do you think about adding cpu_time (by calling getrusage) to > pg_stat_statements? Seems it could be very useful for CPU profiling. > > I am probably able to prepare the patch, but it is always better to > get some feedback on the

Re: CPU time for pg_stat_statement

Michail Nikolaev writes: > So, looks like clock_gettime is not so accurate to measure real CPU > usage for some OLTP workloads. I suppose it is caused by the wall time > vs CPU time difference (IO, thread switch, etc). This is a pretty broad claim to make on the basis of one undocumented test

Re: check for null value before looking up the hash function

Zhihong Yu writes: > I was looking at the code in hash_record() > of src/backend/utils/adt/rowtypes.c > It seems if nulls[i] is true, we don't need to look up the hash function. I don't think this is worth changing. It complicates the logic, rendering it unlike quite a few other functions

Re: Zstandard support for toast compression

Greetings, * Nikolay Shaplov (dh...@nataraj.su) wrote: > В письме от вторник, 17 мая 2022 г. 23:01:07 MSK пользователь Tom Lane > написал: > > Hi! I came to this branch looking for a patch to review, but I guess I would > join the discussion instead of reading the code. Seems that's what

Re: Inquiring about my GSoC Proposal.

Greetings, * Israa Odeh (israa2...@hotmail.com) wrote: > I was wondering if you could provide me with initial feedback on my GSoC > proposal, as well as if you have any comments about it. And would it be > possible to know whether I got accepted as a contributor? Google published this

Re: Limiting memory allocation

Greetings, * Oleksii Kliukin (al...@hintbits.com) wrote: > > On 18. May 2022, at 17:11, Alvaro Herrera wrote: > > On 2022-May-18, Jan Wieck wrote: > >> Maybe I'm missing something, but what is it that you would actually > >> consider > >> a solution? Knowing your current memory consumption

CPU time for pg_stat_statement

Hello, hackers. Today I was doing some aggregates over pg_stat_statements in order to find types of queries consuming most of the CPU. Aggregates were made on two pg_state_statement snapshots within 30 sec delay. The sum(total_time) had the biggest value for a very frequent query with about 10ms

check for null value before looking up the hash function

Hi, I was looking at the code in hash_record() of src/backend/utils/adt/rowtypes.c It seems if nulls[i] is true, we don't need to look up the hash function. Please take a look at the patch. Thanks hash-record-check-null-first.patch Description: Binary data

Re: Limiting memory allocation

Hi, > On 18. May 2022, at 17:11, Alvaro Herrera wrote: > > On 2022-May-18, Jan Wieck wrote: > >> Maybe I'm missing something, but what is it that you would actually consider >> a solution? Knowing your current memory consumption doesn't make the need >> for allocating some right now go away.

Re: 15beta1 test failure on mips in isolation/expected/stats

I wrote: > Andres Freund writes: >> I think what might be happening is that the transactional stats updates get >> reported by s2 *before* the non-transactional stats updates come in from >> s1. I.e. the pgstat_report_stat() at the end of s2_commit_prepared_a does a >> report, because the machine

RE: Build-farm - intermittent error in 031_column_list.pl

On Thursday, May 19, 2022 8:13 PM Amit Kapila wrote: > On Thu, May 19, 2022 at 3:16 PM Amit Kapila > wrote: > > > > On Thu, May 19, 2022 at 12:28 PM Kyotaro Horiguchi > > wrote: > > > > > > At Thu, 19 May 2022 14:26:56 +1000, Peter Smith > > > wrote in > > > > Hi hackers. > > > > > > > > FYI,

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

CFbot says v12 patch does not apply. Rebased. PFA v13. Your reviews are very much welcome! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com From 21fe45c0ae8479e0733bd8caeb5d2a19d715e0d9 Mon Sep 17 00:00:00 2001 From: Pavel Borisov Date:

PG15 beta1 fix pg_stat_statements view document

Hi hackers, The attached patch modifies the pg_stat_statements view documentation updated in PostgreSQL 15 Beta 1. The data type of the following columns in the pg_stat_statements view is bigint in the current document, but it is actually double precision. jit_generation_time

Re: [RFC] Improving multi-column filter cardinality estimation using MCVs and HyperLogLog

On 5/19/22 19:59, Matthias van de Meent wrote: > On Mon, 16 May 2022 at 00:09, Tomas Vondra > mailto:tomas.von...@enterprisedb.com>> > wrote: >> >> On 5/15/22 21:55, Matthias van de Meent wrote: >> > Note: I am not (currently) planning on implementing this rough idea, >> > just putting it up to

Re: Addition of PostgreSQL::Test::Cluster::pg_version()

On Thu, May 19, 2022 at 07:28:53AM -0400, Andrew Dunstan wrote: > Looks ok. PostgreSQL::Version is designed so that the object behaves > sanely in comparisons and when interpolated into a string. Okay, I have applied this thing. I'll move back to my business with the tests of pg_upgrade... --

Re: Build-farm - intermittent error in 031_column_list.pl

On 5/20/22 05:58, Amit Kapila wrote: > On Fri, May 20, 2022 at 6:58 AM Kyotaro Horiguchi > wrote: >> the apply worker will use the existing slot and replication origin corresponding to the subscription. Now, it is possible that before restart the origin has not been updated and

Re: Handle infinite recursion in logical replication setup

On Thu, May 19, 2022 at 2:12 PM shiy.f...@fujitsu.com wrote: > > On Wed, May 4, 2022 2:47 PM vignesh C wrote: > > > > Thanks for the comments, the attached v13 patch has the changes for the > > same. > > > > Here are some comments on v13-0002 patch. > > 1) > +* Throw an error so

Re: PG15 beta1 sort performance regression due to Generation context change

On 20/05/2022 08:56, David Rowley wrote: The problem is that generation chunks have a larger chunk header than aset do due to having to store the block pointer that the chunk belongs to so that GenerationFree() can increment the nfree chunks in the block. aset.c does not require this as freed

Re: Handle infinite recursion in logical replication setup

On Wed, May 18, 2022 at 4:22 PM Amit Kapila wrote: > > On Wed, May 18, 2022 at 10:29 AM Amit Kapila wrote: > > > > On Wed, May 4, 2022 at 12:17 PM vignesh C wrote: > > > > > > Thanks for the comments, the attached v13 patch has the changes for the > > > same. > > > > > > > Few comments on

Re: Handle infinite recursion in logical replication setup

On Wed, May 18, 2022 at 1:40 PM shiy.f...@fujitsu.com wrote: > > On Wed, May 4, 2022 2:47 PM vignesh C wrote: > > > > Thanks for the comments, the attached v13 patch has the changes for the > > same. > > > > Thanks for your patch. Here are some comments on v13-0001 patch. > > 1) > @@ -152,6

Re: 15beta1 crash on mips64el in pg_regress/triggers

Re: Tom Lane > Many kilowatt-hours later, I've entirely failed to reproduce this > on gcc230. Not sure how to investigate further. Given that your > original build machine is so slow, could it be timing-related? > Hard to see how, given the location of the crash, but ... My other rebuild (on

Re: A qsort template

On Fri, May 20, 2022 at 5:43 AM Tom Lane wrote: > > Peter Geoghegan writes: > > On Thu, May 19, 2022 at 1:12 PM Justin Pryzby wrote: > >> Should these debug lines be removed ? > >> > >> elog(DEBUG1, "qsort_tuple"); > > > I agree -- DEBUG1 seems too chatty for something like this. DEBUG2 > >

docs: mention "pg_read_all_stats" in "track_activities" description

Hi Regarding the visibility of query information, the description for "track_activities" [1] says: > Note that even when enabled, this information is not visible to all users, > only to superusers and the user owning the session being reported on, so it > should not represent a security risk.