Re: Missing NULL check after calling ecpg_strdup

On Wed, Jul 16, 2025 at 02:04:12PM +0300, Aleksander Alekseev wrote: > Hi Michael, > > > depending on what's set in a URI. I think that we need to redesign a > > bit ecpg_strdup(), perhaps by providing an extra input argument so as > > we can detect hard failures on OOM and let ECPGconnect() retu

Re: Collation and primary keys

On Wed, 2025-07-16 at 09:46 -0700, Jeff Davis wrote: > On Wed, 2025-07-16 at 08:29 +0200, Laurenz Albe wrote: > > I have a radical proposal: Rather than having "initdb" default to > > whatever locale is in the environment, make it default the the > > builtin provider and the C collation.  Wherever

Re: 024_add_drop_pub.pl might fail due to deadlock

On Wed, Jul 16, 2025 at 8:38 AM Ajin Cherian wrote: > > Thanks for the test and confirming the fix. Fixed the comments. > * origin. So passing missing_ok = true. + * + * Also lock SubscriptionRelationId with AccessShareLock to + * prevent any deadlocks with the us

Re: Fix PQport to never return NULL if the connection is valid

On Wed, 2025-07-16 at 15:36 -0400, Tom Lane wrote: > Laurenz Albe writes: > > On Thu, 2025-05-08 at 22:01 +0200, Daniele Varrazzo wrote: > > > Please find attached a new patch that doesn't change the behaviour and > > > just makes sure to not return NULL in case no info is available in > > > 'conn

Re: duplicate line in ExecEvalJsonCoercionFinish

On Thu, Jul 17, 2025 at 12:03 PM Amit Langote wrote: > On Thu, Jul 17, 2025 at 10:01 AM Richard Guo wrote: > > On Thu, Jul 17, 2025 at 9:52 AM Tender Wang wrote: > > > jian he 于2025年7月17日周四 07:39写道： > > >> ExecEvalJsonCoercionFinish duplicate line: > > >> jsestate->escontext.error_occur

Re: Log prefix missing for subscriber log messages received from publisher

Hi, Shouldn't we be using a notice receiver rather than a notice processor? -- Álvaro Herrera

Re: IndexAmRoutine aminsertcleanup function can be NULL?

On Wed, 16 Jul 2025 at 10:08, Peter Smith wrote: > Hi hackers. > > I happened to notice that many contrib module indexes do not implement > an aminsertcleanup function: > e.g. amroutine->aminsertcleanup = NULL; > > But, unlike many of the other interface functions, the aminsertcleanup > does not s

Re: Log prefix missing for subscriber log messages received from publisher

On Wed, 16 Jul 2025 at 21:30, Fujii Masao wrote: > > > > On 2025/07/16 19:45, vignesh C wrote: > > If we don't trim the trailing newline, an extra blank line will appear > > after the message is printed, like this: > > 2025-07-16 12:44:20.076 IST [534376] LOG: logical replication table > > synchr

Re: ZStandard (with dictionaries) compression support for TOAST compression

On Tue, Jul 15, 2025 at 10:37:02PM -0700, Nikhil Kumar Veldanda wrote: > 0001 – pg_compression_available() > pg_compression_available() in misc.c feels sensible; Actually, I have taken a step back on this one and recalled that the list of values available for an enum GUC are already available in p

Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

On Fri, 4 Jul 2025 14:58:05 +0900 Yugo Nagata wrote: > On Fri, 4 Jul 2025 10:48:26 +0700 > Daniil Davydov <3daniss...@gmail.com> wrote: > > > Hi, > > > > On Thu, Jul 3, 2025 at 9:18 PM Yugo Nagata wrote: > > > > > > On Tue, 1 Jul 2025 18:56:11 +0700 > > > Daniil Davydov <3daniss...@gmail.com>

Re: query_id: jumble names of temp tables for better pg_stat_statement UX

On Tue, Jul 15, 2025 at 11:20 PM Alexander Kukushkin wrote: > However, we regularly hear from many different customers that they *don't > control queries* sent by application or *can't modify these queries*. > Such kinds of workloads are also not that uncommon and this change makes > it impossibl

Re: Conflict detection for update_deleted in logical replication

On Fri, Jul 11, 2025 at 4:28 PM Amit Kapila wrote: > > On Thu, Jul 10, 2025 at 6:46 PM Masahiko Sawada wrote: > > > > On Wed, Jul 9, 2025 at 9:09 PM Amit Kapila wrote: > > > > > > > > > I think that even with retain_conflict_info = off, there is probably a > > > > point at which the subscriber c

Re: Improve pg_sync_replication_slots() to wait for primary to advance

On Wed, Jul 16, 2025 at 3:47 PM Ajin Cherian wrote: > > > I am not able to apply the patch to the latest head or even to a week > > back version. Can you please check and rebase? > > > > thanks > > Shveta > > Rebased. > Thanks. Please find a few comments: 1) /* Any slot with NULL in these field

Re: duplicate line in ExecEvalJsonCoercionFinish

On Thu, Jul 17, 2025 at 10:01 AM Richard Guo wrote: > On Thu, Jul 17, 2025 at 9:52 AM Tender Wang wrote: > > jian he 于2025年7月17日周四 07:39写道： > >> ExecEvalJsonCoercionFinish duplicate line: > >> jsestate->escontext.error_occurred = false; > >> jsestate->escontext.error_occurred = f

Re: simple patch for discussion

On Thu, 17 Jul 2025 at 12:44, Greg Hennessy wrote: > workers, but there isn't an easy way to get more > workers. Is "alter table ... set (parallel_workers=N);" not easy enough? David

Re: psql: tab-completion support for COPY ... TO/FROM STDIN, STDOUT, and PROGRAM

On Tue, 17 Jun 2025 00:08:32 +0900 Yugo Nagata wrote: > On Thu, 5 Jun 2025 16:52:00 +0900 > Yugo Nagata wrote: > > > On Thu, 5 Jun 2025 10:08:35 +0900 > > Yugo Nagata wrote: > > > > > Hi, > > > > > > Currently, tab completion for COPY only suggests filenames after TO or > > > FROM, even thou

Re: duplicate line in ExecEvalJsonCoercionFinish

On Thu, Jul 17, 2025 at 9:52 AM Tender Wang wrote: > jian he 于2025年7月17日周四 07:39写道： >> ExecEvalJsonCoercionFinish duplicate line: >> jsestate->escontext.error_occurred = false; >> jsestate->escontext.error_occurred = false; > Good catch. It was introduced by this commit 231b7d67

Re: duplicate line in ExecEvalJsonCoercionFinish

jian he 于2025年7月17日周四 07:39写道： > hi. > > ExecEvalJsonCoercionFinish duplicate line: > jsestate->escontext.error_occurred = false; > jsestate->escontext.error_occurred = false; > > > https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/executor/execExprInterp.c#n5230 G

Re: Fix lwlock.c and wait_event_names.txt discrepancy

On Wed, Jul 16, 2025 at 11:41:09AM +, Bertrand Drouvot wrote: > On Wed, Jul 16, 2025 at 01:33:07PM +0200, Álvaro Herrera wrote: >> I don't. These names are unlikely to be anywhere other than in the >> output of queries for any length of time, so if we change them now, >> nothing will break per

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Hi, On 2025-02-28 23:45:58 -0800, Lukas Fittl wrote: > From what I can gather, it appears this was an oversight when David first > reapplied the work on the instr_time changes that were committed. Heh, glad that that's now fixed. Unfortunately the patch needs an update, primarily because of the

simple patch for discussion

This is my first attempt for a patch to postgresql, please forgive me if I have forgotten some step. I recently got a new system, with many more CPU cores than previous systems than I am used to, 128 cores (which may not seem a large number to some). I was a bit unhappy that even though I conf

Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available

Hi, On 2025-07-16 18:24:33 -0400, Tom Lane wrote: > ... BTW, another resource worth looking at is src/bin/pg_test_timing/ > which we just improved a few days ago [1]. What I see on two different > Linux-on-Intel boxes is that the loop time that that reports is 16 ns > and change, and the clock re

Re: Improve error reporting in 027_stream_regress test

On Wed, Jul 16, 2025 at 02:32:53PM +0300, Nazir Bilal Yavuz wrote: > On Wed, 16 Jul 2025 at 04:39, Michael Paquier wrote: >> Hmm. Is that actually useful as we know that the standby has been >> stalen down when running the test? Even if we report something, we >> could always trim the output, li

Re: track generic and custom plans in pg_stat_statements

> > Ugh. This is plugging into an executor-related structure a completely > > different layer, so that looks like an invasive layer violation to > > me.. This is passed through ProcessQuery() from a Portal, changing > > while on it ExplainOnePlan. If we want to get access from a cached > > plan,

duplicate line in ExecEvalJsonCoercionFinish

hi. ExecEvalJsonCoercionFinish duplicate line: jsestate->escontext.error_occurred = false; jsestate->escontext.error_occurred = false; https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/executor/execExprInterp.c#n5230

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

Hi, On 2025-07-16 15:25:14 -0700, Jacob Champion wrote: > On Wed, Jul 16, 2025 at 2:34 PM Andres Freund wrote: > > > Based on my understanding of [1], readahead makes this overall problem > > > much worse by opportunistically slurping bytes off the wire and doing > > > absolutely nothing with the

Re: Improve LWLock tranche name visibility across backends

> > Hi, > > > > If a dshash table is used to store tranche names and IDs, where would the > > tranche name for this table > > be registered? > > I guess it could be a new BuiltinTrancheId for this dsa but not sure what > Nathan > and Sami have in mind. Yes, it will be a BuiltinTrancheId for a sha

Re: track generic and custom plans in pg_stat_statements

> this for better tracking. By adding a CachedPlanSource::cplan link, we > can establish a connection to the entire PlanCache entry instead of only > CachedPlan within a queryDesc and, consequently, make it accessible from > the executor. This would give an access to statistics on costs and the > n

Re: track generic and custom plans in pg_stat_statements

> Ugh. This is plugging into an executor-related structure a completely > different layer, so that looks like an invasive layer violation to > me.. This is passed through ProcessQuery() from a Portal, changing > while on it ExplainOnePlan. If we want to get access from a cached > plan, wouldn't

Re: index prefetching

On Wed, Jul 16, 2025 at 6:18 PM Andres Freund wrote: > There's no problem today - the indexams never use the tids to look up blocks > themselves. They're always passed to the tableam to do so (via > table_index_fetch_tuple() etc). I.e. the translation from TIDs to specific > blocks & buffers happe

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

On Wed, Jul 16, 2025 at 2:34 PM Andres Freund wrote: > > Based on my understanding of [1], readahead makes this overall problem > > much worse by opportunistically slurping bytes off the wire and doing > > absolutely nothing with them until you call SSL_read() enough times to > > finally get to th

Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available

... BTW, another resource worth looking at is src/bin/pg_test_timing/ which we just improved a few days ago [1]. What I see on two different Linux-on-Intel boxes is that the loop time that that reports is 16 ns and change, and the clock readings appear accurate to full nanosecond precision. Chang

Re: index prefetching

Hi, On 2025-07-16 17:47:53 -0400, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 5:41 PM Andres Freund wrote: > > I don't mean the index tids, but how the read stream is fed block numbers. > > In > > the "complex" patch that's done by index_scan_stream_read_next(). And the > > block number it

Re: index prefetching

On Wed, Jul 16, 2025 at 5:41 PM Andres Freund wrote: > I don't mean the index tids, but how the read stream is fed block numbers. In > the "complex" patch that's done by index_scan_stream_read_next(). And the > block number it returns is simply > > return ItemPointerGetBlockNumber(tid); > >

Re: small fix for pg_overexplain docs

On Wed, 16 Jul 2025 at 22:22, Nathan Bossart wrote: > > Okay, here is a new version of the patch. > LGTM. Regards, Dean

Re: index prefetching

Hi, On 2025-07-16 17:27:23 -0400, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 4:46 PM Andres Freund wrote: > > Maybe I'm missing something, but the current interface doesn't seem to work > > for AMs that don't have a 1:1 mapping between the block number portion of > > the > > tid and the ac

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

Hi, On 2025-07-16 11:50:46 -0700, Jacob Champion wrote: > On Wed, Jul 16, 2025 at 11:11 AM Andres Freund wrote: > > If one modifies libpq to use openssl readahead (which does result in > > speedups, > > because otherwise openssl think it's useful to do lots of 5 byte reads from > > the socket),

Re: Returning nbtree posting list TIDs in DESC order during backwards scans

Hi, -    for (int i = 0; i < numKilled; i++) +    for (int i = so->currPos.firstItem; i <= so->currPos.lastItem; i++) Does the above change mean it will have to do more work in the loop? Whereas before it visited strictly killed, it now has to go through all of them? Kind regards, Mirce

Re: index prefetching

On Wed, Jul 16, 2025 at 4:46 PM Andres Freund wrote: > Maybe I'm missing something, but the current interface doesn't seem to work > for AMs that don't have a 1:1 mapping between the block number portion of the > tid and the actual block number? I'm not completely sure what you mean here. Even w

Re: [PATCH] avoid double scanning in function byteain

Peter Eisentraut writes: > The relationship between patch 0001 and 0002 is unclear to me. Are > these incremental or alternatives? The description doesn't make this clear. It appears to me that 0002 is actually counterproductive. I cannot see a reason to get a StringInfo involved here: it add

Re: small fix for pg_overexplain docs

On Wed, Jul 16, 2025 at 07:45:05PM +0100, Dean Rasheed wrote: > Maybe. It's kind-of annoying that all the modules that aren't > extensions use different text. Maybe there are genuine differences -- > I didn't look too closely. It would be nice if we just had one > standard description that they all

Re: index prefetching

Hi, On 2025-07-16 16:54:06 -0400, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 3:40 PM Andres Freund wrote: > > As a first thing I just wanted to get a feel for the improvements we can > > get. > > I had a scale 5 tpch already loaded, so I ran a bogus query on that to see. > > Cool. > > >

Re: index prefetching

On Wed, Jul 16, 2025 at 4:46 PM Andres Freund wrote: > Currently the API wouldn't easily allow the table AM to do batched TID lookups > - if you have a query that looks at a lot of table tuples in the same buffer > consecutively, we spend a lot of time locking/unlocking said buffer. We also > spe

Re: index prefetching

On 7/16/25 19:56, Tomas Vondra wrote: > On 7/16/25 18:39, Peter Geoghegan wrote: >> On Wed, Jul 16, 2025 at 11:29 AM Peter Geoghegan wrote: >>> For example, with "linear_10 / eic=16 / sync", it looks like "complex" >>> has about half the latency of "simple" in tests where selectivity is >>> 10.

Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available

Jianghua Yang writes: > By using CLOCK_MONOTONIC_COARSE, which has lower overhead compared to > CLOCK_MONOTONIC, the patch improves the efficiency of timing > collection in EXPLAIN > ANALYZE. While it may slightly reduce precision, the resulting measurements > more closely reflect actual elapsed t

Re: index prefetching

On Wed, Jul 16, 2025 at 3:40 PM Andres Freund wrote: > As a first thing I just wanted to get a feel for the improvements we can get. > I had a scale 5 tpch already loaded, so I ran a bogus query on that to see. Cool. > Test: > > Peter's: To be clear, the "complex" patch is still almost all Toma

Re: index prefetching

Hi, On 2025-07-16 15:39:58 -0400, Andres Freund wrote: > Looking at the actual patches now. I just did an initial, not particularly in depth look. A few comments and questions below. For either patch, I think it's high time we split the index/table buffer stats in index scans. It's really ann

Re: Composite types for updatable views

Hi , Yes, i agree with the statement below , a column is updatable if it is a simple reference to an updatable column of the underlying base relation . View updatability for composite types (being derived construct) will pose challenges Possible temporary work around is: 1. Avoid

Re: index prefetching

Hi, On 2025-07-16 14:30:05 -0400, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 2:27 PM Andres Freund wrote: > > Could you share the current version of the complex patch (happy with a git > > tree)? Afaict it hasn't been posted, which makes this pretty hard follow > > along > > / provide feed

Re: Fix PQport to never return NULL if the connection is valid

Laurenz Albe writes: > On Thu, 2025-05-08 at 22:01 +0200, Daniele Varrazzo wrote: >> Please find attached a new patch that doesn't change the behaviour and >> just makes sure to not return NULL in case no info is available in >> 'conn->connhost'. > I think that it is important to fix that bug and

Re: [PATCH] Add tests for binaryheap.c

On Fri, Jun 27, 2025 at 02:02:22PM +0300, Aleksander Alekseev wrote: >> I'm not sure I see much point in testing both min-heaps and max-heaps. The >> only difference between the two is in the comparator, so IMHO the extra >> tests really only serve to test the test comparator. > > Make sense. Her

Re: index prefetching

On Wed, Jul 16, 2025 at 3:00 PM Tomas Vondra wrote: > Yes, sounds like a fair summary. Cool. > Perhaps, although I don't quite see why the simpler patch couldn't > address some of those problems (within the limit of a single leaf page, > of course). I don't think there's anything that's prevent

Re: index prefetching

On 7/16/25 20:18, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 1:42 PM Tomas Vondra wrote: >> On 7/16/25 16:45, Peter Geoghegan wrote: >>> I get that index characteristics could be the limiting factor, >>> especially in a world where we're not yet eagerly reading leaf pages. >>> But that in

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

On Wed, Jul 16, 2025 at 11:11 AM Andres Freund wrote: > If one modifies libpq to use openssl readahead (which does result in speedups, > because otherwise openssl think it's useful to do lots of 5 byte reads from > the socket), I see occasional hangs in libpq. Now that is a very interesting coinc

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

On Wed, Jul 16, 2025 at 7:36 AM Merlin Moncure wrote: > Agreed. Here's a little more detail on the case I noticed: > > * postgres backend thread managing several libpq connections, with polling > is_busy loop > * when client pushed a lot of log messages (say, with 'RAISE NOTICE'), the > server w

Re: small fix for pg_overexplain docs

On Wed, 16 Jul 2025 at 18:26, Nathan Bossart wrote: > > On Tue, Jul 15, 2025 at 04:14:44PM +0100, Dean Rasheed wrote: > > On Tue, 15 Jul 2025 at 04:17, Robert Treat wrote: > >> On Mon, Jul 14, 2025 at 3:22 PM David G. Johnston > >> > The pg_overexplain extends EXPLAIN with new options that provid

Re: index prefetching

On Wed, Jul 16, 2025 at 2:27 PM Andres Freund wrote: > Could you share the current version of the complex patch (happy with a git > tree)? Afaict it hasn't been posted, which makes this pretty hard follow along > / provide feedback on, for others. Sure: https://github.com/petergeoghegan/postgres

Re: index prefetching

Hi, On 2025-07-16 14:18:54 -0400, Peter Geoghegan wrote: > I don't fully understand why this appears to be less of a problem with > the complex patch. Can you help me to confirm my understanding? Could you share the current version of the complex patch (happy with a git tree)? Afaict it hasn't be

Re: Improving and extending int128.h to more of numeric.c

On Wed, 16 Jul 2025 at 10:02, John Naylor wrote: > > On Mon, Jun 23, 2025 at 3:01 PM Dean Rasheed wrote: > > 0005 is the main patch. It adds a few more functions to int128.h and > > uses them in numeric.c to allow various functions (mainly aggregate > > functions) to use 128-bit integers uncondit

Re: index prefetching

On Wed, Jul 16, 2025 at 1:42 PM Tomas Vondra wrote: > On 7/16/25 16:45, Peter Geoghegan wrote: > > I get that index characteristics could be the limiting factor, > > especially in a world where we're not yet eagerly reading leaf pages. > > But that in no way justifies just forgetting about prefetc

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

Hi, On 2025-07-15 15:31:25 -0700, Jacob Champion wrote: > So I think pqReadData() needs to make the same guarantees for SSL/GSS > that it does for plain TCP: when it returns, either 1) there are no > bytes left pending or 2) the socket itself is marked readable. > Otherwise I think we'll continue

Re: index prefetching

On 7/16/25 18:39, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 11:29 AM Peter Geoghegan wrote: >> For example, with "linear_10 / eic=16 / sync", it looks like "complex" >> has about half the latency of "simple" in tests where selectivity is >> 10. The advantage for "complex" is even greater at

Re: index prefetching

On 7/16/25 17:29, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 4:40 AM Tomas Vondra wrote: >> For "uniform" data set, both prefetch patches do much better than master >> (for low selectivities it's clearer in the log-scale chart). The >> "complex" prefetch patch appears to have a bit of an

Re: index prefetching

On 7/16/25 16:45, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 10:37 AM Tomas Vondra wrote: >> What sounds weird? That the read_stream works like a stream of blocks, >> or that it can't do "pause" and we use "reset" as a workaround? > > The fact that prefetch distance is in any way affected b

Fix tab completion in v18 for ALTER DATABASE/USER/ROLE ... RESET

Hi hackers, These two patches are split out from my earlier thread about improving tab completion for varous RESET forms (https://postgr.es/m/87bjqwwtic@wibble.ilmari.org), so that the bug fixes can be tracked as an open item for v18. Commits 9df8727c5067 and c407d5426b87 added tab completion

Re: small fix for pg_overexplain docs

On Tue, Jul 15, 2025 at 04:14:44PM +0100, Dean Rasheed wrote: > On Tue, 15 Jul 2025 at 04:17, Robert Treat wrote: >> On Mon, Jul 14, 2025 at 3:22 PM David G. Johnston >> > The pg_overexplain extends EXPLAIN with new options that provide... >> > Suggest instead: >> > The pg_overexplain module provi

Re: Saving stack space in nbtree's _bt_first function

On Wed, Jul 16, 2025 at 9:17 AM Mircea Cadariu wrote: > Thanks for the elaboration and updated patch! Indeed, I see it's set in > the ScanKeyEntryInitialize to either BTGreaterStrategyNumber or > BTLessStrategyNumber, then few lines lower there's the if with the break. > > I'm convinced. Pushed.

Re: pg_dumpall dumps global objects with --statistics-only or --no-schema

On Mon, 2025-06-30 at 16:44 -0400, Corey Huinker wrote: > > > > Since pg_dumpall treats global objects as schema-level content, it > > currently > > includes them with --schema-only but skips them with --data-only. > > By that logic, > > it should also skip them when either --statistics-only or --

Re: fix organization wording in psql's \copyright command

Committed. Thanks for the prompt reviews. On Tue, Jul 15, 2025 at 12:29:32AM +0200, Daniel Gustafsson wrote: >> On 15 Jul 2025, at 00:07, Tom Lane wrote: >> I wonder if we missed any other places ... grepping for >> "Postgres95" didn't find any, but ... > > Grepping around with a bit of fuzzy m

Re: Collation and primary keys

On Wed, 2025-07-16 at 08:29 +0200, Laurenz Albe wrote: > I have a radical proposal: Rather than having "initdb" default to > whatever locale is in the environment, make it default the the > builtin > provider and the C collation.  Wherever people need a natural > language > collation, they can say

Re: index prefetching

On Wed, Jul 16, 2025 at 11:29 AM Peter Geoghegan wrote: > For example, with "linear_10 / eic=16 / sync", it looks like "complex" > has about half the latency of "simple" in tests where selectivity is > 10. The advantage for "complex" is even greater at higher > "selectivity" values. All of the oth

Re: Explicitly enable meson features in CI

Hi, On 2025-07-16 14:12:22 +0300, Nazir Bilal Yavuz wrote: > On Fri, 11 Jul 2025 at 14:00, Nazir Bilal Yavuz wrote: > > On Thu, 10 Jul 2025 at 20:12, Jacob Champion > > wrote: > > > > > > On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz > > > wrote: > > > > Andres off-list mentioned that if w

Re: Log prefix missing for subscriber log messages received from publisher

On 2025/07/16 19:45, vignesh C wrote: If we don't trim the trailing newline, an extra blank line will appear after the message is printed, like this: 2025-07-16 12:44:20.076 IST [534376] LOG: logical replication table synchronization worker for subscription "sub1", table "t2" has started 2025

Re: Add progressive backoff to XactLockTableWait functions

Hi all, I spent some extra time walking the code to see where XactLockTableWait() actually fires. A condensed recap: 1) Current call-paths A. Logical walsender (XLogSendLogical → … → SnapBuildWaitSnapshot) in cascading standby B. SQL slot functions (pg_logical_slot_get_changes[_peek]) create_lo

Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)

Hi, On 2025-07-16 18:27:45 +0300, Yura Sokolov wrote: > 16.07.2025 17:58, Andres Freund пишет: > >> Now, if I simply remove the spinlock in SIGetDataEntries, I see a drop of > >> just ~6% under concurrent DDL. I think this strongly suggests that the > >> spinlock is the bottleneck. > > > > This c

Re: Changing shared_buffers without restart

Hi, On 2025-07-14 17:55:13 -0500, Jim Nasby wrote: > I say that because unless you're running a workload that entirely fits in > shared buffers, or a *really* small shared buffers compared to system > memory, increasing shared buffers quickly gets into diminishing returns. I don't think that's tr

Re: Fix PQport to never return NULL if the connection is valid

On Thu, 2025-05-08 at 22:01 +0200, Daniele Varrazzo wrote: > I looked a bit more into the meaning of the port="" setting. The docs > for the port parameter / PGPORT env var > > say: > > An empty string, or an empty

Re: index prefetching

On Wed, Jul 16, 2025 at 4:40 AM Tomas Vondra wrote: > For "uniform" data set, both prefetch patches do much better than master > (for low selectivities it's clearer in the log-scale chart). The > "complex" prefetch patch appears to have a bit of an edge for >1% > selectivities. I find this a bit s

Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)

16.07.2025 17:58, Andres Freund пишет: > Hi, > > On 2025-06-25 16:41:46 +0300, Sergey Shinderuk wrote: >> On 16.06.2025 17:41, Andres Freund wrote: >>> TBH, I don't see a point in continuing with this thread without something >>> that >>> others can test. I rather doubt that the right fix here i

Re: wrong sequence value in dump file

Ok, effectively the dump comes from a standby. Thanks for your explanation. Best regards, Fabrice On Wed, Jul 16, 2025 at 5:06 PM Tom Lane wrote: > Fabrice Chapuis writes: > > When dumping with pg_dump and the directory option, I got a sequence > value > > that is greater in the dump file tha

Re: Explicitly enable meson features in CI

On Wed, Jul 16, 2025 at 4:12 AM Nazir Bilal Yavuz wrote: > > For me it looks like 'Meson Auto' can be confused with 'Autoconf'. We > > can rename it as a 'Meson Auto Feature Detection' but that is a bit > > longer. Do you have any ideas? If you think 'Meson Auto' is good > > enough, we can continu

Re: wrong sequence value in dump file

Fabrice Chapuis writes: > When dumping with pg_dump and the directory option, I got a sequence value > that is greater in the dump file than the sequence in the source database. Perhaps you were dumping from a standby server? It's normal for a standby to show a value up to 32 counts more than th

Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)

Hi, On 2025-06-25 16:41:46 +0300, Sergey Shinderuk wrote: > On 16.06.2025 17:41, Andres Freund wrote: > > TBH, I don't see a point in continuing with this thread without something > > that > > others can test. I rather doubt that the right fix here is to just change > > the > > lock model over,

Re: Changing shared_buffers without restart

> On Mon, Jul 14, 2025 at 05:55:13PM -0500, Jim Nasby wrote: > > Finally, while shared buffers is the most visible target here, there are > other shared memory settings that have a *much* smaller surface area, and > in my experience are going to be much more valuable from a tuning > perspective; no

wrong sequence value in dump file

Hi, When dumping with pg_dump and the directory option, I got a sequence value that is greater in the dump file than the sequence in the source database. The sequence is defined as: CREATE SEQUENCE id_seq_test INCREMENT BY 1 MINVALUE 1 MAXVALUE 190 START 1000 CACHE 1

Re: Changing shared_buffers without restart

> On Tue, Jul 15, 2025 at 10:52:01PM +, Jack Ng wrote: > >> On Mon, Jul 14, 2025 at 03:18:10PM +, Jack Ng wrote: > >> Just brain-storming here... would moving NBuffers to shared memory solve > >this specific issue? Though I'm pretty sure that would open up a new set of > >synchronization is

Re: index prefetching

On Wed, Jul 16, 2025 at 10:37 AM Tomas Vondra wrote: > What sounds weird? That the read_stream works like a stream of blocks, > or that it can't do "pause" and we use "reset" as a workaround? The fact that prefetch distance is in any way affected by a temporary inability to return more blocks. Ju

Re: index prefetching

On 7/16/25 16:29, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 10:20 AM Tomas Vondra wrote: >> The read stream can only return blocks generated by the "next" callback. >> When we return the block for the last item on a leaf page, we can only >> return "InvalidBlockNumber" which means "no more

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

On Tue, Jul 15, 2025 at 4:31 PM Jacob Champion < jacob.champ...@enterprisedb.com> wrote > Otherwise I think we'll continue to chase weird corner cases. > Agreed. Here's a little more detail on the case I noticed: * postgres backend thread managing several libpq connections, with polling is_busy

Re: index prefetching

On Wed, Jul 16, 2025 at 10:20 AM Tomas Vondra wrote: > The read stream can only return blocks generated by the "next" callback. > When we return the block for the last item on a leaf page, we can only > return "InvalidBlockNumber" which means "no more blocks in the stream". > And once we advance t

Re: index prefetching

On Wed, Jul 16, 2025 at 10:25 AM Andres Freund wrote: > This imo isn't something worth optimizing for - if you use an io_method that > actually can execute IO asynchronously this issue does not exist, as the start > of the IO will already have populated the buffer entry (without BM_VALID set, > of

Re: index prefetching

Hi, On 2025-07-16 16:20:25 +0200, Tomas Vondra wrote: > On 7/16/25 16:07, Peter Geoghegan wrote: > >> Te pattern of fadvise+pread for the same block seems a bit silly. And > >> this is not just about "sync" method, the other methods will have a > >> similar issue with no starting the I/O earlier.

Re: index prefetching

On 7/16/25 16:07, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 9:58 AM Tomas Vondra wrote: >>> The "simple" patch has _bt_readpage reset the read stream. That >>> doesn't make any sense to me. Though it does explain why the "complex" >>> patch does so many more fadvise calls. >>> >> >> Why it

Re: index prefetching

On Wed, Jul 16, 2025 at 9:58 AM Tomas Vondra wrote: > > The "simple" patch has _bt_readpage reset the read stream. That > > doesn't make any sense to me. Though it does explain why the "complex" > > patch does so many more fadvise calls. > > > > Why it doesn't make sense? The reset_stream_reset()

Re: index prefetching

On 7/16/25 15:36, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 4:40 AM Tomas Vondra wrote: >> But the thing I don't really understand it the "cyclic" dataset (for >> example). And the "simple" patch performs really badly here. This data >> set is designed to not work for prefetching, it's p

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

On Wed, 16 Jul 2025 21:35:01 +0900 Rintaro Ikeda wrote: > Hi, > > On 2025/07/15 11:16, Yugo Nagata wrote: > >> I noticed one small thing I’d like to discuss. I'm not sure that users > >> clearly > >> understand which aborted in the following error message, the client or the > >> script. > >>>

Re: index prefetching

On Wed, Jul 16, 2025 at 9:36 AM Peter Geoghegan wrote: > Another issue with the "simple" patch: it adds 2 bool fields to > "BTScanPosItem". That increases its size considerably. We're very > sensitive to the size of this struct (I think that you know about this > already). Bloating it like this wi

Re: index prefetching

On Wed, Jul 16, 2025 at 4:40 AM Tomas Vondra wrote: > But the thing I don't really understand it the "cyclic" dataset (for > example). And the "simple" patch performs really badly here. This data > set is designed to not work for prefetching, it's pretty much an > adversary case. There's ~100 TIDs

Re: Saving stack space in nbtree's _bt_first function

On 16/07/2025 07:27, Peter Geoghegan wrote: [...] Rather, we rely on the generic logic that builds our startKeys[] entries. It will inevitably "break" before ever moving on to the next index attribute/next so->keyData[] key because strat_total will inevitably become BTGreaterStrategyNumber/BTLes

Re: track generic and custom plans in pg_stat_statements

On 6/30/25 13:45, Sami Imseih wrote: rebased patch. Only changes to the tests due to the revert of nested query tracking in f85f6ab051b Thank you for your efforts. I would like to share a few thoughts about this patch. First, I believe the 'status' field could be renamed to 'mode,' as it alig

  1   2   >