Re: Add BF member koel-like indentation checks to SanityCheck CI

Bharath Rupireddy writes: > On Wed, Jan 10, 2024 at 12:54 PM Tom Lane wrote: >> Yeah. I'm not quite sure what's a good way to make this work, but >> it seems like having "make check-world" always invoke it would not >> be desirable. Making that conditional on an environment variable >> setting

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

On Wed, Jan 10, 2024 at 3:40 PM Sutou Kouhei wrote: > > Hi, > > In > "Re: Make COPY format extendable: Extract COPY TO format implementations" > on Wed, 10 Jan 2024 15:33:22 +0900, > Masahiko Sawada wrote: > > >> We can use the satic const struct approach by choosing one > >> of the

Re: Add BF member koel-like indentation checks to SanityCheck CI

On Wed, Jan 10, 2024 at 12:54 PM Tom Lane wrote: > > Michael Paquier writes: > > On Wed, Jan 10, 2024 at 01:25:36AM -0500, Tom Lane wrote: > >> So that leads to the conclusion that I wouldn't want an automatic > >> pgindent check to happen during "make all" or "make check", because > >> I want

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

On Tue, Jan 9, 2024 at 11:36 PM torikoshia wrote: > > On Tue, Dec 19, 2023 at 10:14 AM Masahiko Sawada > wrote: > > If we want only such a feature we need to implement it together (the > > patch could be split, though). But if some parts of the feature are > > useful for users as well, I'd

Re: Built-in CTYPE provider

On 1/9/24 2:31 PM, Jeff Davis wrote: > On Tue, 2024-01-09 at 14:17 -0800, Jeremy Schneider wrote: >> I think we missed something in psql, pretty sure I applied all the >> patches but I see this error: >> >> =# \l >> ERROR:  42703: column d.datlocale does not exist >> LINE 8:   d.datlocale as

Re: Add BF member koel-like indentation checks to SanityCheck CI

Michael Paquier writes: > On Wed, Jan 10, 2024 at 01:25:36AM -0500, Tom Lane wrote: >> So that leads to the conclusion that I wouldn't want an automatic >> pgindent check to happen during "make all" or "make check", because >> I want those things to succeed before I consider pgindent'ing. >>

Re: Add BF member koel-like indentation checks to SanityCheck CI

On Wed, Jan 10, 2024 at 01:25:36AM -0500, Tom Lane wrote: > John Naylor writes: >> Off the top of my head, I like to use '//' comments as quick notes to >> myself that stand out from normal code comments, and I'm in the habit >> of putting debug print statements flush against the left margin so

Re: Can we rely on the ordering of paths in pathlist?

On Tue, Apr 11, 2023 at 11:43 AM Andy Fan wrote: > On Tue, Apr 11, 2023 at 11:03 AM Richard Guo > wrote: > >> As the comment above add_path() says, 'The pathlist is kept sorted by >> total_cost, with cheaper paths at the front.' And it seems that >> get_cheapest_parallel_safe_total_inner()

Re: Custom explain options

On Wed, Jan 10, 2024 at 01:29:30PM +0700, Andrei Lepikhov wrote: > What do you think about this really useful feature? Do you wish to develop > it further? I am biased here. This seems like a lot of code for something we've been delegating to the explain hook for ages. Even if I can see the

Re: Add PQsendSyncMessage() to libpq

On Sun, Dec 31, 2023 at 09:37:31AM +0900, Michael Paquier wrote: > On Fri, Dec 29, 2023 at 12:52:30PM +0100, Jelte Fennema-Nio wrote: >> Those are some nice improvements. And I think once this patch is in, >> it would make sense to add the pgbench feature you're suggesting. >> Because indeed that

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Wed, Jan 10, 2024 at 9:05 AM Masahiko Sawada wrote: > > I've done in 0010 patch in v51 patch set. Whereas RT_NODE_4 and > RT_NODE_16 structs declaration needs RT_FANOUT_4_HI and > RT_FANOUT_16_HI respectively, RT_FANOUT_16_LO and RT_FANOUT_48 need > RT_NODE_16 and RT_NODE_48 structs

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

Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Wed, 10 Jan 2024 15:33:22 +0900, Masahiko Sawada wrote: >> We can use the satic const struct approach by choosing one >> of the followings: >> >> ... >> >> 4. ... other idea? > > It's a just idea but the

Re: Parent/child context relation in pg_get_backend_memory_contexts()

On 2024-01-03 20:40, Melih Mutlu wrote: Hi, Thanks for reviewing. Please find the updated patch attached. torikoshia , 4 Ara 2023 Pzt, 07:43 tarihinde şunu yazdı: I reviewed v3 patch and here are some minor comments: + + + path int4 Should 'int4' be 'int4[]'? Other

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

On Wed, Jan 10, 2024 at 12:00 PM Sutou Kouhei wrote: > > Hi, > > In > "Re: Make COPY format extendable: Extract COPY TO format implementations" > on Fri, 22 Dec 2023 10:00:24 +0900, > Michael Paquier wrote: > > >> 3. Export CopySend*() > >> > >>* If we like minimum API, we just need to

Re: Custom explain options

On 30/11/2023 22:40, Konstantin Knizhnik wrote: In all this cases we are using array of `Instrumentation` and if it contains varying part, then it is not clear where to place it. Yes, there is also code which serialize and sends instrumentations between worker processes  and I have updated this

Re: Synchronizing slots from primary to standby

On Tue, Jan 9, 2024 at 5:44 PM Zhijie Hou (Fujitsu) wrote: > comments on 0002 1. +/* Worker's nap time in case of regular activity on the primary server */ +#define WORKER_DEFAULT_NAPTIME_MS 10L /* 10 ms */ + +/* Worker's nap time in case of no-activity on the primary server */

Re: Add BF member koel-like indentation checks to SanityCheck CI

John Naylor writes: > Off the top of my head, I like to use '//' comments as quick notes to > myself that stand out from normal code comments, and I'm in the habit > of putting debug print statements flush against the left margin so > they're really obvious. Both of these would be wiped out by

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

Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Fri, 22 Dec 2023 10:58:05 +0800, Junwang Zhao wrote: >> 1. Add an opaque space for custom COPY TO handler >>* Add CopyToState{Get,Set}Opaque() >> >>

Re: Add BF member koel-like indentation checks to SanityCheck CI

On Wed, Jan 10, 2024 at 2:20 AM Tristan Partin wrote: > > On Tue Jan 9, 2024 at 3:00 AM CST, John Naylor wrote: > > I don't indent during most of development, and don't intend to start. > > Could you expand on why you don't? I could understand as you're writing, > but I would think formatting on

Re: Make NUM_XLOGINSERT_LOCKS configurable

Bharath Rupireddy writes: > On Wed, Jan 10, 2024 at 10:00 AM Tom Lane wrote: >> Maybe. I bet just bumping up the constant by 2X or 4X or so would get >> most of the win for far less work; it's not like adding a few more >> LWLocks is expensive. But we need some evidence about what to set it

Re: Make NUM_XLOGINSERT_LOCKS configurable

On Wed, Jan 10, 2024 at 10:00 AM Tom Lane wrote: > > Michael Paquier writes: > > This suggestion has showed up more than once in the past, and WAL > > insertion is a path that can become so hot under some workloads that > > changing it to a GUC would not be wise from the point of view of > >

Re: Show WAL write and fsync stats in pg_stat_io

On Wed, Jan 03, 2024 at 04:10:58PM +0300, Nazir Bilal Yavuz wrote: > On Sun, 31 Dec 2023 at 03:58, Michael Paquier wrote: >> Apologies if my previous wording sounded confusing. The idea I had in >> mind was to keep op_bytes in pg_stat_io, and extend it so as a value >> of NULL (or 0, or -1) is a

Re: pg_upgrade and logical replication

On Wed, Jan 03, 2024 at 03:18:50PM +0530, Amit Kapila wrote: > I think it would be good to finish the pending patch to improve the > IsBinaryUpgrade check [1] which we decided to do once this patch is > ready. Would you like to take that up or do you want me to finish it? > > [1] -

Re: A recent message added to pg_upgade

On Wed, Nov 15, 2023 at 07:58:06AM +0530, Amit Kapila wrote: > I am fine with this but there is no harm in doing this before or along > with the main patch. As of now, I don't see any problem but as the > main patch is still under review, so thought we could even wait for > the patch to become

Re: speed up a logical replica setup

On Fri, 5 Jan 2024 at 12:19, Shlok Kyal wrote: > > On Thu, 4 Jan 2024 at 16:46, Amit Kapila wrote: > > > > On Thu, Jan 4, 2024 at 12:22 PM Shlok Kyal wrote: > > > > > > Hi, > > > I was testing the patch with following test cases: > > > > > > Test 1 : > > > - Create a 'primary' node > > > -

Re: Make NUM_XLOGINSERT_LOCKS configurable

Michael Paquier writes: > This suggestion has showed up more than once in the past, and WAL > insertion is a path that can become so hot under some workloads that > changing it to a GUC would not be wise from the point of view of > performance. Redesigning all that to not require a set of

Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed

On Tue, Jan 09, 2024 at 08:00:00PM +0300, Alexander Lakhin wrote: > Thus just adding FREEZE is not enough, seemingly. It makes me wonder if > 0174c2d21 should be superseded by a patch like discussed (or just have > autovacuum = off added)... Adding an extra FREEZE offers an extra insurance, so I

Re: Fix bogus Asserts in calc_non_nestloop_required_outer

I wrote: > Robert Haas writes: >> But we could also find some way to assert that the parameterization >> sets contain only top-most rels. > Hmm ... perhaps worth doing. I think bms_is_subset against > all_baserels would work. [ tries that ... ] Nope, it needs to be all_query_rels. I plead

Re: Make NUM_XLOGINSERT_LOCKS configurable

On Tue, Jan 09, 2024 at 09:38:17PM -0500, Tom Lane wrote: > Making it an actual GUC would carry nontrivial costs, not least that > there are hot code paths that do "foo % NUM_XLOGINSERT_LOCKS" which > would go from a mask operation to a full integer divide. We are > unlikely to consider that on

Re: Commitfest 2024-01 first week update

On Wed, 10 Jan 2024 at 03:48, Robert Haas wrote: > > Hi, > > I think we need to be more aggressive about marking things returned > with feedback when they don't get updated. If a patch is waiting for > reviews for a long time, well, that's one thing. Maybe we eventually > close it due to lack of

Re: make pg_ctl more friendly

Hi Nazir, On Tue, Jan 9, 2024 at 9:23 PM Nazir Bilal Yavuz wrote: > > Hi, > > Thank you for working on this! I agree that the current message is not > friendly. > > On Thu, 9 Nov 2023 at 10:19, Junwang Zhao wrote: > > > > On Thu, Nov 9, 2023 at 3:08 PM Junwang Zhao wrote: > > > > > > After a

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

Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Fri, 22 Dec 2023 10:48:18 +0900, Masahiko Sawada wrote: >> I needed to extend the patch: >> >> 1. Add an opaque space for custom COPY TO handler >>* Add CopyToState{Get,Set}Opaque() >> >>

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

Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Fri, 22 Dec 2023 10:00:24 +0900, Michael Paquier wrote: >> 3. Export CopySend*() >> >>* If we like minimum API, we just need to export >> CopySendData() and CopySendEndOfRow(). But >>

Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows

Michael Paquier writes: > I have now applied 0001 for pg_ctl. > While reviewing that, I have also noticed spawn_process() in > pg_regress.c that includes direct command invocations with cmd.exe /c. > Could it make sense to append an extra /d for this case as well? No Windows expert here, but it

Re: Make NUM_XLOGINSERT_LOCKS configurable

writes: > I recently used benchmarksql to evaluate the performance of postgresql. I > achieved nearly 20% improvement > with NUM_XLOGINSERT_LOCKS changed from 8 to 16 under some cases of high > concurrency. I wonder whether > it is feasible to make NUM_XLOGINSERT_LOCKS a

Re: add AVX2 support to simd.h

On Tue, Jan 9, 2024 at 11:20 PM Nathan Bossart wrote: > > On Tue, Jan 09, 2024 at 09:20:09AM +0700, John Naylor wrote: > > On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart > > wrote: > >> > >> > I suspect that there could be a regression lurking for some inputs > >> > that the benchmark doesn't

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Tue, Jan 9, 2024 at 8:19 PM John Naylor wrote: > > On Tue, Jan 9, 2024 at 9:40 AM Masahiko Sawada wrote: > > In addition, I've made some changes and cleanups: > > These look good to me, although I have not tried dumping a node in a while. > > > 0011 - simplify the radix tree iteration code. I

Re: pg_ctl start may return 0 even if the postmaster has been already started on Windows

On Tue, Jan 09, 2024 at 09:40:23AM +0900, Michael Paquier wrote: > On Fri, Jan 05, 2024 at 02:58:55PM -0500, Robert Haas wrote: > > I'm not a Windows expert, but my guess is that 0001 is a very good > > idea. I hope someone who is a Windows expert will comment on that. > > I am +1 on 0001. It is

Re: the s_lock_stuck on perform_spin_delay

Hi, Robert Haas writes: > On Mon, Jan 8, 2024 at 9:40 PM Andy Fan wrote: >> The singler handler I was refering to is 'CHECK_FOR_INTERRUPTS', Based >> on this, spin_lock and lwlock are acted pretty differently. > > CHECK_FOR_INTERRUPTS() is not a signal handler, hmm, I knew this but I

Make NUM_XLOGINSERT_LOCKS configurable

Dear all, I recently used benchmarksql to evaluate the performance of postgresql. I achieved nearly 20% improvement with NUM_XLOGINSERT_LOCKS changed from 8 to 16 under some cases of high concurrency. I wonder whether it is feasible to make NUM_XLOGINSERT_LOCKS a configuration parameter, so

Re: Synchronizing slots from primary to standby

Here are some review comments for the patch v58-0001 == doc/src/sgml/catalogs.sgml 1. + + If true, the associated replication slots (i.e. the main slot and the + table sync slots) in the upstream database are enabled to be + synchronized to the physical standbys. +

Re: [PATCH] Add sortsupport for range types and btree_gist

On Thu, Dec 1, 2022 at 1:27 AM Bernd Helmle wrote: > > Hi, > > No deep code review yet, but CF is approaching its end and i didn't > have time to look at this earlier :/ > > Below are some things i've tested so far. > > Am Mittwoch, dem 15.06.2022 um 12:45 +0200 schrieb Christoph Heiss: > > > >

Re: subscription/015_stream sometimes breaks

On Tue, Aug 29, 2023 at 10:35 PM Alvaro Herrera wrote: > > On 2023-Aug-29, Amit Kapila wrote: > > > On Mon, Aug 28, 2023 at 5:35 AM Peter Smith wrote: > > > > > > On Fri, Aug 25, 2023 at 8:15 PM Amit Kapila > > > wrote: > > > > > > IMO there are inconsistencies in the second patch that was

Re: Built-in CTYPE provider

On Mon, 2024-01-08 at 17:17 -0800, Jeremy Schneider wrote: > I agree with merging the threads, even though it makes for a larger > patch set. It would be great to get a unified "builtin" provider in > place for the next major. I believe that's possible and that this proposal is quite close

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Tue, Jan 9, 2024 at 3:40 PM Robert Haas wrote: > > On Tue, Jan 9, 2024 at 3:13 PM Melanie Plageman > wrote: > > I had already written the patch for immediate reaping addressing the > > below feedback before I saw the emails that said everyone is happy > > with using hastup in

Re: Built-in CTYPE provider

On Tue, 2024-01-09 at 14:17 -0800, Jeremy Schneider wrote: > I think we missed something in psql, pretty sure I applied all the > patches but I see this error: > > =# \l > ERROR:  42703: column d.datlocale does not exist > LINE 8:   d.datlocale as "Locale", > Thank you. I'll fix this in the

Re: Add BF member koel-like indentation checks to SanityCheck CI

Robert Haas writes: > I think we need to do that, too, but the question is how. The best > suggestion I've heard so far was to make it part of the build, or part > of the test suite, so that if you don't do it, some part of what you > were going to do anyway actually fails. That avoids making it

Re: Commitfest 2024-01 first week update

Hi, I think we need to be more aggressive about marking things returned with feedback when they don't get updated. If a patch is waiting for reviews for a long time, well, that's one thing. Maybe we eventually close it due to lack of interest in reviewing it, but that should be done cautiously,

Re: Built-in CTYPE provider

On 12/28/23 6:57 PM, Jeff Davis wrote: > On Wed, 2023-12-27 at 17:26 -0800, Jeff Davis wrote: > Attached a more complete version that fixes a few bugs, stabilizes the > tests, and improves the documentation. I optimized the performance, too > -- now it's beating both libc's "C.utf8" and ICU

Re: Add BF member koel-like indentation checks to SanityCheck CI

On Tue, Jan 9, 2024 at 4:42 PM Daniel Gustafsson wrote: > > On 9 Jan 2024, at 22:20, Tom Lane wrote: > > In short, I don't think that putting this into CI is the answer. > > Putting it into committers' standard workflow is a better idea, > > if we can get all the committers on board with that. >

Re: Add BF member koel-like indentation checks to SanityCheck CI

On 1/9/24 3:20 PM, Tom Lane wrote: In short, I don't think that putting this into CI is the answer. Putting it into committers' standard workflow is a better idea, if we can get all the committers on board with that. FWIW, that's the approach that go takes - not only for committing to go

Re: Add BF member koel-like indentation checks to SanityCheck CI

> On 9 Jan 2024, at 22:20, Tom Lane wrote: > In short, I don't think that putting this into CI is the answer. > Putting it into committers' standard workflow is a better idea, > if we can get all the committers on board with that. +many -- Daniel Gustafsson

Re: add AVX2 support to simd.h

On Tue, 9 Jan 2024 at 18:20, Nathan Bossart wrote: > > On Tue, Jan 09, 2024 at 09:20:09AM +0700, John Naylor wrote: > > On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart > > wrote: > >> > >> > I suspect that there could be a regression lurking for some inputs > >> > that the benchmark doesn't look

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On 1/8/24 2:10 PM, Robert Haas wrote: On Fri, Jan 5, 2024 at 3:57 PM Andres Freund wrote: I will be astonished if you can make this work well enough to avoid huge regressions in plausible cases. There are plenty of cases where we do a very thorough job opportunistically removing index tuples.

Re: Add BF member koel-like indentation checks to SanityCheck CI

Robert Haas writes: > On Tue, Jan 9, 2024 at 2:20 PM Tristan Partin wrote: >>> I don't indent during most of development, and don't intend to start. >> Could you expand on why you don't? I could understand as you're writing, >> but I would think formatting on save, might be useful. > John

Re: Add BF member koel-like indentation checks to SanityCheck CI

On Tue Jan 9, 2024 at 2:49 PM CST, Robert Haas wrote: On Tue, Jan 9, 2024 at 2:20 PM Tristan Partin wrote: > > I don't indent during most of development, and don't intend to start. > > Could you expand on why you don't? I could understand as you're writing, > but I would think formatting on

Re: Adding a pg_get_owned_sequence function?

=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes: > Tom Lane writes: >> Maybe it would work to have both >> pg_get_serial_sequence(table text, column text) -> text >> pg_get_serial_sequence(table regclass, column text) -> regclass > I think it would be more correct to use name for the column

Re: Things I don't like about \du's "Attributes" column

On 03.01.2024 02:37, Jim Nasby wrote: Some attributes are arguably important enough to warrant their own column. The most obvious is NOLOGIN, since those roles are generally used for a very different purpose than LOGIN roles. SUPERUSER might be another candidate (though, I much prefer a

Re: Add BF member koel-like indentation checks to SanityCheck CI

On Tue, Jan 9, 2024 at 2:20 PM Tristan Partin wrote: > > I don't indent during most of development, and don't intend to start. > > Could you expand on why you don't? I could understand as you're writing, > but I would think formatting on save, might be useful. John might have his own answer to

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Tue, Jan 9, 2024 at 3:13 PM Melanie Plageman wrote: > I had already written the patch for immediate reaping addressing the > below feedback before I saw the emails that said everyone is happy > with using hastup in lazy_scan_[no]prune() in a preliminary patch. Let > me know if you have a

Re: index prefetching

On Thu, Jan 4, 2024 at 9:55 AM Tomas Vondra wrote: > Here's a somewhat reworked version of the patch. My initial goal was to > see if it could adopt the StreamingRead API proposed in [1], but that > turned out to be less straight-forward than I hoped, for two reasons: I guess we need Thomas or

Re: Emit fewer vacuum records by reaping removable tuples during pruning

I had already written the patch for immediate reaping addressing the below feedback before I saw the emails that said everyone is happy with using hastup in lazy_scan_[no]prune() in a preliminary patch. Let me know if you have a strong preference for reordering. Otherwise, I will write the three

Re: Emit fewer vacuum records by reaping removable tuples during pruning

Hi, On January 9, 2024 11:33:29 AM PST, Robert Haas wrote: >On Tue, Jan 9, 2024 at 2:23 PM Melanie Plageman > wrote: >> Yes, I agree. I thought about it more, and I prefer updating the FSM >> and setting nonempty_pages into lazy_scan_[no]prune(). Originally, I >> had ordered the patch set with

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Tue, Jan 9, 2024 at 2:23 PM Melanie Plageman wrote: > Yes, I agree. I thought about it more, and I prefer updating the FSM > and setting nonempty_pages into lazy_scan_[no]prune(). Originally, I > had ordered the patch set with that first (before the patch to do > immediate reaping), but there

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Tue, Jan 9, 2024 at 1:31 PM Robert Haas wrote: > > On Tue, Jan 9, 2024 at 10:56 AM Melanie Plageman > wrote: > > Andres had actually said that he didn't like pushing the update of > > nonempty_pages into lazy_scan_[no]prune(). So, my v4 patch set > > eliminates this. > > Mmph - but I was so

Re: Add BF member koel-like indentation checks to SanityCheck CI

On Tue Jan 9, 2024 at 3:00 AM CST, John Naylor wrote: On Mon, Oct 30, 2023 at 2:21 PM Bharath Rupireddy wrote: > > Hi, > > How about adding code indent checks (like what BF member koel has) to > the SanityCheck CI task? This helps catch indentation problems way > before things are committed so

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Tue, Jan 9, 2024 at 11:35 AM Melanie Plageman wrote: > The easiest solution would be to change the name of the parameter to > heap_page_prune_execute()'s from "no_indexes" to something like > "validate_unused", since it is only used in assert builds for > validation. Right. > However,

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Tue, Dec 5, 2023 at 1:44 AM Daniel Gustafsson wrote: > > > On 8 Nov 2023, at 20:00, Jacob Champion wrote: > > > Unfortunately the configure/Makefile build of libpq now seems to be > > pulling in an `exit()` dependency in a way that Meson does not. > > I believe this comes from the libcurl and

Re: WIP Incremental JSON Parser

On Tue, Dec 26, 2023 at 8:49 AM Andrew Dunstan wrote: > Quite a long time ago Robert asked me about the possibility of an > incremental JSON parser. I wrote one, and I've tweaked it a bit, but the > performance is significantly worse that that of the current Recursive > Descent parser. The

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Tue, Jan 9, 2024 at 10:56 AM Melanie Plageman wrote: > Andres had actually said that he didn't like pushing the update of > nonempty_pages into lazy_scan_[no]prune(). So, my v4 patch set > eliminates this. Mmph - but I was so looking forward to killing hastup! > On the other hand, the

Re: cleanup patches for incremental backup

Hello again, I have now committed 0001. I got some off-list review of 0004; specifically, Michael Paquier said it looked OK, and Tom Lane found another bug. So I've added a fix for that in what's now 0003. Here's v2. I plan to commit the rest of this fairly soon if there are no comments.

Re: Add BF member koel-like indentation checks to SanityCheck CI

>From the previous thread on this issue. I think the following proposal seemed like it had the most buy-in from committers. But so far nobody implemented it: On Wed, 18 Oct 2023 at 16:07, Robert Haas wrote: > > On Wed, Oct 18, 2023 at 3:21 AM Peter Eisentraut wrote: > > On 18.10.23 06:40, David

Re: Adding a pg_get_owned_sequence function?

Tom Lane writes: > Peter Eisentraut writes: >> Would it work to change the signature of pg_get_serial_sequence to >> pg_get_serial_sequence(table anyelement, column text) -> anyelement >> and then check inside the function code whether text or regclass was passed? > > Probably not very

Re: verify predefined LWLocks have entries in wait_event_names.txt

On Tue, Jan 09, 2024 at 02:26:20PM +0900, Michael Paquier wrote: > On Tue, Jan 09, 2024 at 04:55:07AM +, Bertrand Drouvot wrote: >> Thanks! v6 looks good to me. > > WFM. Thanks for putting in place this sanity check when compiling. Committed. Thanks for reviewing! -- Nathan Bossart

Re: add AVX2 support to simd.h

On Tue, 9 Jan 2024 at 16:03, Peter Eisentraut wrote: > On 29.11.23 18:15, Nathan Bossart wrote: > > Using the same benchmark as we did for the SSE2 linear searches in > > XidInMVCCSnapshot() (commit 37a6e5d) [1] [2], I see the following: > > > >writerssse2avx2 % > >256

Re: Adding a pg_get_owned_sequence function?

Peter Eisentraut writes: > Would it work to change the signature of pg_get_serial_sequence to > pg_get_serial_sequence(table anyelement, column text) -> anyelement > and then check inside the function code whether text or regclass was passed? Probably not very well, because then we'd get no

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Hello, Melanie! Sorry to interrupt you, just a quick question. > Correct, but there are changes being discussed where we would freeze > tuples during pruning as well [0], which would invalidate that > implementation detail. And, if I had to choose between improved > opportunistic freezing and

Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed

Hello Michael and Bertrand, I'd also like to note that even with FREEZE added [1], I happened to see the test failure: 5   #   Failed test 'inactiveslot slot invalidation is logged with vacuum on pg_class' 5   #   at t/035_standby_logical_decoding.pl line 222. 5 5   #   Failed test

Re: Fix bogus Asserts in calc_non_nestloop_required_outer

Robert Haas writes: > On Mon, Jan 8, 2024 at 5:39 PM Tom Lane wrote: >> I think we're talking at cross-purposes. What I was wondering about >> (at least further down in the thread) was whether we shouldn't be >> checking *both* the "real" and the "parent" relids to make sure they >> don't

Re: psql JSON output format

[cc'ing Joe] On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote: > > Getting it print numeric/boolean without quotes was actually easy, as > well as json(b). Implemented as the attached v2 patch. > > But: not quoting json means that NULL and 'null'::json will both be > rendered as 'null'. That

Re: Fix bogus Asserts in calc_non_nestloop_required_outer

On Mon, Jan 8, 2024 at 5:39 PM Tom Lane wrote: > I think we're talking at cross-purposes. What I was wondering about > (at least further down in the thread) was whether we shouldn't be > checking *both* the "real" and the "parent" relids to make sure they > don't overlap the parameterization

Re: Adding a pg_get_owned_sequence function?

On 08.01.24 22:08, Nathan Bossart wrote: I think these are reasonable concerns, but with this patch, we now have the following functions: pg_get_identity_sequence(table regclass, column name) -> regclass pg_get_serial_sequence(table text, column text) -> text If we only look at

Re: pg_dump: Remove obsolete trigger support

I wrote: > However, the patch looks a little incomplete: you did not remove > fetching of all of the now-unneeded values from the SQL queries. Oh, scratch that, I now see that we already did that query optimization. regards, tom lane

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Mon, Jan 8, 2024 at 3:51 PM Robert Haas wrote: > > On Fri, Jan 5, 2024 at 3:34 PM Melanie Plageman > wrote: > > This part of 0002 makes me very, very uncomfortable: > > + /* > +* Update all line pointers per the record, and repair > fragmentation. > +

Re: abi-compliance-checker

On 06.01.24 18:25, vignesh C wrote: One of the test has failed in cfbot at [1] with: abi-compliance-checker [12:04:10.537] The output from the failed tests: [12:04:10.537] [12:04:10.537] 129/282 postgresql:abidiff / plpgsql.abidiff FAIL 1.25s (exit status 4) [12:04:10.537] [12:04:10.537] ---

Re: pg_dump: Remove obsolete trigger support

On 09.01.24 16:27, Tom Lane wrote: Peter Eisentraut writes: In 30e7c175b81, support for pre-9.2 servers was removed from pg_dump. But I found that a lot of dead code was left for supporting dumping triggers from those old versions, presumably because that code was not behind straightforward

Re: Make psql ignore trailing semicolons in \sf, \ef, etc

On Mon Jan 8, 2024 at 6:08 PM CST, Tom Lane wrote: "Tristan Partin" writes: > On Mon Jan 8, 2024 at 2:48 PM CST, Tom Lane wrote: >> +(isascii((unsigned char) mybuf.data[mybuf.len - 1]) && >> +

Re: add AVX2 support to simd.h

On Tue, Jan 09, 2024 at 09:20:09AM +0700, John Naylor wrote: > On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart > wrote: >> >> > I suspect that there could be a regression lurking for some inputs >> > that the benchmark doesn't look at: pg_lfind32() currently needs to be >> > able to read 4 vector

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Tue, Jan 9, 2024 at 12:56 AM Michael Paquier wrote: > > On Mon, Jan 08, 2024 at 03:50:47PM -0500, Robert Haas wrote: > > Hmm, interesting. I haven't had time to study this fully today, but I > > think 0001 looks fine and could just be committed. Hooray for killing > > useless variables with

Re: the s_lock_stuck on perform_spin_delay

On Mon, Jan 8, 2024 at 9:40 PM Andy Fan wrote: > The singler handler I was refering to is 'CHECK_FOR_INTERRUPTS', Based > on this, spin_lock and lwlock are acted pretty differently. CHECK_FOR_INTERRUPTS() is not a signal handler, and it's OK to acquire and release spin locks or lwlocks there. We

Re: pg_dump: Remove obsolete trigger support

Peter Eisentraut writes: > In 30e7c175b81, support for pre-9.2 servers was removed from pg_dump. > But I found that a lot of dead code was left for supporting dumping > triggers from those old versions, presumably because that code was not > behind straightforward versioned "if" branches.

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

On Tue, Dec 19, 2023 at 10:14 AM Masahiko Sawada wrote: If we want only such a feature we need to implement it together (the patch could be split, though). But if some parts of the feature are useful for users as well, I'd recommend implementing it incrementally. That way, the patches can get

Re: psql JSON output format

Re: Dean Rasheed > > I'll note that the current code uses PG's string representation of > > strings which is meant to be round-trip safe when fed back into the > > server. So quoted numeric values aren't a problem at all. (And that > > part is fixable.) > > I'm not sure that being round-trip safe

Re: partitioning and identity column

On Thu, Dec 21, 2023 at 4:32 PM Peter Eisentraut wrote: > > On 19.12.23 11:47, Ashutosh Bapat wrote: > > At this point I am looking for opinions on the above rules and whether > > the implementation is on the right track. > > This looks on the right track to me. Thanks. > > > 0001 - change to

Re: add AVX2 support to simd.h

On 29.11.23 18:15, Nathan Bossart wrote: Using the same benchmark as we did for the SSE2 linear searches in XidInMVCCSnapshot() (commit 37a6e5d) [1] [2], I see the following: writerssse2avx2 % 25611951188-1 512 9281054 +14 1024 633

Re: make pg_ctl more friendly

Hi, Thank you for working on this! I agree that the current message is not friendly. On Thu, 9 Nov 2023 at 10:19, Junwang Zhao wrote: > > On Thu, Nov 9, 2023 at 3:08 PM Junwang Zhao wrote: > > > > After a PITR shutdown, the db state should be *shut down in recovery*, try > > the > > patch

Re: Synchronizing slots from primary to standby

On Tue, Jan 9, 2024 at 5:44 PM Zhijie Hou (Fujitsu) wrote: > > V58-0002 > +static bool +synchronize_one_slot(WalReceiverConn *wrconn, RemoteSlot *remote_slot) { ... + /* Slot ready for sync, so sync it. */ + else + { + /* + * Sanity check: With hot_standby_feedback enabled and + * invalidations

RE: Synchronizing slots from primary to standby

On Tuesday, January 9, 2024 9:17 AM Peter Smith wrote: > > Here are some review comments for patch v57-0001. Thanks for the comments! > > == > doc/src/sgml/protocol.sgml > > 1. CREATE_REPLICATION_SLOT ... FAILOVER > > + > +FAILOVER [ class="parameter">boolean ] > +

Re: psql JSON output format

On Tue, 9 Jan 2024 at 09:43, Christoph Berg wrote: > > I can see we probably wouldn't want two different output formats named > json, but the general idea of "allow psql to format results as json of > strings" makes a lot of sense, so we should try to make it work. Does > it even have to be

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Tue, Jan 9, 2024 at 9:40 AM Masahiko Sawada wrote: > In addition, I've made some changes and cleanups: These look good to me, although I have not tried dumping a node in a while. > 0011 - simplify the radix tree iteration code. I hope it makes the > code clear and readable. Also I removed

  1   2   >