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 se
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
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
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 proc
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
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 wh
> 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 ad
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
> >
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 postgre
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
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 ab
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
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
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
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
comm
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
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
> > possibl
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
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. Attachin
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 connecti
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:
>>
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
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 ir
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 have
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
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
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 t
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), that
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
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
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
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
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 particular
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 B
+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 (CHECKPOINT_END_OF_RE
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 w
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
> 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 information
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 streaming
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 t
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 loc
>
> 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 stuc
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
flush
+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. Secon
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
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.
Inve
+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
ma
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.
>> 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 tes
I simplified the patch and for now just allowed one server. Please find the
attached patches, and the commit message.
Thanks,
Satya
-Original Message-
From: Robert Haas
Sent: Monday, November 6, 2017 5:56 AM
To: Craig Ringer
Cc: Satyanarayana Narlapuram ;
PostgreSQL-development
50 matches
Mail list logo
