Re: Implement waiting for wal lsn replay: reloaded

On 12/4/24 18:12, Kirill Reshke wrote: On Wed, 27 Nov 2024 at 09:09, Alexander Korotkov wrote: Any comments? What's the current status of https://commitfest.postgresql.org/50/5167/ ? Should we close it or reattach to this thread? To push this feature further I rebased the patch onto current m

Buffer overflow in zic

Hello. Ifyou compilezicwithASAN,you cangetthe following(notethiswill delete/etc/localtime): |$ sudo ./zic -l fff = ==5528==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0053103f at pc 0x00501ceb bp 0x7ffe9fb

Re: Show WAL write and fsync stats in pg_stat_io

Hi, On Thu, Feb 06, 2025 at 12:35:28PM +0900, Michael Paquier wrote: > On Wed, Feb 05, 2025 at 09:52:14PM -0500, Tom Lane wrote: > > Michael Paquier writes: > > Yeah, if we want to assume we can see stats counts left over from > > initdb, we have to put this in a TAP test, though I dunno if that

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 directory: is that a miss? > > Hmm, "make uninstall

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

On Thu, Feb 6, 2025 at 12:30 AM Masahiko Sawada wrote: > > I've updated the patch accordingly. > Today, again thinking about the proposed fix, I was wondering about the following case. Say, on hot_standby, the user created a logical slot, then shut down hot_standby, turn off the hot_standby flag,

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

On Wed, Feb 05, 2025 at 03:28:04PM +0900, Michael Paquier wrote: > 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 acts as a wrapper of `diff` with its formalized output format. > It is not really abou

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

On Thu, Feb 6, 2025 at 10:17 AM Amit Kapila wrote: > > On Thu, Feb 6, 2025 at 8:02 AM Nisha Moond wrote: > > > > > > > > 2. > > > + * Flush all replication slots to disk. Also, invalidate obsolete slots > > > during > > > + * non-shutdown checkpoint. > > > * > > > * It is convenient to flush

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

On Thu, Feb 6, 2025 at 8:02 AM Nisha Moond wrote: > > On Wed, Feb 5, 2025 at 2:42 PM Amit Kapila wrote: > > > > Would it address your concern if we write the actual idle duration > > (now - inactive_since) instead of directly using inactive_since in the > > above message? > > > > Simply using the

Re: Statistics Import and Export

On Wed, 2025-02-05 at 23:01 -0500, Corey Huinker wrote: > And here's an update to the pg_dump code itself. This currently has > failing TAP tests for statistics in the custom and dir formats, but > is working otherwise. This thread got slightly mixed up, so I'm replying to the v45-0001 posted here

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

Hi Shubham. Here are some review comments for v3-0001. FYI, I skipped the review of the test code because I saw Kuroda-san had already posted some comments about the tests == Commit message 1. This patch enhances the 'pg_createsubscriber' utility to automatically fetch all non-template data

Re: Statistics Import and Export

On Mon, Jan 27, 2025 at 11:09 AM Corey Huinker wrote: > On Mon, Jan 27, 2025 at 9:05 AM jian he > wrote: > >> On Tue, Jan 21, 2025 at 7:31 AM Jeff Davis wrote: >> > >> > On Mon, 2025-01-20 at 16:45 -0500, Corey Huinker wrote: >> > > >> > > What I struggle to understand is how that purpose isn't

Re: Statistics Import and Export

On Sat, Jan 25, 2025 at 10:02 AM Corey Huinker wrote: > Fixed. Holding off on posting updated patch pending decision on what's the >>> best thing to do with partitioned indexes. >> >> > Though I was able to get it to work multiple ways, the one that seems to > make the most sense given Michael an

Re: Show WAL write and fsync stats in pg_stat_io

On Wed, Feb 05, 2025 at 09:52:14PM -0500, Tom Lane wrote: > Michael Paquier writes: > Yeah, if we want to assume we can see stats counts left over from > initdb, we have to put this in a TAP test, though I dunno if that is > the most appropriate one. A second option I can think of for the reads i

Re: Show WAL write and fsync stats in pg_stat_io

Michael Paquier writes: > The queries for the normal context are not going to have this problem > even if we have a pg_stat_reset_shared('io'), but the init context > gets unstable, unfortunately. I don't see a way through here in the > main regression test suite, so how about moving these into >

Re: Improve documentation regarding custom settings, placeholders, and the administrative functions

On Wed, Feb 5, 2025 at 7:36 PM Zhang Mingli wrote: > On Oct 20, 2024 at 04:12 +0800, David G. Johnston < > david.g.johns...@gmail.com>, wrote: > > > Mostly I'm pointing out the fact that one can never take the null value to > be the actual value of a setting. In terms of current_setting this the

Re: Improve documentation regarding custom settings, placeholders, and the administrative functions

On Oct 20, 2024 at 04:12 +0800, David G. Johnston , wrote: > > Mostly I'm pointing out the fact that one can never take the null value to be > the actual value of a setting.  In terms of current_setting this then > establishes the fact that the null value it may return is an error-handling > al

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

On Wed, Feb 5, 2025 at 2:42 PM Amit Kapila wrote: > > On Wed, Feb 5, 2025 at 10:30 AM vignesh C wrote: > > > > 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 in

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

On Wed, Feb 5, 2025 at 12:58 PM Peter Smith wrote: > > Hi Nisha, > > Some review comments for the patch v69-0002. > > == > .../t/044_invalidate_inactive_slots.pl > > 2. > +if ($ENV{enable_injection_points} ne 'yes') > +{ > + plan skip_all => 'Injection points not supported by this build'; > +}

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

On Wed, Feb 5, 2025 at 10:30 AM vignesh C wrote: > > 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]. > > 2) Here we have mentioned about invalidation happens only for a) > released slots b) inactive slots replication

Re: Show WAL write and fsync stats in pg_stat_io

On Wed, Feb 05, 2025 at 09:06:24PM -0500, Tom Lane wrote: > Basically, this test is broken because it assumes that the server > is freshly started. That's not a scenario the buildfarm runs > the core tests under, unfortunately, but it is one commonly > used in hand testing. Right. You are pointi

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

Dear Shubham, Thanks for working on it. I have some comments for the patch. 01. fetch_all_databases ``` +/* Placeholder function to fetch all databases from the publisher */ +static void +fetch_all_databases(struct CreateSubscriberOptions *opt) ``` Please update the comment atop function. 02. f

Re: Show WAL write and fsync stats in pg_stat_io

Nazir Bilal Yavuz writes: > On Wed, 5 Feb 2025 at 21:32, Tom Lane wrote: >> Locally, the test added by this commit fails like so: > My thoughts when adding this test was that startup process must do the > WAL read I/O while server is starting, i.e.: Oh! The problem is much simpler than I thoug

Re: Trigger more frequent autovacuums of heavy insert tables

Hi Melanie Plageman Thank you for working on this ,Actually, there were two patches aimed at optimizing vacuum-triggered processes, and one of them reached a consensus and has been committed:https://commitfest.postgresql.org/52/5046/ , https://commitfest.postgresql.org/51/5395/, Maybe referring

Re: Remove unnecessary static specifier

On Wed, 05 Feb 2025 at 18:17, Daniel Gustafsson wrote: >> On 5 Feb 2025, at 17:05, Tom Lane wrote: > >> While we're at it, could we make the adjacent "magic" string be >> "static const char *magic"? (Probably needs a couple more >> "const" modifiers at use sites, too.) > > Good point, from the l

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

On Wed, Feb 05, 2025 at 11:03:25AM +, Bertrand Drouvot wrote: > A few tests are already using this technique (including injection_points in > inplace.spec). Right. I've just re-enabled the permutation. Now let's keep a track of the activity in the CI and the buildfarm. -- Michael signature

Re: per backend WAL statistics

On Wed, Feb 05, 2025 at 02:28:08PM +, Bertrand Drouvot wrote: > Agree, I'll start a dedicated thread for that. Thanks. -- Michael signature.asc Description: PGP signature

Re: Docs for pg_basebackup needs v17 note for incremental backup

Is there seriously not a single person in the past three weeks who has seen this and not had the minute to spare to say "yes, this should be documented"? David J. On Mon, Jan 13, 2025 at 8:13 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > Hackers, > > Should the following paragraph

Re: Improve documentation regarding custom settings, placeholders, and the administrative functions

Adding a file patch so I can load this into the Commitfest. On Tue, Dec 31, 2024 at 1:49 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > Thoughts? Anyone? > > On Sat, Oct 19, 2024 at 1:11 PM David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> Hey! >> >> Motivated by recent

Re: Separate GUC for replication origins

On Wed, Feb 5, 2025 at 4:39 PM Euler Taveira wrote: > > On Wed, Feb 5, 2025, at 1:56 AM, Amit Kapila wrote: > > 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

Re: Separate GUC for replication origins

On Wed, Feb 5, 2025, at 1:56 AM, Amit Kapila wrote: > 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)

Re: new commitfest transition guidance

Peter Geoghegan writes: > Evidently this new policy is why my skip scan patch series wasn't > being tested by CI. Well no, the reason CI wasn't testing anything was the cfbot was broken. See nearby "CFBot is broken" thread. > I just don't think that this new policy makes sense. At least not as

Re: new commitfest transition guidance

On Tue, Feb 4, 2025 at 8:10 PM Tom Lane wrote: > As of right now, I see that 79 CF entries have been manually pushed to > 2025-03 (but it's hard to tell how many of those were moved before > 2025-01 closed). 180 live entries are still in 2025-01, including > 20 RfC ones. I think this experiment

Fwd: [PATCH] Add regression tests of ecpg command notice (error / warning)

On Wed, Feb 5, 2025 at 9:31 PM Ryo Kanbayashi wrote: > > Hi hackers, > > When I wrote patch of ecpg command notice bug, I recognized needs of > regression tests for ecpg command notices and I say that I write the > tests. > > https://commitfest.postgresql.org/52/5497/ > https://www.postgresql.org/

Re: Better visualization of default values

On Thu, Feb 6, 2025 at 8:08 AM Marcos Pegoraro wrote: > > Reading DOCs sometimes is boring because you want to know only the default > value of something. I know what that GUC is, I know how to change it, I only > don't remember what its default value is. Then you have to read that entire > par

Re: [PATCH] Add regression tests of ecpg command notice (error / warning)

On Wed, Feb 5, 2025 at 9:31 PM Ryo Kanbayashi wrote: > > Hi hackers, > > When I wrote patch of ecpg command notice bug, I recognized needs of > regression tests for ecpg command notices and I say that I write the > tests. > > https://commitfest.postgresql.org/52/5497/ > https://www.postgresql.org/

Re: Virtual generated columns

On Tue, 4 Feb 2025 at 22:36, Peter Eisentraut wrote: > > Yeah, this is quite contorted. I have renamed it like you suggested. I looked over this again and I think the patch is in good shape to be committed. One thought that occurred to me was whether it would be better for the psql describe out

Re: RFC: Packing the buffer lookup table

On Wed, 5 Feb 2025 at 02:14, Andres Freund wrote: > > 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 byt

Re: RFC: Packing the buffer lookup table

On Wed, 5 Feb 2025 at 02:22, Andres Freund wrote: > > 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, w

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

> > > Hmmm, yeah. But that's only for the INNER JOIN case. But I've seen many > of these star join queries with LEFT JOIN too, and then the FKs are not > needed. All you need is a PK / unique index on the other side. Indeed, many installations specifically _remove_ foreign keys because of the dre

Re: Confine vacuum skip logic to lazy_scan_skip

On Sat, Jan 18, 2025 at 11:51 AM Tomas Vondra wrote: > > Sure. I repeated the benchmark with v13, and it seems the behavior did > change. I no longer see the "big" regression when most of the pages get > updated (and need vacuuming). > > I can't be 100% sure this is due to changes in the patch, be

Re: Confusing variable naming in LWLockRelease

On Wed, 2025-01-29 at 23:16 -0800, Jacob Brazeal wrote: > Here the variable name "oldstate" leads one to believe that the value > is fetched before the sub operation, similar to some other usages in > lwlock.c. I believe it refers to the state of the lock prior to lock acquisition; not prior to su

Re: Trigger more frequent autovacuums of heavy insert tables

On Thu, Jan 16, 2025 at 5:50 PM Melanie Plageman wrote: > > On Thu, Jan 16, 2025 at 4:43 PM Melanie Plageman > wrote: > > > > On Fri, Oct 25, 2024 at 11:14 AM Melanie Plageman > > wrote: > > > > > > I've done something similar to this in attached v2. > > > > This needed a rebase. See attached v4

Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)

On 05.02.2025 21:56, Tom Lane wrote: It's not a bug. Since the call specifies NIL pathkeys (meaning it doesn't care about sort order) and does not insist on a parallel-safe path, there should always be a path that satisfies it. The only way it could fail to find a path is if the rel's pathlist

Re: New GUC autovacuum_max_threshold ?

Committed. -- nathan

Re: Update Unicode data to Unicode 16.0.0

On Mon, 2024-11-11 at 07:27 +0100, Peter Eisentraut wrote: > Here is the patch to update the Unicode data to version 16.0.0. > > Normally, this would have been routine, but a few months ago there > was > some debate about how this should be handled. [0]  AFAICT, the > consensus > was to go ahead

Re: Optimization for lower(), upper(), casefold() functions.

On Tue, 2025-02-04 at 23:19 +0300, Alexander Borisov wrote: > I've done many different experiments and everywhere the result is > within > the margin of the v2 patch result. Great, thank you for working on this! There doesn't appear to be a downside. Even though it's more complex, we have exhaust

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

On Wed, 5 Feb 2025 at 21:05, Daniel Gustafsson wrote: > For reference, you meant 53 right? Yes, I meant 53 > If the > CFBot always need one in "Future" state we should document that to make sure > we > don't miss that going forward (and perhaps automate it to make sure we dont > make manual wor

Re: problems with extensions compiling after upgrade to fc42 (and gcc15)

st 5. 2. 2025 v 21:55 odesílatel Peter Eisentraut napsal: > On 05.02.25 21:31, Pavel Stehule wrote: > > I found a problem with compilation of plpgsql_check when I upgraded my > > fedora. > > > > plpgsql_check cannot be compiled (against PostgreSQL 15-). The > > compilation fails > > > > rc/expr_w

RE: Proposal for Updating CRC32C with AVX-512 Algorithm.

Hi John, > Further, we verified upthread that Intel's current and near-future product > line > includes server chips (some with over 100 cores, so not exactly low-end) that > don't support AVX-512 at all. I have no idea how common they will be, but they > will certainly be found in cloud datacen

Re: problems with extensions compiling after upgrade to fc42 (and gcc15)

On 05.02.25 21:31, Pavel Stehule wrote: I found a problem with compilation of plpgsql_check when I upgraded my fedora. plpgsql_check cannot be compiled (against PostgreSQL 15-). The compilation fails rc/expr_walk.c:84:66: warning: passing argument 2 of ‘query_tree_walker’ from incompatible

Re: problems with extensions compiling after upgrade to fc42 (and gcc15)

On Wed, Feb 05, 2025 at 09:31:27PM +0100, Pavel Stehule wrote: > I found a problem with compilation of plpgsql_check when I upgraded my > fedora. > > plpgsql_check cannot be compiled (against PostgreSQL 15-). The compilation > fails > > rc/expr_walk.c:84:66: warning: passing argument 2 of `query_

Improve CRC32C performance on SSE4.2

This patch improves the performance of SSE42 CRC32C algorithm. The current SSE4.2 implementation of CRC32C relies on the native crc32 instruction and processes 8 bytes at a time in a loop. The technique in this paper uses the pclmulqdq instruction and processing 64 bytes at time. The algorithm

problems with extensions compiling after upgrade to fc42 (and gcc15)

Hi I found a problem with compilation of plpgsql_check when I upgraded my fedora. plpgsql_check cannot be compiled (against PostgreSQL 15-). The compilation fails rc/expr_walk.c:84:66: warning: passing argument 2 of ‘query_tree_walker’ from incompatible pointer type [-Wincompatible-pointer-types

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

On Tue, Feb 4, 2025 at 11:37 PM Sutou Kouhei wrote: > > 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 cop

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

> On 5 Feb 2025, at 20:36, Jelte Fennema-Nio wrote: > > On Wed, 5 Feb 2025 at 20:29, Jelte Fennema-Nio wrote: >> I'll look into fixing that soonish. I took a quick look and it seems >> related to some unexpected response from the Cirrus API. > > Okay I think I got it running again. It didn't li

Re: Show WAL write and fsync stats in pg_stat_io

Hi, On Wed, 5 Feb 2025 at 21:32, Tom Lane wrote: > > Michael Paquier writes: > > At the end, we want this patch and this data, and my benchmarcking is > > not showing much differences even if going through a workload with > > many pages, so I've used the version relying entirely on > > track_io_

Re: Failed assertion with jit enabled

Hi, On 2025-02-05 13:07:58 -0500, Tom Lane wrote: > Bertrand Drouvot writes: > > I did look more closely (knowing that it works for you) and the issue is > > linked > > to not using --with-llvm. Inded, I used to use --with-llvm but removed it > > some > > time ago for testing. > > So the failed

Re: Prevent COPY FREEZE on Foreign tables

> so the only reason I can see > for not back-patching it is that it could lead to somewhat widespread > breakage for existing scripts, etc. which are arguably kind-of working > today. That is my thought for not backpatching. It's not breaking the COPY command, it's just not applying an optimizati

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

On Wed, 5 Feb 2025 at 20:29, Jelte Fennema-Nio wrote: > I'll look into fixing that soonish. I took a quick look and it seems > related to some unexpected response from the Cirrus API. Okay I think I got it running again. It didn't like that there was no commitfest with number 54 yet. So I created

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

Hi, On 2025-02-05 14:20:59 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2025-02-05 14:09:02 -0500, Tom Lane wrote: > >> Hard to tell, considering the cfbot has been completely wedged > >> since Sunday. > > > It passed on the postgres repo just before this commit: > > https://cirrus-ci

Re: Prevent COPY FREEZE on Foreign tables

On Wed, Feb 05, 2025 at 01:11:44PM -0600, Sami Imseih wrote: > I don't think we will need to backpatch, unless someone has a different > opinion about this. I think this falls into the category of a bug, so the only reason I can see for not back-patching it is that it could lead to somewhat widesp

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

On Wed, 5 Feb 2025 at 20:21, Tom Lane wrote: > > Andres Freund writes: > > On 2025-02-05 14:09:02 -0500, Tom Lane wrote: > >> Hard to tell, considering the cfbot has been completely wedged > >> since Sunday. > > > It passed on the postgres repo just before this commit: > > https://cirrus-ci.com

Re: Prevent COPY FREEZE on Foreign tables

> Yeah, I'd rather error out than expect users to respond to warnings to the > effect of "hey, you told us to do something, but we did something else that > isn't what you asked us to do." That both retains the broken feature and > adds more noise, neither of which seems desirable. I agree. Sami

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

On 2025-Feb-05, Masahiko Sawada wrote: > I think that the patch needs to check if the function's result type is > COPY_HANDLEROID by using get_func_rettype(), before calling it. But > with this check, we can prevent arbitrary functions from being called > via COPY. Why do we need to extend CREATE

Re: Prevent COPY FREEZE on Foreign tables

On Wed, Feb 05, 2025 at 01:05:32PM -0600, Sami Imseih wrote: >> Instead of throwing an error, how about we turn that into a warning? >> This way, if someone is batch-importing data for multiple tables, it won´t >> interrupt their script that generates a COPY for each table. >> Is it better to give

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

Andres Freund writes: > On 2025-02-05 14:09:02 -0500, Tom Lane wrote: >> Hard to tell, considering the cfbot has been completely wedged >> since Sunday. > It passed on the postgres repo just before this commit: > https://cirrus-ci.com/build/4733656549294080 > and then failed with it: > https:

Re: Prevent COPY FREEZE on Foreign tables

my apologies for the top post in the last reply. I hit send too fast :) I also created a CF entry for this https://commitfest.postgresql.org/52/5544/ I don't think we will need to backpatch, unless someone has a different opinion about this. Regards, Sami

Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

On Tue, Feb 4, 2025 at 11:48 PM Bertrand Drouvot wrote: > > 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

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

Hi, On 2025-02-05 14:09:02 -0500, Tom Lane wrote: > Jelte Fennema-Nio writes: > > I guess you probably noticed, but in case you didn't: CI on windows is > > still broken. > > Hard to tell, considering the cfbot has been completely wedged > since Sunday. It passed on the postgres repo just befor

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

Jelte Fennema-Nio writes: > I guess you probably noticed, but in case you didn't: CI on windows is > still broken. Hard to tell, considering the cfbot has been completely wedged since Sunday. regards, tom lane

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

Hi, On 2025-02-05 19:42:05 +0100, Jelte Fennema-Nio wrote: > On Wed, 5 Feb 2025 at 00:22, Andres Freund wrote: > > Pushed like that. > > > > I'll watch CI and BF over the next hours. > > I guess you probably noticed, but in case you didn't: CI on windows is > still broken. Huh. CI did pass on a

Re: Prevent COPY FREEZE on Foreign tables

Thanks for the feedback! > Instead of throwing an error, how about we turn that into a warning? > This way, if someone is batch-importing data for multiple tables, it won’t > interrupt their script that generates a COPY for each table. > Is it better to give them a heads-up without making them mo

Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)

Daniel Gustafsson writes: > On 5 Feb 2025, at 18:34, Ranier Vilela wrote: >> This is evidence that we do not have reports about this bug. > Before that can be stated it needs to be determined if this is a bug, this > thread has not done that yet. It's not a bug. Since the call specifies NIL pa

Re: log_min_messages per backend type

Hello Euler, On 2024-Dec-17, Euler Taveira wrote: > Sometimes you need to inspect some debug messages from autovacuum worker but > you cannot apply the same setting for backends (that could rapidly fill the > log > file). This proposal aims to change log_min_messages to have different log > leve

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

On Wed, 5 Feb 2025 at 00:22, Andres Freund wrote: > Pushed like that. > > I'll watch CI and BF over the next hours. I guess you probably noticed, but in case you didn't: CI on windows is still broken.

Re: Show WAL write and fsync stats in pg_stat_io

Michael Paquier writes: > At the end, we want this patch and this data, and my benchmarcking is > not showing much differences even if going through a workload with > many pages, so I've used the version relying entirely on > track_io_timing and applied it. Locally, the test added by this commit

Re: SQL:2011 application time

On 2/5/25 05:37, Peter Eisentraut wrote: On 29.01.25 07:34, Paul Jungwirth wrote: Is it possible to commit an RI_PLAN_NO_ACTION addition and see if that makes the buildfarm failures go away? Here is a proposed patch for that (v48.1). I would understand if this is too questionable a practice---b

Re: RFC: Additional Directory for Extensions

Hi Andrew, On Feb 4, 2025, at 15:34, Andrew Dunstan wrote: >> 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-specific name? > > IDK, I don't understand what you think you're saying when you specify >

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

On Wed, Feb 5, 2025 at 3:49 AM Álvaro Herrera wrote: > > On 2025-Feb-03, Vladlen Popolitov wrote: > > > You use FORMAT option to add new formats, filling it with routine name > > in shared library. As result any caller can call any routine in PostgreSQL > > kernel. > > I think, it will start compe

Re: Inquiry About Google Summer of Code Projects

Hi Mohamed, On 2/5/25 10:29 AM, Mohamed Badawy wrote: I hope this message finds you well. My name is Mohamed, and I am currently a third-year Computer Engineering student. I possess skills in C++, C#, Python, Object-Oriented Programming (OOP), Data Structures and Algorithms (DSA), SQL, and SQ

Re: Failed assertion with jit enabled

Bertrand Drouvot writes: > I did look more closely (knowing that it works for you) and the issue is > linked > to not using --with-llvm. Inded, I used to use --with-llvm but removed it some > time ago for testing. > So the failed build was not using --with-llvm and was relying on an old > versio

Re: Failed assertion with jit enabled

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 directory: is that a miss? Hmm, "make uninstall" is supposed to remove things from the install directory, but maintainer-clean is

Re: Feature Request: Add AES-128-CFB Mode Support to pgcrypto

On 2025-Jan-29, Umar Hayat wrote: > Hi Daniel Gustafsson and Vladyslav Nebozhyn, > I created a patch for CFB mode for AES encryption. Please have a look > and let me know what you think. > Patch covers implementation, tests and documentation changes. > > OpenSSL profives aes-cfb1, aes-cfb8 and ae

Inconsistency between Compression and Storage for Foreign Tables

Hi, While developing the CREATE FOREIGN TABLE LIKE functionality in [0], I had to consider the like_options, such as STORAGE, COMPRESSION, and others. Although foreign tables do not have actual storage in PostgreSQL, we allow the STORAGE option as it may be useful for foreign data wrappers (FD

Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)

> On 5 Feb 2025, at 18:34, Ranier Vilela wrote: > Em qua., 5 de fev. de 2025 às 14:08, Daniel Gustafsson > escreveu: >> Yet the author wrote an Assert here (over a decade ago), so rather than >> blindly >> changing that it seems reasonable to motivate a patch like this w

Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)

Hi. Em qua., 5 de fev. de 2025 às 14:08, Daniel Gustafsson escreveu: > > On 5 Jan 2025, at 00:29, Ranier Vilela wrote: > > > > Hi. > > > > Per Coverity. > > > > All call sites of function *get_cheapest_path_for_pathkeys* checks > > for NULL returns. > > > > So, it is highly likely that the func

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 generate_series(1,1000); > > server

Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)

Em qua., 5 de fev. de 2025 às 14:09, Ilia Evdokimov < ilya.evdoki...@tantorlabs.com> escreveu: > But what should we do if cheapest == NULL further? Should we return NULL > of get_cheapest_parameterized_child_path() function? > > If it is, we should write it like this: > > if (cheapset == NULL || b

Re: Feature Request: Add AES-128-CFB Mode Support to pgcrypto

> On 5 Feb 2025, at 18:24, Álvaro Herrera wrote: > Anyway, at least the bytes appear to be interpreted the same by both > openssl and this new function, so that's good news. Thanks for confirming. Short of a very small doc change (which I don't have handy on this laptop) I think this patch is r

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

Attached v16 implements the logic to not count pages we failed to freeze because of cleanup lock contention as eager freeze failures. Re the code: I didn't put it in the same if statement block as lazy_scan_prune() because I wanted to avoid another level of indentation, but I am open to changing i

Re: Remove unnecessary static specifier

> On 5 Feb 2025, at 17:05, Tom Lane wrote: > While we're at it, could we make the adjacent "magic" string be > "static const char *magic"? (Probably needs a couple more > "const" modifiers at use sites, too.) Good point, from the link referenced it's clear that FreeBSD has made that change as w

Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)

But what should we do if cheapest == NULL further? Should we return NULL of get_cheapest_parameterized_child_path() function? If it is, we should write it like this: if (cheapset == NULL || bms(PATH_REQ_OUTER(cheapset), required_outer))     return cheapest; I'll look into this issue further.

Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)

> On 5 Jan 2025, at 00:29, Ranier Vilela wrote: > > Hi. > > Per Coverity. > > All call sites of function *get_cheapest_path_for_pathkeys* checks > for NULL returns. > > So, it is highly likely that the function will return NULL. > > IMO, the Assert in this particular call, is not fully effect

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

=?utf-8?Q?=C3=81lvaro?= Herrera writes: > On 2025-Feb-04, Tom Lane wrote: >> The implementation I had in mind was to just invent a >> pg_log_error_internal() macro alias for pg_log_error(). >> That'd take about two lines counting the explanatory comment. >> This approach would fail to suppress the

Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)

Hi. Em qua., 5 de fev. de 2025 às 13:51, Ilia Evdokimov < ilya.evdoki...@tantorlabs.com> escreveu: > > On 05.01.2025 02:29, Ranier Vilela wrote: > > Hi. > > > > Per Coverity. > > > > All call sites of function *get_cheapest_path_for_pathkeys* checks > > for NULL returns. > > > > So, it is highly

Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)

On 05.01.2025 02:29, Ranier Vilela wrote: Hi. Per Coverity. All call sites of function *get_cheapest_path_for_pathkeys* checks for NULL returns. So, it is highly likely that the function will return NULL. IMO, the Assert in this particular call, is not fully effective. Fix removing the Ass

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

On Tue, Feb 4, 2025 at 5:34 PM Melanie Plageman wrote: > I think I misspoke when I said we are unlikely to have contended > all-visible pages. I suppose it is trivial to concoct a scenario where > there are many pinned all-visible pages. It's hard to keep heap pages pinned for a really long time,

Re: [PATCH] SVE popcount support

On Tue, Feb 04, 2025 at 09:01:33AM +, chiranmoy.bhattacha...@fujitsu.com wrote: >> +/* >> + * For smaller inputs, aligning the buffer degrades the performance. >> + * Therefore, the buffers only when the input size is sufficiently >> large. >> + */ > >> Is the inverse true, i

Re: Remove unnecessary static specifier

Daniel Gustafsson writes: > From a quick first inspection (and running the tests with the patch applied) I > agree with this, these variables do not need to be static. I'll stare a bit > more at this to make sure but seems like the right patch. +1. All three of those variables are visibly assig

Re: CREATE ROLE bug?

On Wed, Jan 25, 2023 at 10:21 AM Robert Haas wrote: > I think that the desire to maintain the distinction between membership and ADMIN OPTION makes sense as a > general rule I haven't worked through the details but I suspect part of the issue is that we are not maintaining this distinction whe

  1   2   >