Re: [PATCH] Exponential backoff for auth_delay

Hi, On Wed, Dec 27, 2023 at 05:19:54PM +0100, Michael Banck wrote: > This patch adds exponential backoff so that one can choose a small > initial value which gets doubled for each failed authentication attempt > until a maximum wait time (which is 10s by default, but can be disabled > if so

the s_lock_stuck on perform_spin_delay

Hi, from src/backend/storage/lmgr/README: """ Spinlocks. These are intended for *very* short-term locks. If a lock is to be held more than a few dozen instructions, or across any sort of kernel call (or even a call to a nontrivial subroutine), don't use a spinlock. Spinlocks are primarily

Re: add function argument names to regex* functions.

On Thu, Jan 4, 2024 at 7:26 AM Jim Nasby wrote: > > On 1/3/24 5:05 PM, Dian Fay wrote: > > Another possibility is `index`, which is relatively short and not a > reserved keyword ^1. `position` is not as precise but would avoid the > conceptual overloading of ordinary indices. > > I'm not a fan of

Re: speed up a logical replica setup

On Wed, Jan 3, 2024 at 2:49 PM Amit Kapila wrote: > > c) Drop the replication slots d) Drop the > > publications > > > > I am not so sure about dropping publications because, unlike > subscriptions which can start to pull the data, there is no harm with > publications. Similar to publications

Re: speed up a logical replica setup

Hi, I was testing the patch with following test cases: Test 1 : - Create a 'primary' node - Setup physical replica using pg_basebackup "./pg_basebackup –h localhost –X stream –v –R –W –D ../standby " - Insert data before and after pg_basebackup - Run pg_subscriber and then insert some data to

Re: Synchronizing slots from primary to standby

On Wed, Jan 3, 2024 at 4:20 PM Amit Kapila wrote: > > On Fri, Dec 29, 2023 at 12:32 PM Amit Kapila wrote: > > I see your point and agree that users need to be careful. I was trying > > to compare it with other places like the conninfo used with a > > subscription where no separate dbname needs

Re: speed up a logical replica setup

On Thu, Jan 4, 2024 at 8:52 AM Euler Taveira wrote: > > On Mon, Jan 1, 2024, at 7:14 AM, vignesh C wrote: > > > 5) I felt the target server should be started before completion of > pg_subscriber: > > > Why? > Won't it be a better user experience that after setting up the target server as a

Re: speed up a logical replica setup

On Thu, Jan 4, 2024 at 8:24 AM Euler Taveira wrote: > > On Thu, Dec 21, 2023, at 3:16 AM, Amit Kapila wrote: > > > 2. remove the physical replication slot if the standby is using one > >(primary_slot_name). > > 3. provide instructions to promote the logical replica into primary, I mean, > >

Re: Synchronizing slots from primary to standby

On Wed, Jan 3, 2024 at 6:33 PM Zhijie Hou (Fujitsu) wrote: > > On Tuesday, January 2, 2024 6:32 PM shveta malik > wrote: > > On Fri, Dec 29, 2023 at 10:25 AM Amit Kapila > > > > The topup patch has also changed app_name to > > {cluster_name}_slotsyncworker so that we do not confuse between

Re: speed up a logical replica setup

On Mon, Jan 1, 2024, at 7:14 AM, vignesh C wrote: > 1) This Assert can fail if source is shutdown: > +static void > +drop_replication_slot(PGconn *conn, LogicalRepInfo *dbinfo, const > char *slot_name) > +{ > + PQExpBuffer str = createPQExpBuffer(); > + PGresult *res; > + > +

Re: Change GUC hashtable to use simplehash?

On Wed, Jan 3, 2024 at 10:12 PM John Naylor wrote: > > On Tue, Jan 2, 2024 at 6:56 AM jian he wrote: > > > > My local computer is slow. but here is the test results: > > > > select * from bench_cstring_hash_aligned(10);7318.893 ms > > select * from

Re: speed up a logical replica setup

On Thu, Dec 21, 2023, at 3:16 AM, Amit Kapila wrote: > I think this is an important part. Shall we try to write to some file > the pending objects to be cleaned up? We do something like that during > the upgrade. That's a good idea. > > 2. remove the physical replication slot if the standby is

Re: Transaction timeout

On Wed, 03 Jan 2024 at 20:04, Andrey M. Borodin wrote: >> On 3 Jan 2024, at 16:46, Andrey M. Borodin wrote: >> >> I do not understand why, but mailing list did not pick patches that I sent. >> I'll retry. > > > Sorry for the noise. Seems like Apple updated something in Mail.App couple of >

Re: Update for copyright messages to 2024 (Happy New Year!)

On Mon, Jan 1, 2024 at 07:25:16PM +0900, Michael Paquier wrote: > Hi, > (CC-ing Bruce) > > As of this new year, and in the vein of c8e1ba736b2b. Bruce, are you > planning an update of the copyright dates with a run of > ./src/tools/copyright.pl on HEAD, and the smallish updates of the back >

Re: Add a perl function in Cluster.pm to generate WAL

On Wed, Jan 03, 2024 at 06:39:29PM -0500, Tom Lane wrote: > I am not real sure what is happening there, but I see that c161ab74f > changed some details of how that test works, so I wonder if it's > responsible for these failures. The timing isn't a perfect match, > since this commit went in two

doing also VM cache snapshot and restore with pg_prewarm, having more information of the VM inside PostgreSQL

Hi, for 15 years pgfincore has been sitting quietly and being used in large setups to help in HA and resources management. It can perfectly stay as is, to be honest I was expecting to one day include a windows support and propose that to PostgreSQL, it appears getting support on linux and BSD

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: Adding facility for injection points (or probe points?) for more advanced tests

On Tue, Jan 02, 2024 at 11:14:56PM -0600, Nathan Bossart wrote: > Should we specify HASH_FIXED_SIZE, too? This hash table will be in the > main shared memory segment and therefore won't be able to expand too far > beyond the declared maximum size. Good point. > I'm wondering how important it is

Re: SET ROLE x NO RESET

On Tue, Jan 02, 2024 at 12:36:38PM -0500, Robert Haas wrote: > IMHO, the best solution here would be a protocol message to change the > session user. The pooler could use that repeatedly on the same > session, but refuse to propagate such messages from client > connections. But this requires

Re: SET ROLE x NO RESET

On Sat, Dec 30, 2023 at 10:16:59AM -0600, Eric Hanson wrote: > What do you think of adding a NO RESET option to the SET ROLE command? I've wanted this forever. Consider using this to implement user authentication mechanisms in user-defined SQL functions that use `SET ROLE` with `NO RESET` to

Re: Add a perl function in Cluster.pm to generate WAL

Michael Paquier writes: > I have added a comment about pg_logical_emit_message() being in > non-transactional mode and the flush implied by pg_switch_wal() as > that's important, edited a bit the whole, then applied the patch. Buildfarm member skink has failed 3 times in

Re: WIP Incremental JSON Parser

On Tue, Jan 02, 2024 at 10:14:16AM -0500, Robert Haas wrote: > It seems like a pretty significant savings no matter what. Suppose the > backup_manifest file is 2GB, and instead of creating a 2GB buffer, you > create an 1MB buffer and feed the data to the parser in 1MB chunks. > Well, that saves

Re: add function argument names to regex* functions.

On 1/3/24 5:05 PM, Dian Fay wrote: Another possibility is `index`, which is relatively short and not a reserved keyword ^1. `position` is not as precise but would avoid the conceptual overloading of ordinary indices. I'm not a fan

Re: Reducing output size of nodeToString

On Tue, 2 Jan 2024 at 11:30, Peter Eisentraut wrote: > > On 06.12.23 22:08, Matthias van de Meent wrote: > > PFA a patch that reduces the output size of nodeToString by 50%+ in > > most cases (measured on pg_rewrite), which on my system reduces the > > total size of pg_rewrite by 33% to 472KiB.

Change prefetch and read strategies to use range in pg_prewarm ... and raise a question about posix_fadvise WILLNEED

Hi, I wonder what you think of making pg_prewarm use recent addition on smgrprefetch and readv ? In order to try, I did it anyway in the attached patches. They contain no doc update, but I will proceed if it is of interest. In summary: 1. The first one adds a new check on parameters

Re: Extension Enhancement: Buffer Invalidation in pg_buffercache

On 1/3/24 10:25 AM, Cédric Villemain wrote: Hi Palak, I did a quick review of the patch: +CREATE FUNCTION pg_buffercache_invalidate(IN int, IN bool default true) +RETURNS bool +AS

Re: add function argument names to regex* functions.

> > Another possibility is `index`, which is relatively short and not a > > reserved keyword ^1. `position` is not as precise but would avoid the > > conceptual overloading of ordinary indices. > > I'm not a fan of "index" since that leaves the question of > whether it's 0 or 1 based. "Position"

Re: Reducing output size of nodeToString

On Wed, 3 Jan 2024 at 03:02, David Rowley wrote: > > On Thu, 14 Dec 2023 at 19:21, Matthias van de Meent > wrote: > > > > On Thu, 7 Dec 2023 at 13:09, David Rowley wrote: > > > We could also easily serialize plans to binary format for copying to > > > parallel workers rather than converting

Re: Password leakage avoidance

On 1/3/24 7:53 AM, Robert Haas wrote: Also, +1 for the general idea. I don't think this is a whole answer to the problem of passwords appearing in log files because (1) you have to be using libpq in order to make use of this and (2) you have to actually use it instead

Re: Add new for_each macros for iterating over a List that do not require ListCell pointer

On Wed, 3 Jan 2024 at 23:13, Tom Lane wrote: > I like Nathan's wording. To be clear, I don't want to block this patch on the wording of that single comment. So, if you feel Nathan's wording was better, I'm fine with that too. But let me respond to your arguments anyway: > Your assertion is

Re: add function argument names to regex* functions.

On 1/1/24 12:05 PM, Dian Fay wrote: I agree that the parameter name `n` is not ideal. For example, in `regexp_replace` it's easy to misinterpret it as "make up to n replacements". This has not been a problem when `n` only lives in the documentation which explains

Re: Add new for_each macros for iterating over a List that do not require ListCell pointer

Jelte Fennema-Nio writes: > The "we expect" reads to me as if we're not very sure that compilers > do this optimization. Even though we are quite sure. Maybe some small > changes like this to clarify that. > The outer loop only does a single iteration, so we expect that **any** > optimizing

Re: Add new for_each macros for iterating over a List that do not require ListCell pointer

On Wed, Jan 03, 2024 at 10:57:07PM +0100, Jelte Fennema-Nio wrote: > Overall your light edits look good to me. The commit message is very > descriptive and I like the shortening of the comments. The only thing > I feel is that I think lost some my original intent is this sentence: > > + *

Re: Add new for_each macros for iterating over a List that do not require ListCell pointer

On Wed, 3 Jan 2024 at 20:55, Nathan Bossart wrote: > > I spent some time preparing this for commit, which only amounted to some > light edits. I am posting a new version of the patch in order to get one > more round of cfbot coverage and to make sure there is no remaining > feedback. Overall

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

On 02.01.2024 22:38, Robert Haas wrote: To add to that a bit, I would probably never ask a user to give me the output of \du to troubleshoot some issue. I would either ask them for pg_dumpall -g output, or I'd ask them to give me the raw contents of pg_authid. That's because I know that either

Re: More new SQL/JSON item methods

On 03.01.24 13:01, Peter Eisentraut wrote: On 07.12.23 14:24, Jeevan Chalke wrote: We have the same issue with integer conversion and need a fix. Unfortunately, I was using int8in() for the conversion of numeric values. We should be using numeric_int8() instead. However, there is no

Re: Add new for_each macros for iterating over a List that do not require ListCell pointer

I spent some time preparing this for commit, which only amounted to some light edits. I am posting a new version of the patch in order to get one more round of cfbot coverage and to make sure there is no remaining feedback. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com >From

Re: Set log_lock_waits=on by default

On 12/21/23 6:58 AM, Nikolay Samokhvalov wrote: > On Thu, Dec 21, 2023 at 05:29 Laurenz Albe > wrote: > > Here is a patch to implement this. > Being stuck behind a lock for more than a second is almost > always a problem, so it is reasonable to turn

Re: SET ROLE x NO RESET

On Tue, 2 Jan 2024 at 23:23, Michał Kłeczek wrote: > > On 2 Jan 2024, at 18:36, Robert Haas wrote: > > IMHO, the best solution here would be a protocol message to change the > > session user. The pooler could use that repeatedly on the same > > session, but refuse to propagate such messages from

Re: WIP Incremental JSON Parser

On 2024-01-03 We 10:12, Robert Haas wrote: On Wed, Jan 3, 2024 at 9:59 AM Andrew Dunstan wrote: Say we have a document with an array 1m objects, each with a field called "color". As it stands we'll allocate space for that field name 1m times. Using a hash table we'd allocated space for it

Re: Assorted typo fixes

Robert Haas writes: > On Mon, Jan 1, 2024 at 6:05 PM Dagfinn Ilmari Mannsåker > wrote: >> Thanks. I've fixed the commit message (and elaborated it a bit more why >> I think it's a valid and safe fix). > > Regarding 0001: > > - AIUI, check_decls.m4 is copied from an upstream project, so I don't

Re: Extension Enhancement: Buffer Invalidation in pg_buffercache

Hi Palak, I did a quick review of the patch: +CREATE FUNCTION pg_buffercache_invalidate(IN int, IN bool default true) +RETURNS bool +AS 'MODULE_PATHNAME', 'pg_buffercache_invalidate' +LANGUAGE C PARALLEL SAFE; --> Not enforced anywhere, but you can also add a comment to the function, for end

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, 3 Jan 2024 at 00:43, Jacob Burroughs wrote: > What if we... Great suggestions! Attached is a v3 version of the patchset that implements all of this, including documentation. v3-0001-libpq-Handle-NegotiateProtocolVersion-message-mor.patch Description: Binary data

Re: Password leakage avoidance

On 1/2/24 7:23 AM, Sehrope Sarkuni wrote: Having worked on and just about wrapped up the JDBC driver patch for this, couple thoughts: 2. Password encoding should be split out and made available as its own functions. Not just as part of a wider "create _or_ alter a user's password" function

Re: add AVX2 support to simd.h

On Wed, Jan 03, 2024 at 09:13:52PM +0700, John Naylor wrote: > On Tue, Jan 2, 2024 at 11:11 PM Nathan Bossart > wrote: >> I'm tempted to propose that we move forward with this patch as-is after >> adding a buildfarm machine that compiles with -mavx2 or -march=x86-64-v3. > > That means that we

Re: WIP Incremental JSON Parser

On Wed, Jan 3, 2024 at 9:59 AM Andrew Dunstan wrote: > Say we have a document with an array 1m objects, each with a field > called "color". As it stands we'll allocate space for that field name 1m > times. Using a hash table we'd allocated space for it once. And > allocating the memory isn't

Re: trying again to get incremental backup

On Fri, Dec 22, 2023 at 12:00 AM Alexander Lakhin wrote: > My quick experiment shows that that TimestampDifferenceMilliseconds call > always returns zero, due to it's arguments swapped. Thanks. Tom already changed the unsigned -> int stuff in a separate commit, so I just pushed the fixes to

Re: WIP Incremental JSON Parser

On 2024-01-03 We 08:45, Robert Haas wrote: On Wed, Jan 3, 2024 at 6:57 AM Andrew Dunstan wrote: Yeah. One idea I had yesterday was to stash the field names, which in large JSON docs tent to be pretty repetitive, in a hash table instead of pstrduping each instance. The name would be valid

Re: add AVX2 support to simd.h

On Tue, Jan 2, 2024 at 11:11 PM Nathan Bossart wrote: > > Perhaps I was too optimistic about adding support for newer instructions... > > I'm tempted to propose that we move forward with this patch as-is after > adding a buildfarm machine that compiles with -mavx2 or -march=x86-64-v3. That means

Re: Change GUC hashtable to use simplehash?

On Tue, Jan 2, 2024 at 6:56 AM jian he wrote: > > My local computer is slow. but here is the test results: > > select * from bench_cstring_hash_aligned(10);7318.893 ms > select * from bench_cstring_hash_unaligned(10);10383.173 ms > select * from bench_pgstat_hash(10);

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

On Tue, Jan 2, 2024 at 8:01 PM Masahiko Sawada wrote: > I agree that we expose RT_LOCK_* functions and have tidstore use them, > but am not sure the if (TidStoreIsShared(ts) LWLockAcquire(..., ...)" > calls part. I think that even if we expose them, we will still need to > do something like "if

Re: Password leakage avoidance

On Wed, 3 Jan 2024 at 08:53, Robert Haas wrote: > On Sun, Dec 24, 2023 at 12:06 PM Jonathan S. Katz > wrote: > > We're likely to have new algorithms in the future, as there is a draft > > RFC for updating the SCRAM hashes, and already some regulatory bodies > > are looking to deprecate SHA256.

Re: Password leakage avoidance

On Sun, Dec 24, 2023 at 12:06 PM Jonathan S. Katz wrote: > We're likely to have new algorithms in the future, as there is a draft > RFC for updating the SCRAM hashes, and already some regulatory bodies > are looking to deprecate SHA256. My concern with relying on the > "encrypted_password" GUC

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

On Wed, Jan 3, 2024 at 12:08 AM Dilip Kumar wrote: > Yeah, this is indeed an interesting idea. So I think if we are > interested in working in this direction maybe this can be submitted in > a different thread, IMHO. Yeah, that's something quite different from the patch before us. -- Robert

Re: WIP Incremental JSON Parser

On Wed, Jan 3, 2024 at 6:57 AM Andrew Dunstan wrote: > Yeah. One idea I had yesterday was to stash the field names, which in > large JSON docs tent to be pretty repetitive, in a hash table instead of > pstrduping each instance. The name would be valid until the end of the > parse, and would only

Re: Show WAL write and fsync stats in pg_stat_io

Hi, On Sun, 31 Dec 2023 at 03:58, Michael Paquier wrote: > > On Tue, Dec 26, 2023 at 03:35:52PM +0300, Nazir Bilal Yavuz wrote: > > On Tue, 26 Dec 2023 at 13:10, Michael Paquier wrote: > >> I am not sure while the whole point of the exercise is to have all the > >> I/O related data in a single

Re: add function argument names to regex* functions.

On 28.12.23 04:28, jian he wrote: I looked around the oracle implementation in [1], and the oracle regex related function argumentation name in [2] I use the doc [3] syntax explanation and add the related function names. Current, regex.* function syntax seems fine. but only parameter `N` seems

Re: Transaction timeout

> On 3 Jan 2024, at 16:46, Andrey M. Borodin wrote: > > I do not understand why, but mailing list did not pick patches that I sent. > I'll retry. Sorry for the noise. Seems like Apple updated something in Mail.App couple of days ago and it started to use strange "Apple-Mail" stuff by

Re: More new SQL/JSON item methods

On 07.12.23 14:24, Jeevan Chalke wrote: We have the same issue with integer conversion and need a fix. Unfortunately, I was using int8in() for the conversion of numeric values. We should be using numeric_int8() instead. However, there is no opt_error version of the same. So, I have

Re: WIP Incremental JSON Parser

On 2024-01-02 Tu 10:14, Robert Haas wrote: On Tue, Dec 26, 2023 at 11: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

Re: Transaction timeout

On 3 Jan 2024, at 11:39, Andrey M. Borodin wrote:On 1 Jan 2024, at 19:28, Andrey M. Borodin wrote: 3. Check that timeout is not rescheduled by new queries (Nik's case)The test of Nik's case was not stable enough together with COMMIT AND CHAIN. So I've

Re: Random pg_upgrade test failure on drongo

On Tue, Jan 2, 2024 at 10:30 AM Alexander Lakhin wrote: > > 28.12.2023 06:08, Hayato Kuroda (Fujitsu) wrote: > > Dear Alexander, > > > >> I agree with your analysis and would like to propose a PoC fix (see > >> attached). With this patch applied, 20 iterations succeeded for me. > > There are no

Re: Parent/child context relation in pg_get_backend_memory_contexts()

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: > > > + > > + > role="column_definition"> > > + path int4 > > Should 'int4' be 'int4[]'? > Other

Re: Switching XLog source from archive to streaming when primary available

On Thu, Dec 28, 2023 at 5:26 PM Bharath Rupireddy wrote: > > I took a closer look at v14 and came up with the following changes: > > 1. Used advance_wal introduced by commit c161ab74f7. > 2. Simplified the core logic and new TAP tests. > 3. Reworded the comments and docs. > 4. Simplified new

Re: Synchronizing slots from primary to standby

Hi, On Wed, Jan 03, 2024 at 04:20:03PM +0530, Amit Kapila wrote: > On Fri, Dec 29, 2023 at 12:32 PM Amit Kapila wrote: > > > > On Fri, Dec 29, 2023 at 6:59 AM Masahiko Sawada > > wrote: > > > > > > On Wed, Dec 27, 2023 at 7:43 PM Amit Kapila > > > wrote: > > > > > > > > > > > > > > 3) The

Re: Separate memory contexts for relcache and catcache

Hi, torikoshia , 4 Ara 2023 Pzt, 07:59 tarihinde şunu yazdı: > Hi, > > I also think this change would be helpful. > > I imagine you're working on the Andres's comments and you already notice > this, but v1 patch cannot be applied to HEAD. > For the convenience of other reviewers, I marked it

Re: remaining sql/json patches

some more minor issues: SELECT * FROM JSON_TABLE(jsonb '{"a":[123,2]}', '$' COLUMNS (item int[] PATH '$.a' error on error, foo text path '$' error on error)) bar; ERROR: JSON path expression in JSON_VALUE should return singleton scalar item the error message seems not so great, imho. since

Re: remaining sql/json patches

On Fri, Dec 22, 2023 at 9:01 PM jian he wrote: > > Hi > > + /* FALLTHROUGH */ > + case JTC_EXISTS: > + case JTC_FORMATTED: > + { > + Node *je; > + CaseTestExpr *param = makeNode(CaseTestExpr); > + > + param->collation = InvalidOid; > + param->typeId = cxt->contextItemTypid; > + param->typeMod =

Re: Synchronizing slots from primary to standby

On Fri, Dec 29, 2023 at 12:32 PM Amit Kapila wrote: > > On Fri, Dec 29, 2023 at 6:59 AM Masahiko Sawada wrote: > > > > On Wed, Dec 27, 2023 at 7:43 PM Amit Kapila wrote: > > > > > > > > > > > 3) The slotsync worker uses primary_conninfo but also uses a new GUC > > > > parameter, say

Re: Next step towards 64bit XIDs: Switch to FullTransactionId for PGPROC->xid and XLogRecord->xl_xid

Hi, Maxim, and Happy New Year! On Mon, 1 Jan 2024 at 10:15, Maxim Orlov wrote: > On Fri, 29 Dec 2023 at 16:36, Matthias van de Meent < > boekewurm+postg...@gmail.com> wrote: > >> >> I don't think this is an actionable change, as this wastes 4 more bytes >> (or 8 with alignment) in nearly all

Re: XLog size reductions: Reduced XLog record header size for PG17

Hi and Happy New Year! I've looked through the patches and the change seems quite small and justified. But at the second round, some doubt arises on whether this long patchset indeed introduces enough performance gain? I may be wrong, but it saves only several bytes and the performance gain would

Re: pg_upgrade and logical replication

On Wed, Jan 3, 2024 at 11:33 AM Michael Paquier wrote: > > On Wed, Jan 03, 2024 at 11:24:50AM +0530, Amit Kapila wrote: > > I think the next possible step here is to document how to upgrade the > > logical replication nodes as previously discussed in this thread [1]. > > IIRC, there were a few

Re: speed up a logical replica setup

On Wed, 3 Jan 2024 at 14:49, Amit Kapila wrote: > > On Wed, Jan 3, 2024 at 12:09 PM vignesh C wrote: > > > > On Wed, 1 Nov 2023 at 19:28, Ashutosh Bapat > > wrote: > > > > > > At this stage the standby would have various replication objects like > > > publications, subscriptions, origins

Re: speed up a logical replica setup

On Wed, Jan 3, 2024 at 12:09 PM vignesh C wrote: > > On Wed, 1 Nov 2023 at 19:28, Ashutosh Bapat > wrote: > > > > At this stage the standby would have various replication objects like > > publications, subscriptions, origins inherited from the upstream > > server and possibly very much active.

Re: Update docs for default value of fdw_tuple_cost

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:tested, passed Good catch. This is a trivial fix and so I hope we can just get it in

Re: verify predefined LWLocks have entries in wait_event_names.txt

Hi, On Tue, Jan 02, 2024 at 10:49:03PM -0500, Robert Haas wrote: > On Tue, Jan 2, 2024 at 4:45 PM Nathan Bossart > wrote: > > That seems to date back to commit 14a9101. I can agree that the suffix is > > somewhat redundant since these are already marked as type "LWLock", but > > I'll admit