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: 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: 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: 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: 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: 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: 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

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: 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

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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: Increased work_mem for "logical replication tablesync worker" only?

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 receiver puts almost all of the received data to temp files, then w

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

On 2/5/25 09:16, Lukas Fittl wrote: 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 se

Re: Avoid updating inactive_since for invalid replication slots

On Wed, Feb 5, 2025 at 5:53 AM Peter Smith wrote: > > 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

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

Review comments for v69-0001. == doc/src/sgml/config.sgml 1. + +Invalidate replication slots that have remained idle longer than this +duration. If this value is specified without units, it is taken as +minutes. A value of zero (which is default) disables the id

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: 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

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: 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: 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: 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: 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: 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-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 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: 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: 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: 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: 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: [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: meson missing test dependencies

Hi, I pushed these changes as part of https://postgr.es/m/fucdlk6bgvrz6vb6ruscxa5xof5w2c3voxoqontl7oasf4idxl%40uyljndimefct Greetings, Andres Freund

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

Hi, On 2025-02-04 12:46:42 -0500, Andres Freund wrote: > 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 sufficient

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

>> Separately I've been thinking how we could best have a discussion/review on >> whether the jumbling of specific plan struct fields is correct. I was >> thinking maybe a quick wiki page could be helpful, noting why to jumble/not >> jumble certain fields? > Makes sense. This is a complicated top

Re: Commitfest app release on Feb 17 with many improvements

On Tue, 4 Feb 2025 at 17:27, Álvaro Herrera wrote: > I think this has potential for excessive clutter. I propose that, if > we're going to have a column with addition/deletions, we have two > things: > > 1. the total number of addition and deletions in the whole patch >series, for the last pa

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

Jim Nasby writes: > On Tue, Feb 4, 2025 at 3:42 PM Tomas Vondra wrote: >> Perhaps requiring (INNER JOIN + FK) or (LEFT JOIN + PK) would be enough >> to make this work for most cases, and then the rest would simply use the >> regular join order algorithm. > As long as the join is still happening

Re: Virtual generated columns

On 28.01.25 10:40, Shlok Kyal wrote: Test 5: Update publication on non virtual gen with no column list specified CREATE TABLE t1 (a int, b int GENERATED ALWAYS AS (a * 2) VIRTUAL); create publication pub1 for table t1; alter table t1 replica identity full; update t1 set a = 10; No error is thro

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

On Tue, Feb 4, 2025 at 3:55 PM Robert Haas wrote: > > On Tue, Feb 4, 2025 at 2:57 PM Robert Treat wrote: > > > Yea, I thought that counting them as failures made sense because we > > > did fail to freeze them. However, now that you mention it, we didn't > > > fail to freeze them because of age, s

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: UUID v7

On Sun, Feb 2, 2025 at 11:41 AM Sergey Prokhorenko wrote: > > Dear colleagues, > > I would like to present for discussion my attached new draft documentation on > UUID functions (Section 9.14. UUID Functions), which replaces the previously > proposed draft at https://www.postgresql.org/docs/deve

Re: UUID v7

On Sun, Feb 2, 2025 at 2:15 AM Andrey Borodin wrote: > > > > > On 31 Jan 2025, at 23:49, Masahiko Sawada wrote: > > > > Thank you for the patch! I agree with the basic direction of this fix. > > Here are some review comments: > > > > --- > > -static inline int64 get_real_time_ns_ascending(); > >

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

Tomas Vondra writes: >> The interesting thing about this is we pretty much have all the >> infrastructure for detecting such FK-related join conditions >> already. Possibly the join order forcing could be done with >> existing infrastructure too (by manipulating the joinlist). > Maybe, interesti

Re: vacuumdb changes for stats import/export

I had the opportunity to bring this patch set up for discussion at the developer meeting at FOSDEM PGDay last week [0]. There seemed to be a strong consensus that the idea of a "missing only" mode for vacuumdb's analyze options was useful (especially so if the extended stats piece of the stats imp

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

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 >>> query structure (not stats), which would be nice for pr

Re: doc: explain pgstatindex fragmentation

On 1/27/25 20:56, Ants Aasma wrote: I'll set the patch "ready for committer". Thanks! I personally would still like to know how fragmentation slows down performance. Probable reason is that scanning an unfragmented index results in sequential I/O patterns that the kernel read-ahead mechan

Re: hash_search_with_hash_value is high in "perf top" on a replica

On Wed, Feb 5, 2025 at 10:22 AM Thomas Munro wrote: > (replaying LsnReadQueue) s/replaying/replacing/

Re: hash_search_with_hash_value is high in "perf top" on a replica

On Sun, Feb 2, 2025 at 3:44 AM Ants Aasma wrote: > The other direction is to split off WAL decoding, buffer lookup and maybe > even pinning to a separate process from the main redo loop. Hi Ants, FWIW I have a patch set that changes xlogprefetcher.c to use read_stream.c, which I hope to propose

Re: SIGSEGV, FPE fix in pg_controldata

On Tue, Feb 4, 2025 at 6:36 PM Ilyasov Ian wrote: > > 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. Ok. > >Also, I don't think we should change > segment size to uint32 as it's al

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

On 2/4/25 21:34, Joe Conway wrote: > On 2/4/25 09:00, Tomas Vondra wrote: >> There's a lot of stuff that could / should be improved on the current >> patch. For (1) we might add support for more complex cases with >> snowflake schemas [3] or with multiple fact tables. At the same time (1) >> nee

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

On Tue, Feb 4, 2025 at 2:57 PM Robert Treat wrote: > > Yea, I thought that counting them as failures made sense because we > > did fail to freeze them. However, now that you mention it, we didn't > > fail to freeze them because of age, so maybe we don't want to count > > them as failures. I don't

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

On Tue, Feb 4, 2025 at 10:20 AM Masahiko Sawada wrote: > > 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_PAR

Re: Add -k/--link option to pg_combinebackup

On Wed, Jan 15, 2025 at 12:42 PM Israel Barth Rubio wrote: > With the current implementation of pg_combinebackup, we have a few > copy methods: --clone, --copy and --copy-file-range. By using either of > them, it implicates an actual file copy in the file system, i.e. among > other things, disk us

Re: Add a warning message when using unencrypted passwords

On 04/02/2025 17:59, Tom Lane wrote: 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 s

Re: RFC: Additional Directory for Extensions

On 2025-02-03 Mo 3:42 PM, David E. Wheeler wrote: Hi Peter, prefix= should only be set when running the "install" target, not when building (make all). I see. I confirm that works. Still, don’t all the other parameters work when passed to any/all targets? Should this one have an extension-

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

On 2/4/25 09:00, Tomas Vondra wrote: There's a lot of stuff that could / should be improved on the current patch. For (1) we might add support for more complex cases with snowflake schemas [3] or with multiple fact tables. At the same time (1) needs to be very cheap, so that it does not regress e

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: new commitfest transition guidance

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 author who knows that > the > author is on vac

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

On 2/4/25 20:43, Jeff Davis wrote: > 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 in

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: 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: 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: 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

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: hash_search_with_hash_value is high in "perf top" on a replica

On Sat, 1 Feb 2025 at 16:55, Andres Freund wrote: > > Hi, > > On 2025-02-01 15:43:41 +0100, Ants Aasma wrote: > > On Fri, Jan 31, 2025, 15:43 Andres Freund wrote: > > > > > > Maybe it's a red herring though, but it looks pretty suspicious. > > > > > > It's unfortunately not too surprising - our b

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

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 a standard policy or comment wording abou

Re: RFC: Packing the buffer lookup table

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-coded replacement that has fewer indirections during lookups, and allows for a muc

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: 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: 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: 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: 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: Eagerly scan all-visible pages to amortize aggressive vacuum

Thanks for the review! 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 > > Date: Mon, 27 Jan 2025 12:23:00 -0500 > > Subject: [PATCH

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: 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: 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: 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: 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: 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: 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 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

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: 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

  1   2   >