[BUG] Skipped initialization of some xl_xact_parsed_prepare fields

Hi, I noticed that inside ParsePrepareRecord function we are missing initialization of `nstats` and `nabortstats` fields of xl_xact_parsed_prepare structure: *** (current code in master) memset(parsed, 0, sizeof(*parsed)); parsed->xact_time = xlrec->prepared_at; parsed->origin_lsn = xlrec->origin_

Re: Should we optimize the `ORDER BY random() LIMIT x` case?

Hi Aleksander if we can optimize the query， that would be great，Then we won't need to pull a lot of data to the program end and randomly pick the needed data there. On Thu, 15 May 2025 at 07:41, Aleksander Alekseev wrote: > Hi, > > If I didn't miss anything, currently we don't seem to support s

Should we optimize the `ORDER BY random() LIMIT x` case?

Hi, If I didn't miss anything, currently we don't seem to support sampling the result of an arbitrary SELECT query efficiently. To give one specific example: CREATE TABLE temperature( ts TIMESTAMP NOT NULL, city TEXT NOT NULL, temperature INT NOT NULL); CREATE TABLE humidity( ts TI

Re: Statistics Import and Export

Thanks Nathan. Here is the patch with a comment. On Wed, May 14, 2025 at 8:53 AM Nathan Bossart wrote: > On Tue, May 13, 2025 at 05:01:02PM -0700, Hari Krishna Sunder wrote: > > We found a minor issue when testing statistics import with upgrading from > > versions older than v14. (We have VACUUM

Re: Small fixes needed by high-availability tools

> I think this LSN is simply LSN where crash recovery ends... Yes, you are right and we come back to : > 1. Allow checking standby sync before making data visible after crash recovery Best regards, Mikhail.

Re: PostgreSQL 18 Beta 1 io_max_concurrency

"Jafri, Nazneen" writes: > The default setting of parameter io_max_concurrency shows 64 whereas the > documentation says -1, checking if this is the expected behavior. I think it's behaving as designed: the bootstrap default is indeed -1, but later in startup there is an an auto-tuning step that

Re: Small fixes needed by high-availability tools

> On 14 May 2025, at 05:33, Amit Kapila wrote: > >> It might not necessarily be a flag—it could be some LSN value instead. >> Also, it's not just about a "new transaction," but about any new >> snapshot that could see data not yet replicated to the synchronous >> standby. >> > > Sounds reaso

Re: Assert failure in base_yyparse

On 2025-May-14, Richard Guo wrote: > Attached is a patch that implements this. It also renames the > internally used option name and updates the error message. LGTM. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/

PostgreSQL 18 Beta 1 io_max_concurrency

Hello, The default setting of parameter io_max_concurrency shows 64 whereas the documentation says -1, checking if this is the expected behavior. PG 18 documentation says: The default setting of -1 selects a number based on shared_buffers

Re: Statistics Import and Export

On Tue, May 13, 2025 at 05:01:02PM -0700, Hari Krishna Sunder wrote: > We found a minor issue when testing statistics import with upgrading from > versions older than v14. (We have VACUUM and ANALYZE disabled) > 3d351d916b20534f973eda760cde17d96545d4c4 >

Re: Disable parallel query by default

On 2025-May-13, Scott Mead wrote: > If you have a connection pool from your application and you issue 60 > queries per minute, each that can go from 1 second to 200 ms, That > means that you are making 120 connections per minute back to the DB. > > As we know, connection establishment is brutal..

Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part

> On 13 May 2025, at 11:00 PM, David E. Wheeler wrote: > > On May 13, 2025, at 16:24, Florents Tselai wrote: > >> As Robert said—and I agree—renaming the existing _tz family would be more >> trouble than it’s worth, given the need for deprecations, migration paths, >> etc. If we were design

Re: Backward movement of confirmed_flush resulting in data duplication.

On Wed, May 14, 2025 at 9:16 AM Amit Kapila wrote: > > On Tue, May 13, 2025 at 4:22 PM Dilip Kumar wrote: > > > > On Tue, May 13, 2025 at 3:48 PM shveta malik wrote: > > > > > > Hi All, > > > > > > It is a spin-off thread from earlier discussions at [1] and [2]. > > > > > > While analyzing the s

Re: Incremental Sort Cost Estimation Instability

On 9/12/24 16:57, Tomas Vondra wrote: On 9/12/24 12:12, David Rowley wrote: On Thu, 12 Sept 2024 at 21:51, Andrei Lepikhov wrote: Initial problem causes wrong cost_sort estimation. Right now I think about providing cost_sort() the sort clauses instead of (or in addition to) the pathkeys. I'm

vectorized CRC on ARM64

We did something similar for x86 for v18, and here is some progress towards Arm support. 0001: Like e2809e3a101 -- inline small constant inputs to compensate for the fact that 0002 will do a runtime check even if the usual CRC extension is targeted. There is a difference from x86, however: On Arm

Re: Backward movement of confirmed_flush resulting in data duplication.

On Wed, May 14, 2025 at 12:15 PM Amit Kapila wrote: > > On Wed, May 14, 2025 at 11:59 AM Dilip Kumar wrote: > > > > On Wed, May 14, 2025 at 9:16 AM Amit Kapila wrote: > > > > > > On Tue, May 13, 2025 at 4:22 PM Dilip Kumar wrote: > > > > > > > > On Tue, May 13, 2025 at 3:48 PM shveta malik >

Re: Small fixes needed by high-availability tools

On Wed, May 14, 2025 at 2:15 AM Mihail Nikalayeu wrote: > > > One idea to solve this problem could be that whenever we cancel > > sync_rep_wait, we set some system-wide flag that indicates that any > > new transaction must ensure that all the current data is replicated to > > the synchronous stand

Re: Suggestion to add --continue-client-on-abort option to pgbench

Hi, On Tue, May 13, 2025 at 11:27 AM Dilip Kumar wrote: > On Tue, May 13, 2025 at 9:20 AM wrote: > > I also appreciate you for pointing out my mistakes in the previous > version of the patch. I fixed the duplicated lines. I’ve attached the > updated patch. > > > This is a useful feature, so +1

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

On Mon, Apr 28, 2025 at 4:40 PM Álvaro Herrera wrote: > > On 2025-Apr-28, jian he wrote: > > > for tests, just found out i can imitate > > src/test/modules/test_misc/t/001_constraint_validation.pl, > > > > So I created a file: > > src/test/modules/test_misc/t/008_indexscan_validate_notnull.pl > >

Re: Vacuum statistics

On Tue, May 13, 2025 at 3:19 PM Alena Rybakina wrote: > > On 12.05.2025 08:30, Amit Kapila wrote: > > On Fri, May 9, 2025 at 5:34 PM Alena Rybakina > > wrote: > >> I did a rebase and finished the part with storing statistics separately > >> from the relation statistics - now it is possible to d

Re: Disable parallel query by default

On Tue, 2025-05-13 at 17:53 -0400, Scott Mead wrote: > On Tue, May 13, 2025, at 5:07 PM, Greg Sabino Mullane wrote: > > On Tue, May 13, 2025 at 4:37 PM Scott Mead wrote: > > > I'll open by proposing that we prevent the planner from automatically > > > selecting parallel plans by default > > > > T

Re: Assert failure in base_yyparse

On Fri, May 9, 2025 at 6:50 PM Alvaro Herrera wrote: > I agree that blocking the index from using the option name that xmltable > parsing uses internally is okay. Maybe we can rename it to something > like "__pg__is_not_null" or something like that, which would reduce the > chances of troubling p

Re: Allow reading LSN written by walreciever, but not flushed yet

On Mon, 12 May 2025 at 17:48, Andrey Borodin wrote: > Done so. Thanks! TBH, the current function name pg_last_wal_receive_lsn() is confusing, and introducing a new one pg_last_wal_receive_unflushed_lsn() doesn't make it better :( What about actually adding TWO new functions, pg_last_wal_write_l