Re: define pg_structiszero(addr, s, r)

before the last loop? If so, I did a few tests and did not see any major improvements. So, I thought it's simpler to not add more code in this inline function in v7 shared up-thread. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: define pg_structiszero(addr, s, r)

Hi, On Wed, Nov 06, 2024 at 12:16:33PM +1300, David Rowley wrote: > On Wed, 6 Nov 2024 at 04:03, Bertrand Drouvot > wrote: > > Another option could be to use SIMD instructions to check multiple bytes > > is zero in a single operation. Maybe just an idea to keep in mind and >

Re: per backend I/O statistics

Hi, On Wed, Nov 06, 2024 at 08:39:07AM +0900, Michael Paquier wrote: > On Tue, Nov 05, 2024 at 05:37:15PM +0000, Bertrand Drouvot wrote: > > I'm starting working on option 2, I think it will be easier to discuss with > > a patch proposal to look at. > > > >

Re: define pg_structiszero(addr, s, r)

fully agree. My initial testing was not "good" enough and so was not showing as much improvement as your's and David's ones. Please find v8 attached. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: define pg_structiszero(addr, s, r)

ne either, thanks for the explanation. +1, thanks! Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: per backend I/O statistics

Hi, On Thu, Nov 07, 2024 at 04:32:44PM +, Bertrand Drouvot wrote: > Hi, > > On Thu, Nov 07, 2024 at 09:50:59AM +0900, Michael Paquier wrote: > > On Wed, Nov 06, 2024 at 01:51:02PM +, Bertrand Drouvot wrote: > > > That's not needed, the patch I'm workin

Re: relfilenode statistics

Hi, On Fri, Nov 29, 2024 at 11:23:12AM +0500, Kirill Reshke wrote: > On Tue, 5 Nov 2024 at 11:06, Bertrand Drouvot > wrote: > > > > > > Does it sound ok to you to move with the above principal? (I'm +1 on it). > > > > Hi! I looked through this thread. T

Re: per backend I/O statistics

Hi, On Tue, Nov 19, 2024 at 10:47:53AM +0900, Michael Paquier wrote: > On Thu, Nov 14, 2024 at 01:30:11PM +0000, Bertrand Drouvot wrote: > > - change the arguments to false in the pgstat_drop_entry_internal() call in > > pgstat_drop_all_entries() > > - start the engine &

Re: per backend I/O statistics

Hi, On Fri, Nov 22, 2024 at 10:36:29AM +0900, Michael Paquier wrote: > On Thu, Nov 21, 2024 at 05:23:42PM +0000, Bertrand Drouvot wrote: > > So, given that: > > > > - the end result would be the same > > - the code changes would be non negligible (unless we h

Re: Make pg_stat_io view count IOs as bytes instead of blocks

ontext are passed only for the assertions. What about removing them from there and put the asserts in other places? === 4 + /* Only IOOP_READ, IOOP_WRITE and IOOP_EXTEND can do IO in bytes. */ Not sure about "can do IO in bytes" (same wording is used in multiple places). === 5

Re: per backend I/O statistics

Hi, On Wed, Nov 27, 2024 at 03:33:38PM +0900, Michael Paquier wrote: > On Mon, Nov 25, 2024 at 03:47:59PM +0000, Bertrand Drouvot wrote: > > It also takes care of most of the comments that you have made in [1], > > meaning > > that it: > > > > - removes the bac

Re: fix deprecation mention for age() and mxid_age()

Hi, On Tue, Nov 19, 2024 at 10:09:57AM +0900, Michael Paquier wrote: > On Mon, Nov 18, 2024 at 08:11:57AM +0000, Bertrand Drouvot wrote: > > Also it looks like that for PG 16, 7471230cc6, did put the functions > > description > > in the "Control Data Functions". T

Re: Parametrization minimum password lenght

uto_explain means "In ordinary usage, these parameters are set in postgresql.conf," [1]: https://github.com/postgres/postgres/blob/master/src/tools/ci/README [2]: https://www.postgresql.org/message-id/ZzsZZY3YrO6hinnT%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Ber

Re: per backend I/O statistics

Hi, On Wed, Nov 20, 2024 at 09:01:26AM +0900, Michael Paquier wrote: > On Tue, Nov 19, 2024 at 04:28:55PM +0000, Bertrand Drouvot wrote: > > So, for the startup process only, what about? > > > > - don't call pgstat_create_backend_stat() in pgstat_beinit()... > &

Re: Add a write_to_file member to PgStat_KindInfo

211 insertions(+), 2 deletions(-) v2: 8 files changed, 152 insertions(+), 22 deletions(-) I don't have a strong opinion for this particular case here (I think the code is harder to read but yeah there is some code reduction): so I'm fine with v2 too. Regards, -- Bertrand Drouvot Post

Re: per backend I/O statistics

eah, also this could useful for custom statistics. So I created a dedicated thread and a patch proposal (see [1]). [1]: https://www.postgresql.org/message-id/Zz3skBqzBncSFIuY%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Add a write_to_file member to PgStat_KindInfo

(the code changes are simple enough). [1]: https://www.postgresql.org/message-id/Zy4bmvgHqGjcK1pI%40ip-10-97-1-34.eu-west-3.compute.internal Looking forward to your feedback, Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https

Re: define pg_structiszero(addr, s, r)

Hi, On Fri, Nov 15, 2024 at 09:30:25AM +0900, Michael Paquier wrote: > On Thu, Nov 14, 2024 at 12:33:20PM +0000, Bertrand Drouvot wrote: > Anyway, as you say, the > portability of v12 is OK even for sizeof(size_t) == 4 because we don't > rely on any hardcoded values, and this p

Re: define pg_structiszero(addr, s, r)

Hi, On Sat, Nov 16, 2024 at 11:42:54AM -0300, Ranier Vilela wrote: > > Em sex., 15 de nov. de 2024 às 11:43, Bertrand Drouvot < > > bertranddrouvot...@gmail.com> escreveu: > > > >> while that should be: > >> > >> " > >> static inlin

Re: Potential ABI breakage in upcoming minor releases

| don't use 5-7 bytes| use first (hole_size - 4) bytes only Does that make sense? Regards, [1]: https://wiki.postgresql.org/wiki/Committing_checklist -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: define pg_structiszero(addr, s, r)

e: " static inline bool pg_memory_is_all_zeros_simd(const void *p, const void *end) " Doing so, I do not observe any improvments with v14. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Parametrization minimum password lenght

g (see auto_explain.c for example). === 10 + + In postgresql.conf you may set the minimum password length + by setting passwordcheck.min_password_length = INT. I think that would make sense to add a "Configuration Parameters" section and follow the format done in auto-explain or pg_p

fix deprecation mention for age() and mxid_age()

4013224.4z6oxa6p6va33rxr%40awork3.anarazel.de Looking forward to your feedback, Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com >From 26e0211f2a1366d6e345caeb0fbfd1a7dff70774 Mon Sep 17 00:00:00 2001 From: Bertran

Re: Add a write_to_file member to PgStat_KindInfo

Hi, On Thu, Nov 21, 2024 at 10:38:28AM +0300, Nazir Bilal Yavuz wrote: > Hi, > > On Thu, 21 Nov 2024 at 09:32, Bertrand Drouvot > wrote: > > That was in fact the main reason why I added this test. But well, just > > adding the "write_to_file" in the injec

Re: Add a write_to_file member to PgStat_KindInfo

Hi, On Thu, Nov 21, 2024 at 04:26:47PM +0900, Michael Paquier wrote: > On Thu, Nov 21, 2024 at 06:32:03AM +0000, Bertrand Drouvot wrote: > > That was in fact the main reason why I added this test. But well, just > > adding the "write_to_file" in the injection test

Re: Add a write_to_file member to PgStat_KindInfo

Hi, On Thu, Nov 21, 2024 at 10:01:07AM +0900, Michael Paquier wrote: > On Wed, Nov 20, 2024 at 05:13:18PM +0000, Bertrand Drouvot wrote: > > I don't have a strong opinion for this particular case here (I think the > > code > > is harder to read but yeah there is some co

Re: BF mamba failure

ection points. But I'm not sure that's worth it, as the code in the patch looks "simple" enough. Thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: define pg_structiszero(addr, s, r)

ind attached v12, with more comments and comments changes to explain the multiple cases (for safety) and phases (for efficiency). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com >From 833f4c223717ce71c5b59d27ce5438

Re: define pg_structiszero(addr, s, r)

Hi, On Thu, Nov 14, 2024 at 08:22:23AM -0300, Ranier Vilela wrote: > Em qui., 14 de nov. de 2024 às 07:09, Bertrand Drouvot < > bertranddrouvot...@gmail.com> escreveu: > > > Hi, > > > > On Thu, Nov 14, 2024 at 09:27:06AM +0900, Michael Paquier wrote: > > &g

Re: Speed up TransactionIdIsCurrentTransactionId() with lots of subxacts

Hi, On Thu, Nov 14, 2024 at 12:16:52AM +0200, Heikki Linnakangas wrote: > On 13/11/2024 18:08, Bertrand Drouvot wrote: > > === 1 > > > > + parentOffset--; > > + parents[parentOffset]->totalXids = totalXids; > > > > what about "parents[-

Re: define pg_structiszero(addr, s, r)

Hi, On Thu, Nov 14, 2024 at 09:13:19AM -0300, Ranier Vilela wrote: > Em qui., 14 de nov. de 2024 às 08:58, Bertrand Drouvot < > Maybe I'm doing something wrong. > But I'm testing in 32-bit, with the size set to 63, with v12 and I'm seeing > the SIMD loop execute.

Re: per backend I/O statistics

Hi, On Thu, Nov 14, 2024 at 03:31:51PM +0900, Michael Paquier wrote: > On Fri, Nov 08, 2024 at 02:09:30PM +0000, Bertrand Drouvot wrote: > > 1. one assertion in pgstat_drop_entry_internal() is not necessary true > > anymore > > with this new stat kind. So, adding an extra

Re: per backend I/O statistics

Hi, On Mon, Nov 25, 2024 at 04:18:54PM +0900, Michael Paquier wrote: > On Mon, Nov 25, 2024 at 07:12:56AM +0000, Bertrand Drouvot wrote: > > Not sure here, could custom stats start incrementing before the database > > system > > is ready to accept connections? > &g

Re: per backend I/O statistics

Hi, On Mon, Nov 25, 2024 at 10:06:44AM +0900, Michael Paquier wrote: > On Fri, Nov 22, 2024 at 07:49:58AM +0000, Bertrand Drouvot wrote: > > On Fri, Nov 22, 2024 at 10:36:29AM +0900, Michael Paquier wrote: > >> Hmm. created_entry only matters for pgstat_init_function_usage().

Re: Potential ABI breakage in upcoming minor releases

ostgresql.org/message-id/flat/ZzcR%2BoQmUOIm6RVF%40ip-10-97-1-34.eu-west-3.compute.internal#08182ae6a6719632acf52fe4d90e9778 Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Drop back the redundant "Lock" suffix from LWLock wait event names

https://www.postgresql.org/message-id/flat/18728-450924477056a339%40postgresql.org [2]: https://www.postgresql.org/message-id/flat/202401231025.gbv4nnte5fmm%40alvherre.pgsql Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases

Re: relfilenode statistics

Hi, On Fri, Nov 29, 2024 at 08:52:13PM +0500, Kirill Reshke wrote: > On Fri, 29 Nov 2024 at 20:20, Bertrand Drouvot > wrote: > > On Fri, Nov 29, 2024 at 11:23:12AM +0500, Kirill Reshke wrote: > > > If we don’t have the relation OID when writing buffers out, can we &g

Re: Missing LWLock protection in pgstat_reset_replslot()

Hi, On Thu, Dec 05, 2024 at 01:26:38PM +0900, Michael Paquier wrote: > On Wed, Dec 04, 2024 at 03:20:03PM +0000, Bertrand Drouvot wrote: > > I need to think more about it but it seems to me that those values make > > sense, > > so maybe we should drop the entry for

Re: shared-memory based stats collector - v70

Hi, On Thu, Dec 05, 2024 at 02:43:43PM +0900, Michael Paquier wrote: > On Wed, Dec 04, 2024 at 03:24:55PM +0000, Bertrand Drouvot wrote: > > Thanks! I've the feeling that something has to be fixed, see my comments in > > [1]. It might be that the failed assertion does

Re: shared-memory based stats collector - v70

Hi, On Thu, Dec 05, 2024 at 05:13:13PM +0900, Michael Paquier wrote: > On Thu, Dec 05, 2024 at 07:37:27AM +0000, Bertrand Drouvot wrote: > > That said, I think that's worth to update the comment a bit (like in the > > attached?) as I think that answers a legitimate questio

Re: Missing LWLock protection in pgstat_reset_replslot()

" is false (entry_ref->shared_entry->generation is 1 while entry_ref->generation is 0). I need to think more about it but it seems to me that those values make sense, so maybe we should drop the entry for this particular case (shmem_exit()). Thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: shared-memory based stats collector - v70

ething has to be fixed, see my comments in [1]. It might be that the failed assertion does not handle a "valid" scenario. [1]: https://www.postgresql.org/message-id/Z1BzI/eMTCOKA%2Bj6%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Track the amount of time waiting due to cost_delay

Hi, On Thu, Dec 05, 2024 at 10:43:51AM +, Bertrand Drouvot wrote: > Yeah, people would likely use this new field to monitor long running vacuum. > Long enough that this error should be acceptable. Do you agree? OTOH, adding the 100% accuracy looks as simple as v9-0002 attached (0001 i

Re: shared-memory based stats collector - v70

at could help the tap test added in da99fedf8c to not rely on assert enabled build (the tap test could "simply" check for the WARNING in the logfile instead). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Track the amount of time waiting due to cost_delay

Hi, On Mon, Dec 09, 2024 at 05:18:30PM +0530, Dilip Kumar wrote: > On Mon, Dec 9, 2024 at 2:51 PM Masahiro Ikeda > wrote: > > > > On 2024-12-06 18:31, Bertrand Drouvot wrote: > > > Hi, > > > > > > On Thu, Dec 05, 2024 at 10:43:51AM +, Bertrand Dr

Re: Track the amount of time waiting due to cost_delay

Hi, On Mon, Dec 09, 2024 at 08:34:13PM +0530, Dilip Kumar wrote: > On Mon, Dec 9, 2024 at 6:55 PM Bertrand Drouvot > > Yeah. I think we could change the wording that way: > > > > s/waiting due to/waiting during/ > > > > Does that make sense? I don't th

Re: POC: enable logical decoding when wal_level = 'replica' without a server restart

to "activate logical decoding" and zero logical replication slot created would be synonym to "deactivate logical decoding". That way: 1. an end user don't need to manipulate new functions and would just rely on replication slots existence 2. we ensure that no extra WAL data is generated if not absolutely "needed" Thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Avoid orphaned objects dependencies, take 3

Hi, On Mon, Oct 28, 2024 at 09:30:19AM +, Bertrand Drouvot wrote: > Hi, > > On Mon, Aug 19, 2024 at 03:35:14PM +, Bertrand Drouvot wrote: > > Hi, > > > > On Wed, Jul 10, 2024 at 07:31:06AM +, Bertrand Drouvot wrote: > > > So, to sum up:

Re: PoC: history of recent vacuum/checkpoint runs (using new hooks)

ry often either. Thanks for working on this! Another idea regarding the storage of those metrics: I think that one would want to see "precise" data for recent metrics but would probably be fine with some level of aggregation for historical ones. Something like being able to retrieve &qu

per backend WAL statistics

keep this change as we may want to add more per backend stats in the future. Looking forward to your feedback, Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com >From 5c2241fcee52f7fb3cfea9890d495f51b981a9c0 Mon

Re: per backend I/O statistics

Hi, On Fri, Jan 03, 2025 at 10:48:41AM +, Bertrand Drouvot wrote: > I started to look at it and should be able to share a patch next week. A dedicated thread and a patch have been created, see [1]. [1]: https://www.postgresql.org/message-id/flat/Z3zqc4o09dM/Ezyz%40ip-10-97-1-34.eu-wes

Re: Fix handling of injection_points regarding pending stats

should" be done). > While doing so, I have also noticed that injection_stats_flush_cb() > missed a pgstat_unlock_entry() when entries get locked. Right. > All that is addressed in the patch attached. Feel free if you have > any comments. The patch is pretty straightforward and LGTM. Regards, --

Re: WAL-logging facility for pgstats kinds

So it makes === 7 useless as here we are setting all the fields. But I think it's good to keep === 7 as it acts as a template. === 9 + if (!RecoveryInProgress() && inj_stats_wal_enabled) s/!RecoveryInProgress()/XLogInsertAllowed()/ maybe? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Show WAL write and fsync stats in pg_stat_io

On Mon, Feb 03, 2025 at 08:50:15AM +, Bertrand Drouvot wrote: > === 6 > > I'll also do some benchmark on my side. So, I did some tests using: c=1 && psql -c checkpoint -c 'select pg_switch_wal()' && pgbench -n -M prepared -c$c -j$c -f <(echo &

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

OT_IN_PREREQUISITE_STATE), + errmsg("hot standby must be enabled for pre-existing logical replication slots"))); On a primary lowering wal_level < logical, we'd get something like: " FATAL: logical replication slot "logical_slot" exists, but "wal_leve

Re: Avoid orphaned objects dependencies, take 3

Hi, On Thu, Jan 02, 2025 at 08:15:13AM +, Bertrand Drouvot wrote: > rebased (v18 attached). Thanks to all of you that have discussed this patch during the developer meeting at FOSDEM PGDay last week [1]. I'm attaching a new version to address Álvaro's concern

Re: Track the amount of time waiting due to cost_delay

oint() in its own patch makes sense. It's done that way in the attached and allows 0002 to be focus on the main feature. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com >From 0ba4f51ae63e9b8b4d6987d52465f2a284

Re: per backend WAL statistics

Hi, On Wed, Feb 05, 2025 at 11:16:15AM +0900, Michael Paquier wrote: > On Tue, Feb 04, 2025 at 08:49:41AM +0000, Bertrand Drouvot wrote: > > can be extracted from pg_stat_get_backend_io(), so there is no need to > > duplicate > > this information. The same comment could be

Re: Add isolation test template in injection_points for wait/wakeup/detach

ermutation wait1 wakeup2 detach2(wait1) > > Thoughts? I think that makes sense and the patch LGTM. A few tests are already using this technique (including injection_points in inplace.spec). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: per backend WAL statistics

Hi, On Thu, Jan 23, 2025 at 09:57:50AM +, Bertrand Drouvot wrote: > On Thu, Jan 23, 2025 at 05:05:30PM +0900, Michael Paquier wrote: > > As far I got it from a code > > read, prevWalUsage, prevBackendWalUsage and their local trackings in > > pgstat_backend.c and

Re: Failed assertion with jit enabled

Hi, On Wed, Feb 05, 2025 at 10:51:17AM -0500, Tom Lane wrote: > Bertrand Drouvot writes: > > I was doing some tests and managed to trigger a failed assertion with jit > > enabled. > > > The test can be simplified to: > > > postgres=# select count(*) from genera

Re: Show WAL write and fsync stats in pg_stat_io

ok, but I wonder if that's the best appropriate place. I could think of the checkpointer test in 029_stats_restart.pl and the startup/standby one in one related to standby (030_stats_cleanup_replica.pl?). Though that's probably just a matter of taste. s/and the primary WAL some writ

Re: Failed assertion with jit enabled

Hi, On Wed, Feb 05, 2025 at 06:58:54PM +0100, Álvaro Herrera wrote: > On 2025-Feb-05, Bertrand Drouvot wrote: > > > As a default I also always use "maintainer-clean" but it looks like it does > > not > > remove llvmjit.so from the installation director

Move wal_buffers_full to WalUsage (and report it in pgss/explain)

te.internal Looking forward to your feedback, Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com >From 2047ee9b06f42bf79b39b87b69a2840fe402a95f Mon Sep 17 00:00:00 2001 From: Bertrand Drouvot Date: Wed, 5 Feb 2025 1

Re: per backend WAL statistics

Hi, On Thu, Feb 06, 2025 at 10:38:55AM +0900, Michael Paquier wrote: > On Wed, Feb 05, 2025 at 02:28:08PM +0000, Bertrand Drouvot wrote: > > Agree, I'll start a dedicated thread for that. > > Thanks. Done in [1]. [1]: https://www.postgresql.org/message-id/flat/Z6SOha5YFFgv

Fix 035_standby_logical_decoding.pl race conditions

though (as injection points are available since v17). R2. 0001 should probably bump the injection point module to 1.1, but shouldn't have been the case in d28cd3e7b21c? [1]: https://www.postgresql.org/message-id/flat/386386.1737736935%40sss.pgh.pa.us Looking forward to your feedback, Regar

Re: BF member drongo doesn't like 035_standby_logical_decoding.pl

Hi, On Mon, Jan 27, 2025 at 07:13:01AM +, Bertrand Drouvot wrote: > On Fri, Jan 24, 2025 at 02:44:21PM -0500, Andres Freund wrote: > > If we could trigger VACUUM in a transaction on the primary this would be > > easy, but we can't. > > Another idea that I had

Failed assertion with jit enabled

0feb727c86. I did not look at the exact details, just reporting the issue. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: per backend WAL statistics

Hi, On Wed, Feb 05, 2025 at 07:31:13PM +0900, Michael Paquier wrote: > On Wed, Feb 05, 2025 at 10:22:55AM +0000, Bertrand Drouvot wrote: > > So, wal_buffers_full has been introduced after the WalUsage structure was > > there but I don't see any reason in the emails as to

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

oing it differently > in HEAD and back-branches or let's restrict as your v2 patch is doing > and if by any chance users complain about it we can try to fix it in > another way? I'm tempted to vote for the later so that we can maintain the same code across branches. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

Hi, On Wed, Feb 05, 2025 at 10:59:22AM -0800, Masahiko Sawada wrote: > On Tue, Feb 4, 2025 at 11:48 PM Bertrand Drouvot > wrote: > > + if (SlotIsLogical(s) && !EnableHotStandby) > > + ereport(FATAL, > > + (errcode(ERRCODE_

Re: Move wal_buffers_full to WalUsage (and report it in pgss/explain)

Hi, On Thu, Feb 06, 2025 at 10:27:17AM +, Bertrand Drouvot wrote: > === Patch's structure > > The patch series is made of 3 "small" sub-patches: > > 0001: to move wal_buffers_full to WalUsage > 0002: to report wal_buffers_full in pg_stat_statements >

Re: Track the amount of time waiting due to cost_delay

or the progress views. Yeah, I looked at it and that looks as simmple as 0003 attached (as that's the leader that is doing the report in case of parallel workers being used). 0001 and 0002 remain unchanged. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source D

Re: Move wal_buffers_full to WalUsage (and report it in pgss/explain)

sense to > move wal_buffers_full next to wal_records, wal_fpi and wal_bytes? This way, > all WAL-related information would be grouped together. I think I prefer to add it in "append" order. That way, that does not break queries that rely on ordinal numbers. Regards, -- Bertrand

Re: Unneeded volatile qualifier in fmgr.c

G_CATCH block but it doesn't look needed anymore. > > Trivial patch attached. Yeah, makes sense to me. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Show WAL write and fsync stats in pg_stat_io

add a comment mentioning that the "bytes" are expected to differ given the fact that the IO unit is the wal_block_size. But, that said, I don't have a strong opinion on it, just a nice to have IMHO. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: per backend WAL statistics

mind and see if it still makes sense once [1] gets in. [1]: https://www.postgresql.org/message-id/flat/CAN55FZ3AiQ%2BZMxUuXnBpd0Rrh1YhwJ5FudkHg%3DJU0P%2B-W8T4Vg%40mail.gmail.com Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Show WAL write and fsync stats in pg_stat_io

Hi, On Mon, Feb 03, 2025 at 01:07:26PM +0900, Michael Paquier wrote: > On Fri, Jan 31, 2025 at 11:29:31AM +0300, Nazir Bilal Yavuz wrote: > > On Wed, 29 Jan 2025 at 18:16, Bertrand Drouvot > > wrote: > >> I think that's the main reason why ff99918c625 added t

Re: fix deprecation mention for age() and mxid_age()

t; now. Thanks for the poke. D'oh I missed it too! > Thanks for the poke. +1 Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Make use of pg_memory_is_all_zeros() in more places

Hi, On Wed, Dec 11, 2024 at 03:03:34PM +0900, Michael Paquier wrote: > On Tue, Dec 10, 2024 at 02:18:33PM +0000, Bertrand Drouvot wrote: > > While searching for memcmp() calls in "*stat*.c" files (due to [1]), it > > appeared > > that we could $SUBJECT. Please

Re: Fix comments related to pending statistics

Hi, On Wed, Dec 11, 2024 at 02:56:08PM +0900, Michael Paquier wrote: > On Tue, Dec 10, 2024 at 02:16:14PM +0000, Bertrand Drouvot wrote: > > > > 2. One linked to PgStat_FunctionCounts pending stats, mentioning the use of > > memcmp() against zeroes to detect whether there

Re: Track the amount of time waiting due to cost_delay

Hi, On Tue, Dec 10, 2024 at 11:55:41AM -0600, Nathan Bossart wrote: > On Mon, Dec 09, 2024 at 04:41:03PM +0000, Bertrand Drouvot wrote: > > + time_delayed bigint > > I think it's also worth considering names like total_delay and > cumulative_delay. That's f

Fix comments related to pending statistics

/ZlGYokUIlERemvpB%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com >From a7a026fa0f183bf4d66d85ea05463b69422d20a8 Mon Sep 17 00:00:00 2001 From: Bertrand Drouvot Date: Tue, 10 Dec 2

Make use of pg_memory_is_all_zeros() in more places

t there is no others that could be replaced with pg_memory_is_all_zeros(). [1]: https://www.postgresql.org/message-id/flat/Z1hNLvcPgVLPxCoc%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://

Re: shared-memory based stats collector - v70

Hi, On Tue, Dec 10, 2024 at 09:54:36AM +0900, Michael Paquier wrote: > On Mon, Dec 09, 2024 at 08:03:54AM +0000, Bertrand Drouvot wrote: > > Right. OTOH I think that could help the tap test added in da99fedf8c to not > > rely on assert enabled build (the tap test could "s

Re: Track the amount of time waiting due to cost_delay

Yeah, fair enough. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com >From 35e6075791000498ed05a7eb62fd34616957c4ce Mon Sep 17 00:00:00 2001 From: Bertrand Drouvot Date: Mon, 24 Jun 2024 08:43:26 + Subject:

Re: Fix comments related to pending statistics

Hi, On Thu, Dec 12, 2024 at 09:20:15AM +0900, Michael Paquier wrote: > On Wed, Dec 11, 2024 at 07:32:38AM +0000, Bertrand Drouvot wrote: > > On Wed, Dec 11, 2024 at 02:56:08PM +0900, Michael Paquier wrote: > >> Your suggestion does not look completely right to me. The

Re: per backend I/O statistics

Hi, On Thu, Dec 12, 2024 at 01:52:03PM +0900, Michael Paquier wrote: > On Mon, Nov 25, 2024 at 03:47:59PM +0000, Bertrand Drouvot wrote: > +view. The function does not return I/O statistics for the > checkpointer, > +the background writer, the startup process and th

Re: per backend I/O statistics

Hi, On Mon, Dec 16, 2024 at 05:07:52PM +0900, Michael Paquier wrote: > On Fri, Dec 13, 2024 at 09:20:13AM +0000, Bertrand Drouvot wrote: > > Not feeling so sure about the value brought by the backend_type > returned in pg_stat_get_backend_io(), but well.. It's not necessar

Re: Track the amount of time waiting due to cost_delay

gly. === 5 + if (INSTR_TIME_GET_NANOSEC(time_since_last_report) >= + PARALLEL_VACUUM_WORKER_DELAY_REPORT_INTERVAL_NS) + { + pgstat_progress_parallel_incr_param(PROGRESS_VACUUM_DELAY_TIME, Added a comment to mention that PROGRESS_ANALYZE_DELAY_TIME is out of interest here. v14 also fixes the typo mentio

Re: Track the amount of time waiting due to cost_delay

Hi, On Mon, Dec 16, 2024 at 04:02:56PM -0600, Nathan Bossart wrote: > On Mon, Dec 16, 2024 at 10:11:23AM +0000, Bertrand Drouvot wrote: > > +#define PARALLEL_VACUUM_WORKER_DELAY_REPORT_INTERVAL_NS (NS_PER_S) > > > > Did not changed in v14, but "PARALLEL_VACUUM_REPORT_IN

Re: per backend I/O statistics

Hi, On Tue, Dec 17, 2024 at 03:26:02PM +0900, Michael Paquier wrote: > On Mon, Dec 16, 2024 at 03:42:04PM +0000, Bertrand Drouvot wrote: > >> Perhaps there's an argument for an entirely separate > >> callback that would run before pgstat is plugged off, like a

Re: per backend I/O statistics

Hi, On Tue, Dec 17, 2024 at 06:13:44PM +0900, Michael Paquier wrote: > On Tue, Dec 17, 2024 at 08:13:59AM +0000, Bertrand Drouvot wrote: > > Having said that, v9-0002 looks good to me (except the > > pgstat_fetch_proc_stat_io > > renaming). > > This routine retu

Re: Removing the pgstat_flush_io() call from the walwriter

Hi, On Wed, Dec 18, 2024 at 10:35:45AM -0500, Andres Freund wrote: > Hi, > > On 2024-12-18 15:14:07 +, Bertrand Drouvot wrote: > > While working on [1], it has been noticed that pgstat_flush_io() is called > > for > > the walwriter. Indeed, it's coming from

Removing the pgstat_flush_io() call from the walwriter

https://www.postgresql.org/message-id/Z1rs/j5JMdTbUIJJ%40ip-10-97-1-34.eu-west-3.compute.internal [2]: https://www.postgresql.org/message-id/flat/20200124195226.lth52iydq2n2uilq%40alap3.anarazel.de Looking forward to your feedback, Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Data

Re: per backend I/O statistics

Hi, On Wed, Dec 18, 2024 at 01:57:53PM +0900, Michael Paquier wrote: > On Tue, Dec 17, 2024 at 09:35:37AM +0000, Bertrand Drouvot wrote: > > Agree, we may need to add parameters to it but we'll see when the time > > comes. > > Another thing that'

Re: per backend I/O statistics

On Wed, Dec 18, 2024 at 08:11:55AM +, Bertrand Drouvot wrote: > Yeah, I also had something like this in mind (see R2 in [1]). So, +1 for it. [1] being: https://www.postgresql.org/message-id/Zy4bmvgHqGjcK1pI%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot Postgre

Re: per backend I/O statistics

and done. Thanks! I think I'll start a dedicated thread to discuss the stats_fetch_consistency/'snapshot' point (will be easier to follow than resuming the discussion in this thread). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Parametrization minimum password lenght

_0001.txt attached). Also, it seems to me that INT_MAX is too large (as mentioned in [1]), but that's probably a nit. [1]: https://www.postgresql.org/message-id/Zzzmw4IAvrypmFO4%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open

Re: Removing the pgstat_flush_io() call from the walwriter

instead: I'll try to have a look at adding IO stats for walwriter. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

<    1   2   3   4   5   6   7   8   9   >