Re: [RFC] Lock-free XLog Reservation from WAL

On Mon, 27 Jan 2025 at 17:30, "Zhou, Zhiguo" wrote: > On 1/26/2025 10:59 PM, Yura Sokolov wrote: >> 24.01.2025 12:07, Japin Li пишет: >>> On Thu, 23 Jan 2025 at 21:44, Japin Li wrote: On Thu, 23 Jan 2025 at 15:03, Yura Sokolov wrote: > 23.01.2025 11:46, Japin Li пишет: >> On We

Re: using index to speedup add not null constraints to a table

hi rebased new patch attached. I also did some cosmetic changes. comments refined. make sure using index_scan mechanism to fast check column not-null can only be used via btree index. isolation tests are simplified. From be8fea79986339cadff21dbe9c4415b330a296a3 Mon Sep 17 00:00:00 2001 From: jian

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

On Wed, Feb 5, 2025 at 5:42 AM Tomas Vondra wrote: > 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. > > Perhaps requiring (INNER JOIN

Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?

Ooops, missed one commit - fixed (logic related to LP_DEAD in GIST extracted to separate commit). Also, commitfest entry is here - https://commitfest.postgresql.org/52/5542/ > v7-0004-This-should-fix-issues-with-incorrect-results-whe.patch Description: Binary data v7-0002-This-should-fix-issu

Re: per backend WAL statistics

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

Re: per backend WAL statistics

On Wed, Feb 05, 2025 at 10:22:55AM +, Bertrand Drouvot wrote: > So, wal_buffers_full has been introduced after the WalUsage structure was > there but I don't see any reason in the emails as to why it's not in the > WalUsage > structure (I might have missed it though). > > I think that this pr

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

On Wed, Feb 5, 2025 at 5:55 AM Tom Lane wrote: > Right now, if we have four tables to join, we have a joinlist > (A B C D). (Really they're integer relids, but let's use names here.) > If we decide to force C to be joined last, it should be sufficient to > convert this to ((A B D) C). If C and D

Re: Logging parallel worker draught

On 2/3/25 6:36 AM, Sami Imseih wrote: As far as the current set of patches, I had some other changes that I missed earlier; indentation to the calls in LogParallelWorkersIfNeeded and comment for the LogParallelWorkersIfNeeded function. I also re-worked the setup of the GUC as it was not setup the

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

On 2025-Feb-05, vignesh C wrote: > We can maintain the behavior you suggested when the > PUBLISH_VIA_PARTITION_ROOT option is set to false. However, when > PUBLISH_VIA_PARTITION_ROOT is true, the table data is copied from the > root table (as intended by the user), which will also include the > fo

Re: Commitfest app release on Feb 17 with many improvements

On 2025-Feb-04, Jelte Fennema-Nio wrote: > To be clear: the only stats column currently in the staging > environment shows exactly this. Changes 4 and 5 are *not* visible in > columns on the commitfest page, that info is currently only visible on > the patch details page. (For context for others:

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

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 cost of gettext's > trying to look up the str

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

Hi, On Wed, Feb 05, 2025 at 03:12:53PM +0900, Michael Paquier wrote: > 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

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

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 competition, who can find most dangerous routine > to call just from COP

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

On Wed, 5 Feb 2025 at 01:26, Shubham Khanna wrote: > > 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 > > >

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

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

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

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: 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: Make COPY format extendable: Extract COPY TO format implementations

Álvaro Herrera писал(а) 2025-02-05 18:49: 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 competition, who can find most da

Re: Failed assertion with jit enabled

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 closed the connection unexpectedly Hmm, works for me on today's HEAD. > The f

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

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: Special-case executor expression steps for common combinations

> On 13 Sep 2024, at 15:01, Andreas Karlsson wrote: > > On 9/10/24 10:54 AM, Daniel Gustafsson wrote: >>> On 22 Jul 2024, at 23:25, Andreas Karlsson wrote: >>> >>> I have bench marked the two patches now and failed to measure any speedup >>> or slowdown from the first patch (removing return) b

Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?

Hello everyone, and Mathias! I have fixed sp-gist related crash and a few issues in implementation. Now it passes tests and (in my opinion) feels simpler. I'll register that thread in commitfest to honor the bureaucracy. Best regards, Mikhail. v6-0003-This-should-fix-issues-with-incorrect-resu

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]. > > Few minor suggestions: > 1) In the slot invalidation reporting below: > + case RS_INVAL_IDLE_TIME

Re: Sample rate added to pg_stat_statements

On 04.02.2025 20:59, Sami Imseih wrote: 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_state

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)

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

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

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

Inquiry About Google Summer of Code Projects

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 SQL Server. Recently, I have also gained knowledge about Git

Re: Showing applied extended statistics in explain Part 2

On 05.02.2025 09:28, Tatsuro Yamada wrote: 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 -h

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

Failed assertion with jit enabled

Hi hackers, 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 closed the connection unexpectedly This probably means the server terminated abnormally

Re: per backend WAL statistics

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

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

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

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

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_

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

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

  1   2   >