Re: NOT ENFORCED constraint feature

On 2025-Feb-04, Peter Eisentraut wrote: > On 03.02.25 08:50, Alvaro Herrera wrote: > > On 2025-Feb-03, Ashutosh Bapat wrote: > > > > > VALID, NOT ENFORCED changed to VALID, ENFORCED - data validation > > > required, constraint is enforced > > There's no such thing as a VALID NOT ENFORCED constrai

Re: Show WAL write and fsync stats in pg_stat_io

Hi, On Tue, 4 Feb 2025 at 10:55, Michael Paquier wrote: > > On Mon, Feb 03, 2025 at 02:34:29PM +0300, Nazir Bilal Yavuz wrote: > > On Mon, 3 Feb 2025 at 11:50, Bertrand Drouvot < bertranddrouvot...@gmail.com> wrote: > >> === 1 > >> > >> + pgstat_count_io_op_time(IOOBJECT_WAL, IOCONTEXT_INIT

Re: Convert sepgsql tests to TAP

On 28.01.25 14:34, Dagfinn Ilmari Mannsåker wrote: Peter Eisentraut writes: On 27.08.24 10:12, Peter Eisentraut wrote: Here is a new patch version. I simplified the uses of sed and awk inside the Perl script.  I also fixed "make installcheck".  I noticed that meson installs sepgsql.sql into th

Re: Should heapam_estimate_rel_size consider fillfactor?

On 1/29/25 19:56, Heikki Linnakangas wrote: > On 03/07/2023 20:54, Tomas Vondra wrote: >> Pushed, using the formula with two divisions (as in the original patch). > > I ran into an issue with this, in the case of a small fillfactor and > wide tuple width: > > On v16: > > postgres=# create tab

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

On Sun, Feb 2, 2025 at 8:11 PM Amit Kapila wrote: > > On Fri, Jan 24, 2025 at 4:05 AM Masahiko Sawada wrote: > > > > When a standby replays a XLOG_PARAMETER_CHANGE record that lowers > > wal_level from logical, we invalidate all logical slots only when the > > standby is in hot standby mode: > >

Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning

On Fri, Jan 31, 2025 at 5:46 PM Alvaro Herrera wrote: > > On 2025-Jan-31, Alvaro Herrera wrote: > > > So I tried to rerun Ashutosh's benchmark (of course, on a build > > with no C assertions, otherwise the numbers are meaningless). First, > > the patches still apply to current master. > > (BTW I

RE: Introduce XID age and inactive timeout based replication slot invalidation

Dear Nisha, Thanks for updating the patch! Here are my comments. 01. ``` +# Test for replication slots invalidation ``` Since the file tests only timeout invalidations, the comment seems too general. 02. ``` + # Check that an invalidated slot cannot be acquired + my ($result, $stdou

Re: Restrict publishing of partitioned table with a foreign table as partition

On Fri, 31 Jan 2025 at 10:38, Sergey Tatarintsev wrote: > > Ok, but maybe it will be correct to raise an WARNING (or at least LOG) > that some tables was skipped during publication. What do you think? > > And I think we need check tables which was really published in case of > 'FOR ALL TABLES' and

Re: Vacuum statistics

On 04.02.2025 18:22, Alena Rybakina wrote:   Also, should pgstat_track_vacuum_statistics also affect per database statistics? According to my original idea, I thought that we could collect extended statistics on relationships depending on whether the hook is enabled, and always on databases

Re: Conflict detection for update_deleted in logical replication

On Fri, Jan 31, 2025 at 9:07 PM Amit Kapila wrote: > > On Sat, Feb 1, 2025 at 2:54 AM Masahiko Sawada wrote: > > > > On Thu, Jan 30, 2025 at 10:39 PM Amit Kapila > > wrote: > > > > > > On Fri, Jan 31, 2025 at 4:10 AM Masahiko Sawada > > > wrote: > > > > > > > > I have one question about the 0

Re: Adding facility for injection points (or probe points?) for more advanced tests

On Mon, Feb 03, 2025 at 09:30:33PM -0800, Jeff Davis wrote: > That sounds useful, but not necessarily required, for the HashAgg tests > I just posted[1]. I thought so based on what you have posted on the other thread, as you are relying on a three-step sequence to happen in a specific order, multi

Re: new commitfest transition guidance

Tomas Vondra writes: > I didn't have an opinion on this during the developer meeting, but after > thinking about it I think having an up to date status for the patch is a > reasonable requirement. > It wouldn't need to be very long / detailed, it could even point to an > earlier message in the th

Re: RFC: Packing the buffer lookup table

Hi, On 2025-02-04 19:58:36 +0100, Matthias van de Meent wrote: > On Thu, 30 Jan 2025 at 08:48, Matthias van de Meent > wrote: > > > > Together that results in the following prototype patchset. > > Here's an alternative patch, which replaces dynahash in the buffer > lookup table with an open-code

Re: Make COPY format extendable: Extract COPY TO format implementations

On Tue, Feb 4, 2025 at 2:46 AM Vladlen Popolitov wrote: > > Sutou Kouhei писал(а) 2025-02-04 13:29: > Hi > > Hi, > > > > In > > "Re: Make COPY format extendable: Extract COPY TO format > > implementations" on Mon, 03 Feb 2025 13:38:04 +0700, > > Vladlen Popolitov wrote: > > > >> I would like

Re: new commitfest transition guidance

On Wed, 2025-02-05 at 01:38 +0100, Tomas Vondra wrote: > How did you propose to submit/track the status? Would it be sent to > the > mailing list, or would it be entered into the CF app while adding the > patch to the next commitfest? (The latter wouldn't have the problem > of > cluttering the mail

Re: [PATCH] Optionally record Plan IDs to track plan changes for a query

>> I can work on this if you agree. > I'd welcome an extra patch to rework a bit the format of the comments > for the Plan nodes, to ease the addition of pg_node_attr(), making any > proposed patches more readable. I'll take care of this also. Regards, Sami

Re: [PATCH] Optionally record Plan IDs to track plan changes for a query

Hi Andrei, On Fri, Jan 24, 2025 at 1:23 AM Andrei Lepikhov wrote: > I may not be close to the task monitoring area, but I utilise queryId > and other tools to differ plan nodes inside extensions. Initially, like > queryId serves as a class identifier for queries, plan_id identifies a > class of

Re: per backend WAL statistics

On Tue, Feb 04, 2025 at 08:49:41AM +, Bertrand Drouvot wrote: > I think that: > > wal_write (and wal_write_time) > wal_sync (and wal_sync_time) Right. We are not able to get this data from XLogWrite() and issue_xlog_fsync(), so there is no need to duplicate that anymore in your patch. > ca

RE: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.

Dear Shlok, > 4. Instead of warning we should throw an error here: > + if (PQresultStatus(res) != PGRES_TUPLES_OK) > + { > + pg_log_warning("could not obtain publication information: %s", > + PQresultErrorMessage(res)); > + I don't think so. ERROR ev

Re: Make COPY format extendable: Extract COPY TO format implementations

Masahiko Sawada писал(а) 2025-02-05 08:32: On Tue, Feb 4, 2025 at 2:46 AM Vladlen Popolitov >> Standard PostgreSQL realisation for new methods to use USING >> keyword. Every >> new method could have own options (FORMAT is option of internal 'copy >> from/to' >> methods), > > Ah, I didn't thi

Re: [PATCH] Optionally record Plan IDs to track plan changes for a query

On Tue, Feb 04, 2025 at 05:14:48PM -0600, Sami Imseih wrote: > Here are my high-level thoughts on this: > 1. rename queryjumblefuncs.c to jumblefuncs.c If these APIs are used for somethings else than Query structure, yes, the renaming makes sense. > 2. move the query jumbling related code to pars

Re: Avoid updating inactive_since for invalid replication slots

Hi Nisha, Some review comments for v2-0001. == doc/src/sgml/system-views.sgml 1. The time when the slot became inactive. NULL if the slot is currently being streamed. If the slot becomes invalid, this value will never be updated. Note that for slots on the standby that are being synced from

Re: add missing PQfinish() calls to vacuumdb

On Tue, Feb 04, 2025 at 10:30:58AM -0600, Nathan Bossart wrote: > I noticed that vacuum_one_database() doesn't call PQfinish() before > pg_fatal() in a few of the server version checks. I seem to have > unintentionally established this precedent in commit 00d1e88. Michael > claimed to have fixed

Re: new commitfest transition guidance

On 2/4/25 21:11, Jeff Davis wrote: > On Mon, 2025-02-03 at 12:22 +0100, Peter Eisentraut wrote: >> My interpretation of this is that patches should be moved forward by >> either an author, possibly a reviewer, possibly a committer signed up >> for the patch, or maybe even a colleague of an aut

Re: RFC: Packing the buffer lookup table

Hi, On 2025-01-30 08:48:56 +0100, Matthias van de Meent wrote: > Some time ago I noticed that every buffer table entry is quite large at 40 > bytes (+8): 16 bytes of HASHELEMENT header (of which the last 4 bytes are > padding), 20 bytes of BufferTag, and 4 bytes for the offset into the shared > bu

Re: new commitfest transition guidance

On Tue, 2025-02-04 at 20:10 -0500, Tom Lane wrote: > I am very strong -1 on the idea of requiring a status email before a > entry can be pushed to the next CF. OK, I retract the idea. Regards, Jeff Davis

Re: Separate GUC for replication origins

On Fri, Jan 24, 2025, at 8:12 PM, Masahiko Sawada wrote: > Here are some comments on v2 patch: > > --- > /* Report this after the initial starting message for consistency. */ > - if (max_replication_slots == 0) > + if (max_replication_origins == 0) > ereport(ERR

Re: Sample rate added to pg_stat_statements

> To summarize the results of all benchmarks, I compiled them into a table: Thanks for compiling the benchmark data above. The main benefit of this patch will be to give the user a toggle if they are observing high spinlock contention due to pg_stat_statements which will likely occur on larger mac

Re: Restrict publishing of partitioned table with a foreign table as partition

On 2025-Feb-04, vignesh C wrote: > We should throw an error for partitioned tables that contain foreign > partitions, as this would include the data from these foreign tables > during the initial sync, while incremental changes would not be > replicated. Hmm, I would support the idea of allowing

Re: should we have a fast-path planning for OLTP starjoins?

Tomas Vondra writes: > On 2/4/25 20:43, Jeff Davis wrote: >> If you base it on the join conditions rather than the size of the >> table, then detection of the star join would be based purely on the >> query structure (not stats), which would be nice for predictability. > Right, there may be other

Re: should we have a fast-path planning for OLTP starjoins?

On Tue, 2025-02-04 at 15:00 +0100, Tomas Vondra wrote: > This is a surprisingly common query pattern in OLTP applications, > thanks > to normalization. +1. Creating a small lookup table should be encouraged rather than penalized. Your test data includes a fact table with 10k rows and no index on

Re: Support for NO INHERIT to INHERIT state change with named NOT NULL constraints

On 2025-Jan-13, Suraj Kharage wrote: > Please find attached revised version of patch which added the INHERIT to NO > INHERIT state change for not null constraint. Thanks! I find the doc changes a little odd. First, you seem to have added a [INHERIT/NO INHERIT] flag in the wrong place (line 112)

Re: Enhance 'pg_createsubscriber' to retrieve databases automatically when no database is provided.

On Tue, Feb 4, 2025 at 3:49 PM Ashutosh Bapat wrote: > > Hi Shubham, > > On Tue, Feb 4, 2025 at 2:10 PM Shubham Khanna > wrote: > > > > > > > > > > It could be a bit tricky to find that for users but they can devise a > > > query to get the names and numbers of databases matching the given > > >

Re: Eagerly scan all-visible pages to amortize aggressive vacuum

On Tue, Feb 4, 2025 at 12:44 PM Melanie Plageman wrote: > On Mon, Feb 3, 2025 at 9:09 PM Andres Freund wrote: > > > > On 2025-01-29 14:12:52 -0500, Melanie Plageman wrote: > > > From 71f32189aad510b73d221fb0478ffd916e5e5dde Mon Sep 17 00:00:00 2001 > > > From: Melanie Plageman > > > > @@ -1064,7

Re: Better title output for psql \dt \di etc. commands

=?utf-8?Q?=C3=81lvaro?= Herrera writes: > On 2025-Feb-04, Tom Lane wrote: >> =?utf-8?Q?=C3=81lvaro?= Herrera writes: >>> At this point I would just add a "translator:" comment that explains >>> that the ??? bit is for unexpected cases and can be translated in the >>> same way. >> Hmm, do we have

Re: should we have a fast-path planning for OLTP starjoins?

On Tue, Feb 4, 2025 at 3:42 PM Tomas Vondra wrote: > On 2/4/25 21:23, Tom Lane wrote: > > Tomas Vondra writes: > >> On 2/4/25 20:43, Jeff Davis wrote: > >>> If you base it on the join conditions rather than the size of the > >>> table, then detection of the star join would be based purely on the

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Tue, 4 Feb 2025 at 19:56, Nisha Moond wrote: > > Here is v69 patch set addressing above and Kuroda-san's comments in [1]. Few minor suggestions: 1) In the slot invalidation reporting below: + case RS_INVAL_IDLE_TIMEOUT: + Assert(inactive_since > 0); + +

Re: Make COPY format extendable: Extract COPY TO format implementations

On Sat, Feb 01, 2025 at 07:12:01PM +0900, Sutou Kouhei wrote: > For the propose, copyapi.h should not include > copy{to,from}_internal.h. If we do it, copyto.c includes > CopyFromState and copyfrom*.c include CopyToState. > > What do you think about the following change? Note that > extensions mus

Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.

On Wed, 5 Feb 2025 at 07:49, Hayato Kuroda (Fujitsu) wrote: > > Dear Shlok, > > > 4. Instead of warning we should throw an error here: > > + if (PQresultStatus(res) != PGRES_TUPLES_OK) > > + { > > + pg_log_warning("could not obtain publication information: %s", > > +

Re: Conflict detection for update_deleted in logical replication

On Sat, Feb 1, 2025 at 10:37 AM Amit Kapila wrote: > > On Sat, Feb 1, 2025 at 2:54 AM Masahiko Sawada wrote: > > > > On Thu, Jan 30, 2025 at 10:39 PM Amit Kapila > > wrote: > > > > > > On Fri, Jan 31, 2025 at 4:10 AM Masahiko Sawada > > > wrote: > > > > > > > > I have one question about the 0

Re: Increased work_mem for "logical replication tablesync worker" only?

On Wed, Feb 5, 2025 at 9:50 AM Dmitry Koterov wrote: > > Only one index, the primary key. > > ChatGPT tells that temp files may be used, when bytea columns (or heavily > toasted ones) are utilized, but it can’t explain, why. To me, it’s hard to > believe that on the destination, the COPY stream

Re: Make COPY format extendable: Extract COPY TO format implementations

On Tue, Feb 4, 2025 at 6:19 PM Vladlen Popolitov wrote: > > Masahiko Sawada писал(а) 2025-02-05 08:32: > > On Tue, Feb 4, 2025 at 2:46 AM Vladlen Popolitov > > >> >> Standard PostgreSQL realisation for new methods to use USING > >> >> keyword. Every > >> >> new method could have own options (FOR

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

On Thu, Oct 31, 2024 at 08:47:04AM +0900, Michael Paquier wrote: > Thanks for the review. Applied that, then. I was looking at src/test/isolation/README, and based on what is described for parenthesized markers (which I didn't know about so we learn a new thing every day), it is possible to force

Re: Make COPY format extendable: Extract COPY TO format implementations

On Tue, Feb 4, 2025 at 9:10 PM Michael Paquier wrote: > > On Sat, Feb 01, 2025 at 07:12:01PM +0900, Sutou Kouhei wrote: > > For the propose, copyapi.h should not include > > copy{to,from}_internal.h. If we do it, copyto.c includes > > CopyFromState and copyfrom*.c include CopyToState. > > > > What

Re: Show WAL write and fsync stats in pg_stat_io

On Tue, Feb 04, 2025 at 05:40:06PM +0300, Nazir Bilal Yavuz wrote: > Hi, > > On Tue, 4 Feb 2025 at 17:29, Nazir Bilal Yavuz wrote: > > > > Thanks! My benchmark results are the same [1]. I could not see the > > noticable difference between master and patched version. I run the > > benchmark a coup

Re: Separate GUC for replication origins

On Wed, Feb 5, 2025 at 8:17 AM Euler Taveira wrote: > > Under reflection, an accurate name is max_replication_origin_session_setup. A > counter argument is that it is a long name (top-5 length). > > postgres=# select n, length(n) from (values('max_replication_origins'), > ('max_tracked_replication

Re: Test to dump and restore objects left behind by regression

On Mon, Jan 27, 2025 at 03:04:55PM +0530, Ashutosh Bapat wrote: > PFA patch with rebased on the latest HEAD and conflicts fixed. Thanks for the new patch. Hmm. I was reading through the patch and there is something that clearly stands out IMO: the new compare_dumps(). It is in Utils.pm, and it

Re: Conflict detection for update_deleted in logical replication

On Wed, Feb 5, 2025 at 6:00 AM Masahiko Sawada wrote: > > On Fri, Jan 31, 2025 at 9:07 PM Amit Kapila wrote: > > > > > > > > I was not sure of the point of > > > making the max_conflict_retention_duration a per-subscription > > > parameter. > > > > > > > The idea is to keep it at the same level a

Re: EDB Installer initcluster script changes - review requested

Hi Manika, The final patch looks fine to me. Hopefully, it'll be included in the upcoming minor releases. It'll help a lot of users who use installers with the locale containing non-ascii characters. On Wed, Jan 29, 2025 at 8:34 PM Manika Singhal < manika.sing...@enterprisedb.com> wrote: > > On

Re: Showing applied extended statistics in explain Part 2

Hi All, Thank you everyone for your cooperation with comments on the patch and solution ideas. I am sorting through your review comments now. And after rebasing the patch, I plan to send a patch that addresses the comments as much as possible to -hackers by Feb 21 at the latest. Therefore, the st

Recheck if ANALYZE is needed after VACUUM finishes by autovacuum

Hi, I would like to propose adding logic to recheck whether an ANALYZE is necessary at the end of VACUUM. I believe this could be a viable idea to mitigate a problem encountered by my customer. The customer’s issue occurred as follows: 1. Every 5 minutes, a large amount of data (2 million recor

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

On Wed, Feb 5, 2025 at 2:06 AM Masahiko Sawada wrote: > > I've attached the updated patch. The fix needs to be back-patched to > v16 where logical decoding on standby was introduced. > Isn't it better to give the new ERROR near the below code? RestoreSlotFromDisk() { ... if (cp.slotdata.database

Re: Vacuum statistics

On Tue, Feb 4, 2025 at 5:22 PM Alena Rybakina wrote: > > Hi! Thank you for your review! > > On 02.02.2025 23:43, Alexander Korotkov wrote: > > On Mon, Jan 13, 2025 at 3:26 PM Alena Rybakina > > wrote: > >> I noticed that the cfbot is bad, the reason seems to be related to the > >> lack of a para

Re: Restrict publishing of partitioned table with a foreign table as partition

On Tue, 4 Feb 2025 at 21:21, Álvaro Herrera wrote: > > On 2025-Feb-04, vignesh C wrote: > > > We should throw an error for partitioned tables that contain foreign > > partitions, as this would include the data from these foreign tables > > during the initial sync, while incremental changes would n

Re: SQL:2023 JSON simplified accessor support

Hi hackers, On Tue, Nov 26, 2024 at 3:12 AM Peter Eisentraut wrote: > On 21.11.24 23:46, Andrew Dunstan wrote: > >> Questions: > >> > >> 1. Since Nikita’s patches did not address the JSON data type, and JSON > >> currently does not support subscripting, should we limit the initial > >> feature s

Re: Make COPY format extendable: Extract COPY TO format implementations

Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Tue, 04 Feb 2025 17:46:10 +0700, Vladlen Popolitov wrote: > I think, in case of USING PostgreSQL kernel will call corresponding > handler, > and it looks secure - the same as for table and index methods > h

Re: Introduce XID age and inactive timeout based replication slot invalidation

Hi Nisha, Some review comments for the patch v69-0002. == src/backend/replication/slot.c 1. +#ifdef USE_INJECTION_POINTS + + /* + * To test idle timeout slot invalidation, if the + * slot-time-out-inval injection point is attached, + * immediately invalidate the slot. + */ + if (IS_INJECTION

Re: Make COPY format extendable: Extract COPY TO format implementations

Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Tue, 4 Feb 2025 17:32:07 -0800, Masahiko Sawada wrote: > BTW we need to check if the return value type of the handler function > is copy_handler. Oh, can we do it without calling a function? It seems that

Re: Conflict detection for update_deleted in logical replication

On Thu, Jan 23, 2025 at 5:17 PM Zhijie Hou (Fujitsu) wrote: > I was reviewing v26 patch set and have some comments so far I reviewed 0001 so most of the comments/question are from this patch. comments on v26-0001 1. + next_full_xid = ReadNextFullTransactionId(); + epoch = EpochFromFullTransactio

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

Hi, On Wed, Feb 05, 2025 at 12:08:26PM +0530, Amit Kapila wrote: > On Wed, Feb 5, 2025 at 2:06 AM Masahiko Sawada wrote: > > > > I've attached the updated patch. The fix needs to be back-patched to > > v16 where logical decoding on standby was introduced. Nice catch and thanks for the patch! I a

Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning

On Fri, Jan 31, 2025 at 5:41 PM Alvaro Herrera wrote: > > On 2024-Nov-25, Ashutosh Bapat wrote: > > > Hmm, I am doing something similar to what you are doing. Here are my > > scripts. setup.sql - creates partitioned table, and functions, tables > > used to run the benchmark benchmark.sh - creates

Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum

03.02.2025 19:49, Heikki Linnakangas пишет: > On 03/02/2025 13:05, Yura Sokolov wrote: >> Investigating some performance issues of a client, our engineers found >> msgnumLock to be contended. >> >> Looking closer it is obvious it is not needed at all: it used only as >> memory barrier. It is even s

Re: Make COPY format extendable: Extract COPY TO format implementations

Sutou Kouhei писал(а) 2025-02-04 13:29: Hi Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Mon, 03 Feb 2025 13:38:04 +0700, Vladlen Popolitov wrote: I would like to inform about the security breach in your design of COPY TO/FROM. Thanks! I didn't n

Re: NOT ENFORCED constraint feature

On 03.02.25 06:19, Ashutosh Bapat wrote: Here's how I see the state conversions happening. NOT VALID, NOT ENFORCED changed to NOT_VALID, ENFORCED - no data validation required, constraint is enforced on the new tuples/changes NOT VALID, ENFORCED changed to NOT VALID, NOT ENFORCED - no data valid

Re: NOT ENFORCED constraint feature

On 03.02.25 13:19, Alvaro Herrera wrote: On 2025-Feb-03, Ashutosh Bapat wrote: ``` If the constraint is NOT ENFORCED, the database system will not check the constraint. It is then up to the application code to ensure that the constraints are satisfied. The database

Re: NOT ENFORCED constraint feature

On 03.02.25 08:50, Alvaro Herrera wrote: On 2025-Feb-03, Ashutosh Bapat wrote: VALID, NOT ENFORCED changed to VALID, ENFORCED - data validation required, constraint is enforced There's no such thing as a VALID NOT ENFORCED constraint. It just cannot exist. The way I interpret this is that t

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Tue, Feb 4, 2025 at 4:42 PM vignesh C wrote: > > On Tue, 4 Feb 2025 at 15:58, Nisha Moond wrote: > > > > Here are the v68 patches, incorporating above as well as comments from [1]. > > > Few comments: > 1) Let's call TimestampDifferenceExceedsSeconds only if > idle_replication_slot_timeout_min

Re: Better title output for psql \dt \di etc. commands

On 2025-Feb-03, Tom Lane wrote: > One problem with it is that while we can leave "List of ???" out > of the set of translatable strings easily, we can't currently > do that for the argument of pg_log_error because it's automatically > a gettext trigger. I'd rather not burden translators with figu

Re: Show WAL write and fsync stats in pg_stat_io

Hi, On Tue, 4 Feb 2025 at 17:29, Nazir Bilal Yavuz wrote: > > Thanks! My benchmark results are the same [1]. I could not see the > noticable difference between master and patched version. I run the > benchmark a couple of times, sometimes the patched version, sometimes the > master version is bet

Re: Better title output for psql \dt \di etc. commands

=?utf-8?Q?=C3=81lvaro?= Herrera writes: > At this point I would just add a "translator:" comment that explains > that the ??? bit is for unexpected cases and can be translated in the > same way. Hmm, do we have a standard policy or comment wording about that? I looked for "translator: ... unexpec

Re: Commitfest app release on Feb 17 with many improvements

On 2025-Jan-31, Jelte Fennema-Nio wrote: > 3. Showing total additions/deletions of the most recent patchset on > patch and commitfest pages > 4. Showing additions/deletions of the first patch of the most recent > patchset on the patch page > 5. Showing the version and number of patches of the most

add missing PQfinish() calls to vacuumdb

I noticed that vacuum_one_database() doesn't call PQfinish() before pg_fatal() in a few of the server version checks. I seem to have unintentionally established this precedent in commit 00d1e88. Michael claimed to have fixed it before committing [0], but that seems to have been missed, too. I do

Re: Add a warning message when using unencrypted passwords

On 09/12/2024 15:58, Guillaume Lelarge wrote: Hi, Le lun. 9 déc. 2024 à 14:40, Daniel Gustafsson > a écrit : > On 9 Dec 2024, at 14:26, Greg Sabino Mullane mailto:htamf...@gmail.com>> wrote: > -1 to throwing an ERROR - that's not really an error, and not our

RE: SIGSEGV, FPE fix in pg_controldata

Thank you for your answer, Alexander! I like your patch and it looks similar to my first version of it before I came up to the possible segment size problem. >Also, I don't think we should change segment size to uint32 as it's already defined as int in awfully a lot of places I agree that changi

Re: Doc fix of aggressive vacuum threshold for multixact members storage

A few paragraphs up the docs, there is this mention: ". There is a separate storage area which holds the list of members in each multixact, which also uses a 32-bit counter and which must also be managed." Maybe we can add more to this paragraph, such as: "also be managed. This member can grow

Re: add missing PQfinish() calls to vacuumdb

> On 4 Feb 2025, at 17:30, Nathan Bossart wrote: > > I noticed that vacuum_one_database() doesn't call PQfinish() before > pg_fatal() in a few of the server version checks. I seem to have > unintentionally established this precedent in commit 00d1e88. Michael > claimed to have fixed it before c

Re: [PATCH] SVE popcount support

> The meson configure check seems to fail on my machine > This test looks quite different than the autoconf one. Why is that? I would expect them to be the same. And I think ideally the test would check that all the intrinsics functions we need are available. Fixed, both meson and autoconf have

Re: POC: track vacuum/analyze cumulative time per relation

Hi! On 28.01.2025 03:59, Michael Paquier wrote: On Mon, Jan 27, 2025 at 11:22:16AM -0600, Sami Imseih wrote: I have put my hands on this patch, and at the end I think that we should just do the attached, which is simpler and addresses your use-case. Note also that the end time is acquired whil

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 about calling getObjectDescriptio

Re: SQL/JSON json_table plan clause

Hi Amit! No, JSON_TABLE is ok. I've meant that in the previous approach to PLAN clause implementation there were some wrong tests. On Tue, Feb 4, 2025 at 6:05 AM Amit Langote wrote: > Hi Nikita, > > On Wed, Dec 18, 2024 at 12:11 AM Nikita Malakhov > wrote: > > > > Hi hackers! > > > > This thre

Re: Using Expanded Objects other than Arrays from plpgsql

Hi, Tom! On Mon, 3 Feb 2025 at 21:53, Tom Lane wrote: > > Pavel Borisov writes: > > Minor notes on the patches: > > > If dump_* functions could use the newly added walker, the code would > > look better. I suppose the main complication is that dump_* functions > > contain a lot of per-statement

Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.

On Wed, 29 Jan 2025 at 15:14, Shubham Khanna wrote: > > On Wed, Jan 29, 2025 at 10:42 AM Hayato Kuroda (Fujitsu) > wrote: > > > > Dear Shubham, > > > > > I propose adding the --clean-publisher-objects option to the > > > pg_createsubscriber utility. As discussed in [1], this feature ensures > > >

Re: Enhance 'pg_createsubscriber' to retrieve databases automatically when no database is provided.

On Thu, Jan 30, 2025 at 12:08 PM Amit Kapila wrote: > > On Thu, Jan 30, 2025 at 6:21 AM Peter Smith wrote: > > > > On Wed, Jan 29, 2025 at 4:44 PM Amit Kapila wrote: > > > > > > On Tue, Jan 28, 2025 at 12:01 PM Ashutosh Bapat > > > wrote: > > > > > > > > If we want to stick to --database= suppo

Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch)

On Sun, Feb 2, 2025 at 3:11 PM jian he wrote: > hi. > the following reviews based on > v10-0001-Introduce-the-ability-to-set-index-visibility-us.patch. > > Thank you for the amazing review!! > in src/test/regress/sql/create_index.sql > seems there are no sql tests for "create index ... invisibl

Restrict copying of invalidated replication slots

Hi, Currently, we can copy an invalidated slot using the function 'pg_copy_logical_replication_slot'. As per the suggestion in the thread [1], we should prohibit copying of such slots. I have created a patch to address the issue. [1]: https://www.postgresql.org/message-id/CAA4eK1Kw%3DvZ2FZ4Ddrm

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Tue, 4 Feb 2025 at 10:45, Amit Kapila wrote: > > On Mon, Feb 3, 2025 at 6:35 PM Shlok Kyal wrote: > > > > I reviewed the v66 patch. I have few comments: > > > > 1. I also feel the default value should be set to '0' as suggested by > > Vignesh in 1st point of [1]. > > > > +1. This will ensure t

Re: Index AM API cleanup

On 03.02.25 12:08, Peter Eisentraut wrote: Yeah, actually this turned out to be unnecessary, because you can easily obtain the AM OID from the passed-in opclass ID.  So I have fixed it that way.  I have committed this whole patch set now with the mentioned adjustments.  I'll post a rebased vers

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

On Mon, Feb 3, 2025 at 3:40 AM Hayato Kuroda (Fujitsu) wrote: > > Dear Sawada-san, > > > I'm concerned that users could be confused if two different names > > refer to substantially the same thing. > > > > Having said that, I guess that we need to drastically change the > > messages. For example,

Re: Track the amount of time waiting due to cost_delay

Hi, On Mon, Feb 03, 2025 at 02:05:51PM -0600, Nathan Bossart wrote: > Barring objections, I am planning to commit this one soon. I might move > the addition of analyze_delay_point() to its own patch, but otherwise I > think it looks good to go. Yeah, I think that having analyze_delay_point() in

Re: Restrict publishing of partitioned table with a foreign table as partition

On Thu, 30 Jan 2025 at 17:32, Shlok Kyal wrote: > > @@ -1428,6 +1427,12 @@ check_foreign_tables_in_schema(Oid schemaid) > errdetail("foreign table \"%s\" is a partition of > partitioned table \"%s\"", >get_rel_name(foreign_tbl_relid), > parent_

Re: Add a warning message when using unencrypted passwords

Guillaume Lelarge writes: > v2 is attached. This seems pretty much entirely useless to me. The password has already been leaked to the log (*and* the network, if session is unencrypted), so what's the point of a warning? And as already noted, this ignores several other hazards of the same sort,

Re: Should heapam_estimate_rel_size consider fillfactor?

On 2/4/25 16:02, Tomas Vondra wrote: > ... > > Thanks for the report. And yeah, clamping it to 1 seems like the right > fix for this. I wonder if it's worth inventing some sort of test for > this, shouldn't be too hard I guess. > > In any case, I'll take care of the fix/backpatch soon. > Here's

Re: RFC: Packing the buffer lookup table

On Sat, 1 Feb 2025 at 06:01, Zhang Mingli wrote: > > > > Zhang Mingli > www.hashdata.xyz > On Jan 30, 2025 at 15:49 +0800, Matthias van de Meent < boekewurm+postg...@gmail.com>, wrote: > > Hi, > > Thanks for your insights. > While the buffer tag consumes a relatively small amount of space in the o

Re: Eagerly scan all-visible pages to amortize aggressive vacuum

On Mon, Feb 3, 2025 at 9:09 PM Andres Freund wrote: > > + > xreflabel="vacuum_max_eager_freeze_failure_rate"> > > + vacuum_max_eager_freeze_failure_rate > > (floating point) > > + > > + vacuum_max_eager_freeze_failure_rate > > configuration parameter > > + > > +

Re: Orphaned users in PG16 and above can only be managed by Superusers

On Thu, Jan 30, 2025 at 8:45 AM Ashutosh Sharma wrote: > Imagine a superuser creates role u1. Since the superuser is creating > u1, it won't have membership in any role. Now, suppose u1 creates a > new role, u2. In this case, u1 automatically becomes a member of u2 > with the admin option. However

Re: RFC: Packing the buffer lookup table

On Fri, 31 Jan 2025 at 18:23, James Hunter wrote: > > On Wed, Jan 29, 2025 at 11:49 PM Matthias van de Meent > wrote: > > > > Hi, > > > > Some time ago I noticed that every buffer table entry is quite large at 40 > > bytes (+8): 16 bytes of HASHELEMENT header (of which the last 4 bytes are > >

Re: Windows CFBot is broken because ecpg dec_test.c error

Hi, On 2025-01-30 16:18:54 +0300, Nazir Bilal Yavuz wrote: > On Wed, 29 Jan 2025 at 19:50, Andres Freund wrote: > > I don't think that's the entirety of the issue. > > > > Our dependencies aren't quite airtight enough. With a sufficiently modern > > meson, try doing e.g. > > > > rm -rf tmp_inst

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

On Tue, Feb 4, 2025 at 12:59 AM Masahiko Sawada wrote: > > On Sun, Feb 2, 2025 at 8:11 PM Amit Kapila wrote: > > > > On Fri, Jan 24, 2025 at 4:05 AM Masahiko Sawada > > wrote: > > > > > > When a standby replays a XLOG_PARAMETER_CHANGE record that lowers > > > wal_level from logical, we invalida

Re: Doc fix of aggressive vacuum threshold for multixact members storage

I confirmed the 20GB value as is described here [1]. 8k page can hold 409 member groups and each member group can hold 4 members, thus (2^32/(409 *4))*8192 = 20GB. I also fixed whitespace issues in v3. This is ready-for-committer In my opinion. Regards, Sami [1] https://github.com/postgres/po

Re: add missing PQfinish() calls to vacuumdb

On Tue, Feb 04, 2025 at 05:51:28PM +0100, Daniel Gustafsson wrote: > No objections, I too prefer to do the right thing here. +1 on backpatching. Committed. Thanks for looking. -- nathan

  1   2   >