Re: Logical Replication of sequences

On Mon, Oct 20, 2025 at 5:29 PM Hayato Kuroda (Fujitsu) wrote: > > > Here is the latest patch set which addressed Shveta[1], Amit[2], Chao[3][4], > > Dilip[5], Sawada-San's[6] comments. > > I found the patch could not pass the sanity check, because 0001 missed a > comma. > Also, there was a dupli

Re: Speed up COPY FROM text/CSV parsing using SIMD

On Tue, Oct 21, 2025, 8:17 AM KAZAR Ayoub wrote: > > Currently we are at 200-400Mbps which isn't that terrible compared to > production and non production grade parsers (of course we don't only parse > in our case), also we are using SSE2 only so theoretically if we add > support for avx later on

Re: Speed up COPY FROM text/CSV parsing using SIMD

On Sat, Oct 18, 2025 at 10:01 PM Nazir Bilal Yavuz wrote: > Thank you so much for doing this! The results look nice, do you think > there are any other benchmarks that might be interesting to try? > > > I'm also trying the idea of doing SIMD inside quotes with prefix XOR > using carry less multi

Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array

Hi, Thanks for looking into this. On Tue, Oct 21, 2025 at 1:05 PM Kirill Reshke wrote: > > On Tue, 21 Oct 2025 at 04:31, Michael Paquier wrote: > > > > On Sat, Oct 18, 2025 at 01:59:40PM +0500, Kirill Reshke wrote: > > > Indeed, these changes look correct. > > > I wonder why b89e151054a0 did th

CREATE POLICY IF NOT EXISTS

hi. People have complained about the lack of CREATE POLICY IF NOT EXISTS syntax in [1]. The attached patch adds support for syntax "CREATE POLICY IF NOT EXISTS". [1] https://postgr.es/m/cwxp265mb500957dd1918490cd4ab439ef7...@cwxp265mb5009.gbrp265.prod.outlook.com From acaf26a8a89b61ab274647d99e3

Re: Extended Statistics set/restore/clear functions.

On Tue, Oct 21, 2025 at 02:48:37PM +0900, Michael Paquier wrote: > Tomas, what is your take about the format changes and my argument > about the backward requirements of pg_dump (about not dumping these > stats if connecting to a server older than v18, included)? By the way, the patch is still nee

Re: BRIN: Prevent the heapblk overflow during index summarization on very large tables resulting in an infinite loop

On Tue, Oct 21, 2025 at 06:32:01PM +1300, David Rowley wrote: > I'd leave it as uint64. There's no reason to mixup the signedness > between these two variables. That's fine as well. > I'm happy to finish this one off. I was leaving it for Tomas to > comment, but I think he'll be busy with pgconf.

Re: BRIN: Prevent the heapblk overflow during index summarization on very large tables resulting in an infinite loop

On Tue, 21 Oct 2025 at 15:55, Michael Paquier wrote: > Using signed or unsigned is not going to matter much at the end. We > would be far from the count even if the number is signed. I'd leave it as uint64. There's no reason to mixup the signedness between these two variables. > +* Sinc

Re: POC: enable logical decoding when wal_level = 'replica' without a server restart

Hi Sawada-San. Here are some mostly cosmetic review comments for patch v19 (excluding test code). == doc/src/sgml/logicaldecoding.sgml 1. + + If either condition is met, the operational WAL level becomes equivalent + to logical, which can be monitored through + parametr. +

Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

On Tue, Oct 21, 2025 at 1:18 PM Tom Lane wrote: > Richard Guo writes: > > Oops, I made a mistake in the test case for v18. Fixing it now… > Bleah. I pretty much don't ever commit things into back branches > without running regression tests there as well as in master. > Postgres is a moving tar

Re: Eliminating SPI / SQL from some RI triggers - take 3

Hi út 21. 10. 2025 v 6:07 odesílatel Amit Langote napsal: > On Thu, Apr 3, 2025 at 7:19 PM Amit Langote > wrote: > > On Fri, Dec 20, 2024 at 1:23 PM Amit Langote > wrote: > > > We discussed $subject at [1] and [2] and I'd like to continue that > > > work with the hope to commit some part of it

Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array

On Tue, 21 Oct 2025 at 04:31, Michael Paquier wrote: > > On Sat, Oct 18, 2025 at 01:59:40PM +0500, Kirill Reshke wrote: > > Indeed, these changes look correct. > > I wonder why b89e151054a0 did this place this way, hope we do not miss > > anything here. > > Perhaps a lack of time back in 2014? It

Re: Making pg_rewind faster

Hi John, On Tue, Oct 21, 2025 at 3:34 AM John H wrote: > > > 3) maybe we can improve the error messages for the > > last 2 checks in tap test, that because of this > > reason hence proven that the copy from source to > > target has been done. > > What are you thinking of? Something like the belo

Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

Richard Guo writes: > Oops, I made a mistake in the test case for v18. Fixing it now… Bleah. I pretty much don't ever commit things into back branches without running regression tests there as well as in master. Postgres is a moving target. regards, tom lane

Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

On Tue, Oct 21, 2025 at 12:58 PM Richard Guo wrote: > Cool! I've pushed and back-patched v5. Thanks for working on this > patch. Oops, I made a mistake in the test case for v18. Fixing it now… - Richard

Re: Eliminating SPI / SQL from some RI triggers - take 3

On Thu, Apr 3, 2025 at 7:19 PM Amit Langote wrote: > On Fri, Dec 20, 2024 at 1:23 PM Amit Langote wrote: > > We discussed $subject at [1] and [2] and I'd like to continue that > > work with the hope to commit some part of it for v18. > > I did not get a chance to do any further work on this in th

Re: Logical Replication of sequences

On Mon, Oct 20, 2025 at 5:29 PM Hayato Kuroda (Fujitsu) wrote: > > > Here is the latest patch set which addressed Shveta[1], Amit[2], Chao[3][4], > > Dilip[5], Sawada-San's[6] comments. > > I found the patch could not pass the sanity check, because 0001 missed a > comma. > Also, there was a dupli

Re: remove unnecessary include in src/backend/commands/policy.c

On Wed, Oct 15, 2025 at 1:44 PM Shinya Kato wrote: > > On Sun, Oct 12, 2025 at 5:31 PM Álvaro Herrera wrote: > > > > On 2025-Sep-30, Shinya Kato wrote: > > > > > However, the changes make policy.c rely on transitive includes. For > > > example, policy.c uses GETSTRUCT(), which is defined in > > >

Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

On Tue, Oct 21, 2025 at 12:26 PM Tom Lane wrote: > Richard Guo writes: > > Regarding the tests, I think we could add another test query to cover > > the case with no empty grouping sets and degenerate HAVING clauses. > > This way, all cases for the HAVING pushdown optimization with grouping > > s

Re: Add \pset options for boolean value display

"David G. Johnston" writes: > On Monday, October 20, 2025, David G. Johnston > wrote: >> Sympathetic to the concern but opposed to taking on such responsibility. >> They could probably modify their own query to do that if they really wanted >> to fool someone and I’m having trouble accepting this

Re: Proposal for enabling auto-vectorization for checksum calculations

On Fri, Oct 17, 2025 at 2:15 PM Andrew Kim wrote: > > Hi John, > > Thank you for your detailed and constructive feedback on the checksum > AVX2 optimization patch. > I've carefully addressed all of your concerns and am pleased to share > the updated V6 implementation. Great! I know we're on v7 no

Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

Richard Guo writes: > Regarding the tests, I think we could add another test query to cover > the case with no empty grouping sets and degenerate HAVING clauses. > This way, all cases for the HAVING pushdown optimization with grouping > sets should be covered. > I've added such a test in v5, alon

Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

On Tue, Oct 21, 2025 at 1:27 AM Tom Lane wrote: > I wrote: > > I like the concept here, but not so much the details. Pulling > > expand_grouping_sets out of preprocess_grouping_sets feels weird. > > I guess it's all right given that preprocess_grouping_sets doesn't > > manipulate the parse tree o

Re: BRIN: Prevent the heapblk overflow during index summarization on very large tables resulting in an infinite loop

On Mon, Oct 20, 2025 at 03:11:01PM +0530, sunil s wrote: > Thanks, David, for providing feedback on the changes. > I’ve addressed your comments and attached a rebased patch. Using signed or unsigned is not going to matter much at the end. We would be far from the count even if the number is signe

Re: Add \pset options for boolean value display

> On Oct 21, 2025, at 10:29, David G. Johnston > wrote: > > They could probably modify their own query to do that if they really wanted > to fool someone and I’m having trouble accepting this happening by accident. If they modify queries, the result can visibly correlate to the query, for

Re: Add \pset options for boolean value display

On Monday, October 20, 2025, David G. Johnston wrote: > On Monday, October 20, 2025, Chao Li wrote: > >> The other thing I am thinking is that, with this patch, users are allowed >> to display arbitrary strings for true/false, if a user mistakenly set >> display_true to f and display_false to t,

Re: Add \pset options for boolean value display

On Monday, October 20, 2025, Chao Li wrote: > The other thing I am thinking is that, with this patch, users are allowed > to display arbitrary strings for true/false, if a user mistakenly set > display_true to f and display_false to t, which will load to > misunderstanding. > Sympathetic to the

Re: [PATCH] Remove make_temptable_name_n()

Hi, On Thu, Oct 16, 2025 at 8:11 PM Aleksander Alekseev wrote: > > Hi Álvaro, > > Thanks for your feedback. > > > Hmm, but instead of keeping the comment about why this is bogus, why not > > just fix it and remove the comment? You could do something like > > > > nsp = get_namespace_name( .. ); >

Re: Add \pset options for boolean value display

> On Oct 21, 2025, at 04:51, David G. Johnston > wrote: > > On Monday, October 20, 2025, Álvaro Herrera wrote: > On 2025-Jun-24, David G. Johnston wrote: > > > v1, Ready aside from bike-shedding the name. > > Here's v2 after some kibitzing. What do you think? > > Thank you. Seems good f

Re: Skip unregistered custom kinds on stats load

On Mon, Oct 20, 2025 at 07:54:09PM -0500, Sami Imseih wrote: > The more worrying case is if the struct of this other kind has > the same length, and the data ends up being read back > into the wrong fields. More to the point. If I were to put defenses when reading back a stats file that includes

Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue

On Mon, Oct 20, 2025 at 5:37 AM Matheus Alcantara wrote: > > On Sat Oct 18, 2025 at 2:43 AM -03, Joel Jacobson wrote: > > On Fri, Oct 17, 2025, at 22:50, Arseniy Mukhin wrote: > > What a funny coincidence that the approach in this patch, > > has one similarity with the "Direct advancement" approac

Re: Skip unregistered custom kinds on stats load

I hit send too fast. Link [0] referenced above was just pointing out the part of the code that reads a chunk of data using the length of the kind entry. -- Sami

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

On Sun, Oct 19, 2025 at 10:12 PM Rintaro Ikeda wrote: > > Hi, > > On 2025/10/02 1:22, Fujii Masao wrote: > > Regarding 0002: > > > > - if (canRetryError(st->estatus)) > > + if (continue_on_error || canRetryError(st->estatus)) > > { > > if (verbose_errors) > > commandError(st, PQresultErrorMe

Re: Fix race condition in SSI when reading PredXact->SxactGlobalXmin

Hello! Josh Curtis : > This is definitely a bit more complex. It requires that SetNewSxactGlobalXmin > is never called when SxactGlobalXmin is invalid to prevent readers from > seeing an invalid transaction ID when they should see a valid one -- I think > this is the case now since before SetNe

Re: Skip unregistered custom kinds on stats load

> The fun does not stop there. This also means that the data tracked in > the file becomes incorrect if a server tries to reuse the same ID > across two restarts with a different kind attached to them. The point > is that giving up is kind of always the safest bet and acts as a > sanity measure,

Re: Fix lag columns in pg_stat_replication not advancing when replay LSN stalls

On Mon, Oct 20, 2025 at 1:45 PM Shinya Kato wrote: > > On Mon, Oct 20, 2025 at 10:17 AM Fujii Masao wrote: > > > > On Sun, Oct 19, 2025 at 2:04 AM Shinya Kato wrote: > > > Thank you for the patch. I have one comment. > > > > > > + if (lag_tracker->overflowed[head].lsn > lsn) > > > +

Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array

On Sat, Oct 18, 2025 at 01:59:40PM +0500, Kirill Reshke wrote: > Indeed, these changes look correct. > I wonder why b89e151054a0 did this place this way, hope we do not miss > anything here. Perhaps a lack of time back in 2014? It feels like an item where we would need to research a bit some of t

Re: Skip unregistered custom kinds on stats load

On Mon, Oct 20, 2025 at 01:39:37PM -0500, Sami Imseih wrote: > I think this can be better handled by tracking the lengths of the > kinds in the pgstat.stat file when saving, and re-reading the lengths > on startup. This would allow skipping past any unrecognized custom > data. We need to save the l

Re: [PATCH] Fix POSIX compliance in pgwin32_unsetenv()

On Sun, Oct 19, 2025 at 08:34:02PM -0500, Bryan Green wrote: > I have been going through all of the windows code line by line. That is how > I initially noticed this. I then wrote a program to exercise the code and > confirm the crash. I agree it should be backported. Applied down to v14. Note

Re: isolation tester limitation in case of multiple injection points in a single command

Hello, Michael! Michael Paquier : > Ah, OK. So you want to have one single command, still wait through > two injection points inside it. I am wondering about one thing: do > you really require that? Could it be simpler to have two > permutations, each one of them using one wait point to check y

Re: [PATCH v4] parallel pg_restore: avoid disk seeks when jumping short distance forward

Dimitrios Apostolou writes: > Thanks for the extensive testing! Did you see the same syscall pattern in > strace output, as I did? Yes, I did look at that, and it's the same as you saw: HEAD repeats read(4k) lseek(~128k forward) which is to be expected if we have to read data b

Re: Logical Replication of sequences

On Mon, Oct 20, 2025 at 4:59 AM Hayato Kuroda (Fujitsu) wrote: > > > Here is the latest patch set which addressed Shveta[1], Amit[2], Chao[3][4], > > Dilip[5], Sawada-San's[6] comments. > > I found the patch could not pass the sanity check, because 0001 missed a > comma. > Also, there was a dupli

Re: [PATCH v4] parallel pg_restore: avoid disk seeks when jumping short distance forward

I wrote: > So for me, the proposed patch actually makes it 2X slower. I went and tried this same test case on a 2024 Mac Mini M4 Pro. Cutting to the chase: HEAD: $ time pg_restore -f /dev/null -t zedtable bench1.dump real1m26.525s user0m0.364s sys 0m6.806s Patched: $ time pg_r

Re: [PATCH v4] parallel pg_restore: avoid disk seeks when jumping short distance forward

Thanks for the extensive testing! Did you see the same syscall pattern in strace output, as I did? If yes, then the only reason I can think of that excuses the regression with my patch is that the SATA interface was maxed out when reading sequentially, while the very short latency of SSDs guara

Re: Making pg_rewind faster

Hi Srinath, Thank you for the quick review! On Sat, Oct 18, 2025 at 9:05 AM Srinath Reddy Sadipiralla wrote: > ... > I agree with Robert here, and i think if we found > that the WAL filename is not valid after parsing > we can return something like FILE_CONTENT_INVALID_TYPE > in getFileContentTy

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

On Oct 20, 2025, at 22:14, Tom Lane wrote: > I do take your point that being able to find things before commit > is helpful. But I think the answer to that is to get this > general-purpose ABI check mechanism sufficiently well product-ized > that committers can run it locally if they choose. Id

Re: Fix race condition in SSI when reading PredXact->SxactGlobalXmin

To prevent it being lost forever - I registered commitfest entry for it: https://commitfest.postgresql.org/patch/6145/

Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward

Dimitrios Apostolou writes: > + /* Dump buffer if full */ > + if (nonecs->bufdata >= nonecs->buflen) > Shouldn't this be equality check instead: > if (nonecs->bufdata == nonecs->buflen) Old defensive-programming habit. The invariant we want to establish is that

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

On Oct 20, 2025, at 22:52, Nathan Bossart wrote: > Thanks. If baza's next run looks good, I'll proceed with committing. I suggest mentioning that new entries should be at the top, that the list should be in reverse chronological order. Otherwise this looks great, love seeing it! D signat

Re: [PATCH v4] parallel pg_restore: avoid disk seeks when jumping short distance forward

Dimitrios Apostolou writes: > Regarding the attached patch (rebased and edited commit message), it > basically replaces seek(up to 1MB forward) with read(). The 1MB number > comes a bit out of the top of my head. But tweaking it between 128KB and > 1MB wouldn't really change anything, given tha

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

On Oct 20, 2025, at 19:07, Tom Lane wrote: > Agreed, but let's get v18 in shape first. I imagine the back branches > will require some effort to fill in the correct reference commits. > I was expecting we'd commit initial values pointing at the .0 releases > and then seeing what the ABI checker

Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward

On Wednesday 2025-10-15 21:21, Tom Lane wrote: 0004 increases the row width in the existing test case that says it's trying to push more than DEFAULT_IO_BUFFER_SIZE through the compressors. While I agree with the premise, this solution is hugely expensive: it adds about 12% to the already-long

Re: Speed up COPY FROM text/CSV parsing using SIMD

Hi, On Mon, 20 Oct 2025 at 23:32, Andrew Dunstan wrote: > > > On 2025-10-20 Mo 1:04 PM, Nathan Bossart wrote: > > On Mon, Oct 20, 2025 at 10:02:23AM -0400, Andrew Dunstan wrote: > > On 2025-10-16 Th 10:29 AM, Nazir Bilal Yavuz wrote: > > With this heuristic the regression is limited by %2 in the

Re: Add \pset options for boolean value display

On 2025-Oct-20, David G. Johnston wrote: > Thank you. Seems good from a quick read. I’m regretting the choice of the > display_ prefix; is there any technical limitation or other opposition to > using just true and false? > > \pset true ‘true’ > \pset false ‘false’ > > To keep in line with: >

Can we make pg_strcasecmp(), pg_tolower(), pg_toupper() plain ASCII semantics?

pg_strcasecmp(), etc., have a dependency on LC_CTYPE, which means a dependency on setlocale(). I'd like to eliminate those dependencies in the backend because they cause significant annoyance, especially when using non-libc providers. Right now, these functions are effectively very close to plain-

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

On Mon, Oct 20, 2025 at 03:33:53PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> Here is an updated patch set. > > The v3 patches work for me. Thanks. If baza's next run looks good, I'll proceed with committing. -- nathan

Re: Add \pset options for boolean value display

On Monday, October 20, 2025, Álvaro Herrera wrote: > On 2025-Jun-24, David G. Johnston wrote: > > > v1, Ready aside from bike-shedding the name. > > Here's v2 after some kibitzing. What do you think? > Thank you. Seems good from a quick read. I’m regretting the choice of the display_ prefix;

Re: [PING] [PATCH v2] parallel pg_restore: avoid disk seeks when jumping short distance forward

WriteDataToArchiveNone(ArchiveHandle *AH, CompressorState *cs, const void *data, size_t dLen) { - cs->writeF(AH, data, dLen); + NoneCompressorState *nonecs = (NoneCompressorState *) cs->private_data; + size_t remaining = dL

Client-only Meson Build From Sources

Hello, Are there any plans to support a client-only (no server) build in meson? We currently maintain a libpq-standalone fork that we haven’t updated in about ~1 year and would like to deprecate if possible. Here’s another

Re: Speed up COPY FROM text/CSV parsing using SIMD

On 2025-10-20 Mo 1:04 PM, Nathan Bossart wrote: On Mon, Oct 20, 2025 at 10:02:23AM -0400, Andrew Dunstan wrote: On 2025-10-16 Th 10:29 AM, Nazir Bilal Yavuz wrote: With this heuristic the regression is limited by %2 in the worst case. My worry is that the worst case is actually quite common.

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

Robert Haas writes: > On Mon, Oct 20, 2025 at 3:34 PM Tom Lane wrote: >> BTW, not critical right now, but thought I'd mention it: ISTM >> this mechanism obviates the need for the single-purpose NodeTag ABI >> checks installed by commit eea9fa9b2. > Hmm, but: the code in gen_node_support.pl would

Re: speedup COPY TO for partitioned table.

On Thu, Oct 16, 2025 at 3:01 PM Masahiko Sawada wrote: > > On Wed, Oct 15, 2025 at 7:57 PM jian he wrote: > > > > On Thu, Oct 16, 2025 at 9:21 AM Masahiko Sawada > > wrote: > > > > > > > Please check the attached v18. > > > > > > Thank you for updating the patch! > > > > > > I've reviewed the p

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

On Sun, Oct 19, 2025 at 2:16 PM Álvaro Herrera wrote: > If I were > a consultant trying to understand a customer's system, I would have to > ask them to run it twice just in case 'fast' is supported, and I don't > think that's very helpful. Big +1 from me. -- Robert Haas EDB: http://www.enterpr

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

On Mon, Oct 20, 2025 at 3:34 PM Tom Lane wrote: > Nathan Bossart writes: > > Here is an updated patch set. > > The v3 patches work for me. > > BTW, not critical right now, but thought I'd mention it: ISTM > this mechanism obviates the need for the single-purpose NodeTag ABI > checks installed by

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

Nathan Bossart writes: > Here is an updated patch set. The v3 patches work for me. BTW, not critical right now, but thought I'd mention it: ISTM this mechanism obviates the need for the single-purpose NodeTag ABI checks installed by commit eea9fa9b2. We still need the checks in gen_node_support

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

Some tests of stabilization, discussed in [0]. Also, an issue known for more then 1.5year... Should we at least document it? [0]: https://www.postgresql.org/message-id/flat/CADzfLwUc%3DjtSUEaQCtyt8zTeOJ-gHZ8%3Dw_KJsVjDOYSLqaY9Lg%40mail.gmail.com v10-0002-Modify-the-infer_arbiter_indexes-functi

Re: Accessing an invalid pointer in BufferManagerRelation structure

Hi, On Sun, Oct 19, 2025 at 6:32 PM Álvaro Herrera wrote: > > I edited your comments a bit. What do you think of this version? > Thanks for looking into this! All added changes LGTM. > I don't think this is backpatchable material, mainly because you said > you don't see any situations in which

[PATCH v4] parallel pg_restore: avoid disk seeks when jumping short distance forward

On Thursday 2025-10-16 19:01, Tom Lane wrote: I think this is more or less committable, and then we could get back to the original question of whether it's worth tweaking pg_restore's seek-vs-scan behavior. And done. Dimitrios, could you re-do your testing against current HEAD, and see if the

Skip unregistered custom kinds on stats load

Hi, While working on something nearby, I observed that if a custom pgstats kind is not registered while the on-disk pgstats.stat file contains entries for this custom kind, it results in all of the stats, including the built-in ones, being discarded. This can happen if you initially register this

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

On Mon, Oct 20, 2025 at 12:14:09PM -0500, Nathan Bossart wrote: > On Mon, Oct 20, 2025 at 01:07:04PM -0400, Tom Lane wrote: >> I'd tend to s/placate/control/, otherwise the proposed wording in the >> file looks good. I doubt we really need a script to generate the >> file in the first place -- why

Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue

On Mon Oct 20, 2025 at 11:18 AM -03, Álvaro Herrera wrote: > On 2025-Oct-20, Matheus Alcantara wrote: > >> This is similar to what was already proposed at [1]. This approach was >> abandoned because a notification on the queue may block datfrozenxid >> advance and clog truncation which can cause ot

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

On Mon, Oct 20, 2025 at 01:07:04PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> Thanks. Here's a new patch set. The v18 patch is just an update to the >> .abi-compliance-history file that Tom committed. The master patch adds >> instructions for generating the file to RELEASE_NOTES. > > I

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

Nathan Bossart writes: > Thanks. Here's a new patch set. The v18 patch is just an update to the > .abi-compliance-history file that Tom committed. The master patch adds > instructions for generating the file to RELEASE_NOTES. I'd tend to s/placate/control/, otherwise the proposed wording in th

Re: Speed up COPY FROM text/CSV parsing using SIMD

On Mon, Oct 20, 2025 at 10:02:23AM -0400, Andrew Dunstan wrote: > On 2025-10-16 Th 10:29 AM, Nazir Bilal Yavuz wrote: >> With this heuristic the regression is limited by %2 in the worst case. > > My worry is that the worst case is actually quite common. Sparse data sets > dominated by a lot of nul

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

On Mon, Oct 20, 2025 at 10:39:19AM -0400, Tom Lane wrote: > OK, I pushed a placeholder following Nathan's formatting proposal. > The ABI checker should still complain, because I made it point at > REL_18_0^, which is what I expect we'd do in practice. After we > see it respond to that, we can move

Re: Optimize LISTEN/NOTIFY

On Mon, Oct 20, 2025 at 1:07 AM Joel Jacobson wrote: > > > Minute of brainstorming > > > > I also thought about a workload that probably frequently can be met. > > Let's say we have sequence of notifications: > > > > F F F T F F F T F F F T > > > > Here F - notification from the channel we don't c

Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

I wrote: > I like the concept here, but not so much the details. Pulling > expand_grouping_sets out of preprocess_grouping_sets feels weird. > I guess it's all right given that preprocess_grouping_sets doesn't > manipulate the parse tree otherwise, but you didn't update the comment > for preproces

Re: Docs and tests for RLS policies applied by command type

Oops, looks like CI got mad as I didn’t include all patch files - trying again. /Viktor On 20 Oct 2025 at 16:02 +0200, Viktor Holmberg , wrote: > I’ve had a look at this. > > • The doc updates make it much clearer how things work. > • For the new test, I’ve verified that they pass. I also think th

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

On Oct 20, 2025, at 16:39, Tom Lane wrote: > OK, I pushed a placeholder following Nathan's formatting proposal. > The ABI checker should still complain, because I made it point at > REL_18_0^, which is what I expect we'd do in practice. After we > see it respond to that, we can move the referenc

Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt

On 2025-Oct-20, jian he wrote: > @@ -15632,11 +15623,6 @@ ATPostAlterTypeParse(Oid oldId, Oid oldRelId, > Oid refRelId, char *cmd, > querytree_list = lappend(querytree_list, stmt); > querytree_list = list_concat(querytree_list, afterStmts); > } > - else if (IsA(stmt, CreateStatsStmt)) > - qu

Re: Should we say "wal_level = logical" instead of "wal_level >= logical"

On Mon, Oct 20, 2025 at 3:20 AM Peter Smith wrote: > Do you have thoughts about the patch? I agree with the rationale that Ashutosh states but I don't see a strong need to patch the code to make this a 100% invariable rule. (Of course, someone else may disagree, which is fine.) -- Robert Haas E

Re: Proposal for enabling auto-vectorization for checksum calculations

Thanks for the new patch version! Another round of review: 1) I think that changes to contrib/pageinspect/rawpage.c should be in the main patch, not in the benchmark patch. Also, without those chages the main patch can't compile using make world-bin 2) I still don't get why you check for wor

Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

"David E. Wheeler" writes: > I’ve now deployed this change (well, a subsequent change that does it better) > to baza, so once the .abi-compliance-history has been committed to the rev 18 > branch (assuming the format is compatible), it should start passing again. OK, I pushed a placeholder foll

Re: pg_waldump: support decoding of WAL inside tarfile

On Thu, Oct 16, 2025 at 7:49 AM Amul Sul wrote: > astreamer reads the archive in fixed-size chunks (here it is 128KB). > Sometimes, a single read can contain data from two WAL files -- > specifically, the tail end of one file and the start of the next -- > because of how they’re physically stored

Re: Add \pset options for boolean value display

On 2025-Jun-24, David G. Johnston wrote: > v1, Ready aside from bike-shedding the name. Here's v2 after some kibitzing. What do you think? -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ >From ab14c69835836ff70c7193ff016e683ec8de9608 Mon Sep 17 00:00:00 2001 Fr

Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue

On 2025-Oct-20, Matheus Alcantara wrote: > This is similar to what was already proposed at [1]. This approach was > abandoned because a notification on the queue may block datfrozenxid > advance and clog truncation which can cause other issues for the users [2]. Well, I think that this is the rig

Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

Richard Guo writes: > On Sat, Oct 18, 2025 at 6:14 AM Tom Lane wrote: >>> The proposed patch tries to close the hole by checking whether >>> the condition is degenerate, but that feels subtly wrong to me: >>> what we ought to check is whether there is any empty grouping set. > v1 patch tries to

Re: Speed up COPY FROM text/CSV parsing using SIMD

On 2025-10-16 Th 10:29 AM, Nazir Bilal Yavuz wrote: Hi, On Thu, 21 Aug 2025 at 18:47, Andrew Dunstan wrote: On 2025-08-19 Tu 10:14 AM, Nazir Bilal Yavuz wrote: Hi, On Tue, 19 Aug 2025 at 15:33, Nazir Bilal Yavuz wrote: I am able to reproduce the regression you mentioned but both regression

Re: Docs and tests for RLS policies applied by command type

I’ve had a look at this. • The doc updates make it much clearer how things work. • For the new test, I’ve verified that they pass. I also think that having them is very good, considering the complexity of the RLS system. I found the added test quite hectic to follow, but this could just be a me

Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

On Sat, Oct 18, 2025 at 6:14 AM Tom Lane wrote: > I wrote: > > The proposed patch tries to close the hole by checking whether > > the condition is degenerate, but that feels subtly wrong to me: > > what we ought to check is whether there is any empty grouping set. > > As proposed, I think we miss

Re: formatting.c cleanup

> On Oct 20, 2025, at 17:50, Peter Eisentraut wrote: > > The file formatting.c contains some hard to read and understand code. For the > attached patch series, I made a few more or less mechanical passes over it to > modernize the code a bit, renamed some symbols to be clearer, adjusted some

Re: Question on ThrowErrorData

The comment seems not correct after the commit: commit dccda847b709e38ce6f09ac5c47f2bdf30e93a2c Author: Tom Lane Date: Thu Jun 27 14:43:59 2024 -0400 Avoid crashing when a JIT-inlined backend function throws an error. errfinish() assumes that the __FUNC__ and __FILE__ arguments it's

Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue

On Sun Oct 19, 2025 at 2:14 PM -03, Joel Jacobson wrote: > On Fri, Oct 17, 2025, at 15:51, Álvaro Herrera wrote: >> I have the impression that this thread has lost focus on the idea of >> producing a backpatchable bugfix. The last proposed patch has a lot of >> new mechanism that doesn't seem suit

Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue

On Sat Oct 18, 2025 at 2:43 AM -03, Joel Jacobson wrote: > On Fri, Oct 17, 2025, at 22:50, Arseniy Mukhin wrote: > What a funny coincidence that the approach in this patch, > has one similarity with the "Direct advancement" approach > in the patch in the "Optimize LISTEN/NOTIFY" [1] thread, > namel

Re: RFC: Logging plan of the running query

On 2025-10-17 05:15, Robert Haas wrote: On Wed, Oct 1, 2025 at 5:11 AM torikoshia wrote: I was also considering using an isolation test and injection points, like in the attached PoC patch. The main steps are: In session1, set an injection point to wait during query execution. In session

Re: Question on ThrowErrorData

=?UTF-8?B?5q2j5Y2O5ZCV?= writes: > Inside errfinish, it just does a simple pointer assignment to set > filename and funcname field (via function set_stack_entry_location()). Please note the comment on struct ErrorData: * ErrorData holds the data accumulated during any one ereport() cy

Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt

On Mon, Oct 20, 2025 at 3:31 PM Álvaro Herrera wrote: > > On 2025-Oct-20, jian he wrote: > > > On Fri, Oct 17, 2025 at 8:13 PM Álvaro Herrera wrote: > > > /* > > * transformStatsStmt - parse analysis for CREATE STATISTICS > > * > > * To avoid race conditions, it's important that this function

Re: Proposal: Adding compression of temporary files

Definitely, it’s not dead. I’m a bit busy at the moment, but I will address the compiler warnings along with the review. -Filip- po 20. 10. 2025 v 11:36 odesílatel Álvaro Herrera napsal: > Hello, > > This latest patchset is failing CI because of some compiler warnings on > Windows, see bel

Re: doc: create table improvements

On Monday, October 20, 2025, Laurenz Albe wrote: > On Thu, 2025-10-16 at 15:19 +0200, Laurenz Albe wrote: > > Attached is version 3. > > David, do you as the original patch author want to comment? > The patch is "waiting for author". > Thanks, I question whether “parameter” is even the correct

Re: PATCH for BUG #18785: Pointer bmr.rel, dereferenced by passing as 1st parameter to function is checked for NULL later

В письме от четверг, 18 сентября 2025 г. 11:44:57 Москва, стандартное время пользователь Алена Васильева написал: > I propose adding an Assert at this point as a way to document the contract > between this code and its environment. > This was previously discussed in BUG #18785 in pqsql-bugs > htt

  1   2   >