Re: Improve WALRead() to suck data directly from WAL buffers when possible

2023-01-25 Thread SATYANARAYANA NARLAPURAM
On Sat, Jan 14, 2023 at 12:34 PM Andres Freund wrote: > Hi, > > On 2023-01-14 00:48:52 -0800, Jeff Davis wrote: > > On Mon, 2022-12-26 at 14:20 +0530, Bharath Rupireddy wrote: > > > Please review the attached v2 patch further. > > > > I'm still unclear on the performance goals of this patch. I

Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication

2022-11-29 Thread SATYANARAYANA NARLAPURAM
On Tue, Nov 29, 2022 at 11:20 AM SATYANARAYANA NARLAPURAM < satyanarlapu...@gmail.com> wrote: > > > On Tue, Nov 29, 2022 at 10:52 AM Andrey Borodin > wrote: > >> On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian wrote: >> > >> > On Tue, Nov 29, 2022

Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication

2022-11-29 Thread SATYANARAYANA NARLAPURAM
On Tue, Nov 29, 2022 at 10:52 AM Andrey Borodin wrote: > On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian wrote: > > > > On Tue, Nov 29, 2022 at 08:14:10AM -0800, SATYANARAYANA NARLAPURAM wrote: > > > 2. Process proc die immediately when a backend is waiting for sy

Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication

2022-11-29 Thread SATYANARAYANA NARLAPURAM
On Tue, Nov 29, 2022 at 8:42 AM SATYANARAYANA NARLAPURAM < satyanarlapu...@gmail.com> wrote: > > > On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian wrote: > >> On Tue, Nov 29, 2022 at 08:14:10AM -0800, SATYANARAYANA NARLAPURAM wrote: >> > 2. Process pr

Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication

2022-11-29 Thread SATYANARAYANA NARLAPURAM
On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian wrote: > On Tue, Nov 29, 2022 at 08:14:10AM -0800, SATYANARAYANA NARLAPURAM wrote: > > 2. Process proc die immediately when a backend is waiting for sync > > replication acknowledgement, as it does today, however, upon restart

Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication

2022-11-29 Thread SATYANARAYANA NARLAPURAM
On Sun, Nov 27, 2022 at 10:33 PM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > On Mon, Nov 28, 2022 at 12:57 AM Andrey Borodin > wrote: > > > > Some funny stuff. If a user tries to cancel a non-replicated transaction > > Azure Postgres will answer: "user requested cancel

Re: WIP: WAL prefetch (another approach)

2022-04-12 Thread SATYANARAYANA NARLAPURAM
> Other way around. FPWs make prefetch unnecessary. > Therefore you would only want prefetch with FPW=off, AFAIK. > A few scenarios I can imagine page prefetch can help are, 1/ A DR replica instance that is smaller instance size than primary. Page prefetch can bring the pages back into memory in

Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory

2022-04-11 Thread SATYANARAYANA NARLAPURAM
On Sun, Apr 10, 2022 at 11:16 PM Kyotaro Horiguchi wrote: > Sorry for the terrible typos.. > > At Sat, 9 Apr 2022 18:03:01 +0530, Bharath Rupireddy < > bharath.rupireddyforpostg...@gmail.com> wrote in > > On Tue, Jan 4, 2022 at 1:40 AM SATYANARAYANA NARLAPURAM > >

Re: How to simulate sync/async standbys being closer/farther (network distance) to primary in core postgres?

2022-04-08 Thread SATYANARAYANA NARLAPURAM
On Fri, Apr 8, 2022 at 6:44 AM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > On Wed, Apr 6, 2022 at 4:30 PM Ashutosh Bapat > wrote: > > > > On Tue, Apr 5, 2022 at 9:23 PM Bharath Rupireddy > > wrote: > > > > > > Hi, > > > > > > I'm thinking if there's a way in core

Re: Stream Replication not working

2022-01-10 Thread SATYANARAYANA NARLAPURAM
Seems there is a problem with the replay on your standby. Either it is too slow or stuck behind some locks ( replay_lag of 20:38:47.00904 indicates this and the flush_lsn is the same as lsn on primary ) . Run pg_locks to see if the replay is stuck behind a lock. On Mon, Jan 10, 2022 at 11:53 AM

Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers

2022-01-08 Thread SATYANARAYANA NARLAPURAM
On Fri, Jan 7, 2022 at 4:52 PM Jeff Davis wrote: > On Fri, 2022-01-07 at 14:54 -0800, Andres Freund wrote: > > > If you only promote the furthest-ahead sync replica (which is what > > > you > > > should be doing if you have quorum commit), why wouldn't that work? > > > > Remove "sync" from the

Re: Logging replication state changes

2022-01-08 Thread SATYANARAYANA NARLAPURAM
On Sat, Jan 8, 2022 at 3:26 AM Amit Kapila wrote: > On Thu, Dec 30, 2021 at 4:18 AM SATYANARAYANA NARLAPURAM > wrote: > > > > On Wed, Dec 29, 2021 at 2:04 PM Tom Lane wrote: > >> > >> SATYANARAYANA NARLAPURAM writes: > >> > I noticed that bel

Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers

2022-01-07 Thread SATYANARAYANA NARLAPURAM
On Fri, Jan 7, 2022 at 12:27 AM Kyotaro Horiguchi wrote: > At Thu, 6 Jan 2022 23:55:01 -0800, SATYANARAYANA NARLAPURAM < > satyanarlapu...@gmail.com> wrote in > > On Thu, Jan 6, 2022 at 11:24 PM Jeff Davis wrote: > > > > > On Wed, 2022-01-05 at 23:59 -080

Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers

2022-01-06 Thread SATYANARAYANA NARLAPURAM
On Thu, Jan 6, 2022 at 11:24 PM Jeff Davis wrote: > On Wed, 2022-01-05 at 23:59 -0800, SATYANARAYANA NARLAPURAM wrote: > > I would like to propose a GUC send_Wal_after_quorum_committed which > > when set to ON, walsenders corresponds to async standbys and logical > > rep

Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers

2022-01-06 Thread SATYANARAYANA NARLAPURAM
Consider a cluster formation where we have a Primary(P), Sync Replica(S1), and multiple async replicas for disaster recovery and read scaling (within the region and outside the region). In this setup, S1 is the preferred failover target in an event of the primary failure. When a transaction is

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2022-01-05 Thread SATYANARAYANA NARLAPURAM
On Wed, Jan 5, 2022 at 10:05 PM Dilip Kumar wrote: > On Thu, Jan 6, 2022 at 11:27 AM SATYANARAYANA NARLAPURAM > wrote: > > > On Wed, Jan 5, 2022 at 9:46 AM Andres Freund wrote: > >> > >> Hi, > >> > >> On 2021-12-29 11:31:51 -0800, Andr

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2022-01-05 Thread SATYANARAYANA NARLAPURAM
On Wed, Jan 5, 2022 at 9:46 AM Andres Freund wrote: > Hi, > > On 2021-12-29 11:31:51 -0800, Andres Freund wrote: > > That's pretty much the same - XLogInsert() can trigger an > > XLogWrite()/Flush(). > > > > I think it's a complete no-go to add throttling to these places. It's > quite > >

Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory

2022-01-03 Thread SATYANARAYANA NARLAPURAM
Thanks Michael! On Sun, Jan 2, 2022 at 11:56 PM Michael Paquier wrote: > On Sun, Jan 02, 2022 at 09:27:43PM -0800, SATYANARAYANA NARLAPURAM wrote: > > I noticed that pg_receivewal fails to stream when the partial file to > write > > is not fully initialized and fails with

pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory

2022-01-02 Thread SATYANARAYANA NARLAPURAM
Hi Hackers, I noticed that pg_receivewal fails to stream when the partial file to write is not fully initialized and fails with the error message something like below. This requires an extra step of deleting the partial file that is not fully initialized before starting the pg_receivewal.

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-30 Thread SATYANARAYANA NARLAPURAM
On Thu, Dec 30, 2021 at 12:20 AM Dilip Kumar wrote: > On Thu, Dec 30, 2021 at 1:41 PM Bharath Rupireddy < > bharath.rupireddyforpostg...@gmail.com> wrote: > >> >> > >> > Yeah, that's true, but even if we are blocking the transactions from >> committing then also it is possible that a new

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-29 Thread SATYANARAYANA NARLAPURAM
On Wed, Dec 29, 2021 at 10:38 PM Dilip Kumar wrote: > On Thu, Dec 30, 2021 at 1:09 AM Andres Freund wrote: > >> Hi, >> >> On 2021-12-29 11:34:53 -0800, SATYANARAYANA NARLAPURAM wrote: >> > On Wed, Dec 29, 2021 at 11:31 AM Andres Freund >> wrote: >&

Re: Logging replication state changes

2021-12-29 Thread SATYANARAYANA NARLAPURAM
On Wed, Dec 29, 2021 at 2:04 PM Tom Lane wrote: > SATYANARAYANA NARLAPURAM writes: > > I noticed that below critical replication state changes are DEBUG1 level > > logged. Any concern about changing the below two messages log level to > LOG? > > Why? These seem like pe

Logging replication state changes

2021-12-29 Thread SATYANARAYANA NARLAPURAM
Hi hackers, I noticed that below critical replication state changes are DEBUG1 level logged. Any concern about changing the below two messages log level to LOG? If this is too verbose, we can introduce a new GUC, log_replication_state_changes that logs the replication state changes when enabled

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-29 Thread SATYANARAYANA NARLAPURAM
On Wed, Dec 29, 2021 at 11:31 AM Andres Freund wrote: > Hi, > > On 2021-12-27 16:40:28 -0800, SATYANARAYANA NARLAPURAM wrote: > > > Yet another problem is that if we are in XlogInsert() that means we are > > > holding the buffer locks on all the pages we ha

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-29 Thread SATYANARAYANA NARLAPURAM
On Wed, Dec 29, 2021 at 11:16 AM Stephen Frost wrote: > Greetings, > > On Wed, Dec 29, 2021 at 14:04 SATYANARAYANA NARLAPURAM < > satyanarlapu...@gmail.com> wrote: > >> Stephen, thank you! >> >> On Wed, Dec 29, 2021 at 5:46 AM Stephen Frost wrote: &g

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-29 Thread SATYANARAYANA NARLAPURAM
Stephen, thank you! On Wed, Dec 29, 2021 at 5:46 AM Stephen Frost wrote: > Greetings, > > * SATYANARAYANA NARLAPURAM (satyanarlapu...@gmail.com) wrote: > > On Sat, Dec 25, 2021 at 9:25 PM Dilip Kumar > wrote: > > > On Sun, Dec 26, 2021 at 10:36 AM SATYANARAYANA NARL

Re: Report checkpoint progress in server logs

2021-12-29 Thread SATYANARAYANA NARLAPURAM
Coincidentally, I was thinking about the same yesterday after tired of waiting for the checkpoint completion on a server. On Wed, Dec 29, 2021 at 7:41 AM Tom Lane wrote: > Magnus Hagander writes: > >> Therefore, reporting the checkpoint progress in the server logs, much > >> like [1], seems

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-27 Thread SATYANARAYANA NARLAPURAM
On Sat, Dec 25, 2021 at 9:25 PM Dilip Kumar wrote: > On Sun, Dec 26, 2021 at 10:36 AM SATYANARAYANA NARLAPURAM < > satyanarlapu...@gmail.com> wrote: > >> >>> Actually all the WAL insertions are done under a critical section >>> (except few exceptions), t

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-25 Thread SATYANARAYANA NARLAPURAM
On Sat, Dec 25, 2021 at 6:01 PM Dilip Kumar wrote: > On Sun, Dec 26, 2021 at 3:52 AM SATYANARAYANA NARLAPURAM < > satyanarlapu...@gmail.com> wrote: > >> >> >> On Fri, Dec 24, 2021 at 3:13 AM Dilip Kumar >> wrote: >> >>> On Fri, Dec 24, 2021

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-25 Thread SATYANARAYANA NARLAPURAM
On Fri, Dec 24, 2021 at 3:13 AM Dilip Kumar wrote: > On Fri, Dec 24, 2021 at 3:27 AM SATYANARAYANA NARLAPURAM < > satyanarlapu...@gmail.com> wrote: > >> >>> >> XLogInsert in my opinion is the best place to call it and the hook can be >> something like

Fwd: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-23 Thread SATYANARAYANA NARLAPURAM
Please find the attached draft patch. On Thu, Dec 23, 2021 at 2:47 AM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > On Thu, Dec 23, 2021 at 5:53 AM SATYANARAYANA NARLAPURAM > wrote: > > > > Hi Hackers, > > > > I am considering implem

Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-23 Thread SATYANARAYANA NARLAPURAM
On Thu, Dec 23, 2021 at 5:18 AM Ashutosh Bapat wrote: > On Thu, Dec 23, 2021 at 5:53 AM SATYANARAYANA NARLAPURAM > wrote: > > > > Hi Hackers, > > > > I am considering implementing RPO (recovery point objective) enforcement > feature for Postgres where the WAL

Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

2021-12-22 Thread SATYANARAYANA NARLAPURAM
Hi Hackers, I am considering implementing RPO (recovery point objective) enforcement feature for Postgres where the WAL writes on the primary are stalled when the WAL distance between the primary and standby exceeds the configured (replica_lag_in_bytes) threshold. This feature is useful

Re: Do we need pre-allocate WAL files during end-of-recovery checkpoint?

2021-12-06 Thread SATYANARAYANA NARLAPURAM
If the segment size is 16MB it shouldn't take much time but higher segment values this can be a problem. But again, the current segment has to be filled 75% to precreate new one. I am not sure how much we gain. Do you have some numbers with different segment sizes? On Mon, Dec 6, 2021 at 4:51 AM

Re: O(n) tasks cause lengthy startups and checkpoints

2021-12-01 Thread SATYANARAYANA NARLAPURAM
+1 to the idea. I don't see a reason why checkpointer has to do all of that. Keeping checkpoint to minimal essential work helps servers recover faster in the event of a crash. RemoveOldXlogFiles is also an O(N) operation that can at least be avoided during the end of recovery

Re: pg_replslotdata - a tool for displaying replication slot information

2021-11-30 Thread SATYANARAYANA NARLAPURAM
On Tue, Nov 30, 2021 at 9:47 PM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > On Wed, Dec 1, 2021 at 12:13 AM Bossart, Nathan > wrote: > > > > On 11/30/21, 6:14 AM, "Peter Eisentraut" < > peter.eisentr...@enterprisedb.com> wrote: > > > On 23.11.21 06:09, Bharath Rupireddy

Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file

2021-11-30 Thread SATYANARAYANA NARLAPURAM
On Tue, Nov 30, 2021 at 4:54 PM Michael Paquier wrote: > On Tue, Nov 30, 2021 at 05:58:15PM -0500, David Steele wrote: > > The main objections as I recall are that it is much harder for simple > backup > > scripts and commercial backup integrations to hold a connection to > postgres > > open and

Re: Synchronizing slots from primary to standby

2021-11-28 Thread SATYANARAYANA NARLAPURAM
> 3) Instead of the subscriber pulling the slot info, why can't the > publisher (via the walsender or a new bg worker maybe?) push the > latest slot info? I'm not sure we want to add more functionality to > the walsender, if yes, isn't it going to be much simpler? > Standby pulling the

Switching XLog source from archive to streaming when primary available

2021-11-28 Thread SATYANARAYANA NARLAPURAM
Hi Hackers, When the standby couldn't connect to the primary it switches the XLog source from streaming to archive and continues in that state until it can get the WAL from the archive location. On a server with high WAL activity, typically getting the WAL from the archive is slower than

Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file

2021-11-25 Thread SATYANARAYANA NARLAPURAM
Thanks Michael! This is a known issue with exclusive backups, which is a reason why > non-exclusive backups have been implemented. pg_basebackup does that, > and using "false" as the third argument of pg_start_backup() would > have the same effect. So I would recommend to switch to that. > Is

Postgres restart in the middle of exclusive backup and the presence of backup_label file

2021-11-24 Thread SATYANARAYANA NARLAPURAM
Hi Hackers, While an exclusive backup is in progress if Postgres restarts, postgres runs the recovery from the checkpoint identified by the label file instead of the control file. This can cause long recovery or even sometimes fail to recover as the WAL records corresponding to that checkpoint

Re: Synchronous commit behavior during network outage

2021-04-21 Thread SATYANARAYANA NARLAPURAM
> > This can be an option for us in our case. But there also needs to be a > process how to detect these "stuck commits" and how to invalidate/remove > them, because in reality, if the app/user would not see the change in the > database, it/he/she will try to insert/delete it again. If it just

Re: Synchronous commit behavior during network outage

2021-04-20 Thread SATYANARAYANA NARLAPURAM
One idea here is to make the backend ignore query cancellation/backend termination while waiting for the synchronous commit ACK. This way client never reads the data that was never flushed remotely. The problem with this approach is that your backends get stuck until your commit log record is

Re: when the startup process doesn't

2021-04-20 Thread SATYANARAYANA NARLAPURAM
+1 for both log messages and allowing connections. I believe these two complement each other. In the cloud world, we oftentimes want to monitor the progress of the recovery without connecting to the server as the operators don't necessarily have the required permissions to connect and query.

why pg_walfile_name() cannot be executed during recovery?

2021-04-02 Thread SATYANARAYANA NARLAPURAM
Hello Hackers, Why pg_walfile_name() can't be executed under recovery? What is the best way for me to get the current timeline and/or the file being recovering on the standby using a postgres query? I know I can get it via process title but don't want to go that route. Thanks, Satya

Re: Reduce/eliminate the impact of FPW

2020-08-03 Thread SATYANARAYANA NARLAPURAM
Increasing checkpoint_timeout helps reduce the amount of log written to the disk. This has several benefits like, reduced number of WAL IO, archival load on the system, less network traffic to the standby replicas. However, this increases the crash recovery time and impact server availability.

Re: [Patch] ALTER SYSTEM READ ONLY

2020-07-22 Thread SATYANARAYANA NARLAPURAM
+1 to this feature and I have been thinking about it for sometime. There are several use cases with marking database read only (no transaction log generation). Some of the examples in a hosted service scenario are 1/ when customer runs out of storage space, 2/ Upgrading the server to a different

RE: [HACKERS] Client Connection redirection support for PostgreSQL

2018-03-05 Thread Satyanarayana Narlapuram
Please see the attached patch with the comments. Changes in the patch: A client-side PGREDIRECTLIMIT parameter has been introduced to control the maximum number of retries. BE_v3.1 sends a ProtocolNegotiation message. FE_v3.1 downgrades to v3.0 upon receipt of this message.

Re: zheap: a new storage format for PostgreSQL

2018-03-01 Thread Satyanarayana Narlapuram
>> Cons >> --- >> 1. Deletes can be somewhat expensive. >> 2. Transaction aborts will be expensive. >> 3. Updates that update most of the indexed columns can be somewhat expensive. Given transaction aborts are expensive, is there any impact on the crash recovery? Did you perform any

RE: [HACKERS] Client Connection redirection support for PostgreSQL

2018-02-12 Thread Satyanarayana Narlapuram
t.com> Cc: Satyanarayana Narlapuram <satyanarayana.narlapu...@microsoft.com>; PostgreSQL-development <pgsql-hack...@postgresql.org> Subject: Re: [HACKERS] Client Connection redirection support for PostgreSQL On Thu, Nov 2, 2017 at 4:33 PM, Craig Ringer <cr...@2ndquadrant.com