Hi,
On Thu, Jul 28, 2022 at 4:05 AM Jacob Champion wrote:
>
> On Fri, Apr 8, 2022 at 7:27 AM Amul Sul wrote:
> > Attached is rebase version for the latest maste head(#891624f0ec).
>
> Hi Amul,
>
> I'm going through past CF triage emails today; I noticed that this
> patch dropped out of the
On Fri, Apr 8, 2022 at 7:27 AM Amul Sul wrote:
> Attached is rebase version for the latest maste head(#891624f0ec).
Hi Amul,
I'm going through past CF triage emails today; I noticed that this
patch dropped out of the commitfest when you withdrew it in January,
but it hasn't been added back with
On Sat, Apr 23, 2022 at 1:34 PM Bharath Rupireddy
wrote:
>
> On Mon, Mar 15, 2021 at 12:56 PM Amul Sul wrote:
> > >
> > > It is a very minor change, so I rebased the patch. Please take a look, if
> > > that works for you.
> > >
> >
> > Thanks, I am getting one more failure for the vacuumlazy.c.
On Mon, Mar 15, 2021 at 12:56 PM Amul Sul wrote:
> >
> > It is a very minor change, so I rebased the patch. Please take a look, if
> > that works for you.
> >
>
> Thanks, I am getting one more failure for the vacuumlazy.c. on the
> latest master head(d75288fb27b), I fixed that in attached
On Wed, Nov 17, 2021 at 6:20 PM Amul Sul wrote:
>
> On Wed, Nov 17, 2021 at 4:07 PM Amul Sul wrote:
> >
> > On Wed, Nov 17, 2021 at 11:13 AM Amul Sul wrote:
> > >
> > > On Sat, Nov 13, 2021 at 2:18 AM Robert Haas wrote:
> > > >
> > > > On Mon, Nov 8, 2021 at 8:20 AM Amul Sul wrote:
> > >
On Wed, Nov 17, 2021 at 4:07 PM Amul Sul wrote:
>
> On Wed, Nov 17, 2021 at 11:13 AM Amul Sul wrote:
> >
> > On Sat, Nov 13, 2021 at 2:18 AM Robert Haas wrote:
> > >
> > > On Mon, Nov 8, 2021 at 8:20 AM Amul Sul wrote:
> > > > Attached is the rebased version of refactoring as well as the
> >
On Wed, Nov 17, 2021 at 11:13 AM Amul Sul wrote:
>
> On Sat, Nov 13, 2021 at 2:18 AM Robert Haas wrote:
> >
> > On Mon, Nov 8, 2021 at 8:20 AM Amul Sul wrote:
> > > Attached is the rebased version of refactoring as well as the
> > > pg_prohibit_wal feature patches for the latest master head
On Sat, Nov 13, 2021 at 2:18 AM Robert Haas wrote:
>
> On Mon, Nov 8, 2021 at 8:20 AM Amul Sul wrote:
> > Attached is the rebased version of refactoring as well as the
> > pg_prohibit_wal feature patches for the latest master head (commit #
> > 39a3105678a).
>
> I spent a lot of time today
On Mon, Nov 8, 2021 at 8:20 AM Amul Sul wrote:
> Attached is the rebased version of refactoring as well as the
> pg_prohibit_wal feature patches for the latest master head (commit #
> 39a3105678a).
I spent a lot of time today studying 0002, and specifically the
question of whether EndOfLog must
On Mon, Oct 25, 2021 at 8:15 PM Robert Haas wrote:
>
> On Mon, Oct 25, 2021 at 3:05 AM Amul Sul wrote:
> > Ok, did the same in the attached 0001 patch.
> >
> > There is no harm in calling LocalSetXLogInsertAllowed() calling
> > multiple times, but the problem I can see is that with this patch
On 10/25/21, 1:33 PM, "Robert Haas" wrote:
> On Mon, Oct 25, 2021 at 3:14 PM Bossart, Nathan wrote:
>> My compiler is complaining about oldXLogAllowed possibly being used
>> uninitialized in CreateCheckPoint(). AFAICT it can just be initially
>> set to zero to silence this warning because it
On Mon, Oct 25, 2021 at 3:14 PM Bossart, Nathan wrote:
> My compiler is complaining about oldXLogAllowed possibly being used
> uninitialized in CreateCheckPoint(). AFAICT it can just be initially
> set to zero to silence this warning because it will, in fact, be
> initialized properly when it is
On 10/25/21, 7:50 AM, "Robert Haas" wrote:
> I've pushed 0001 and 0002 but I reversed the order of them and made a
> few other edits.
My compiler is complaining about oldXLogAllowed possibly being used
uninitialized in CreateCheckPoint(). AFAICT it can just be initially
set to zero to silence
On Mon, Oct 25, 2021 at 3:05 AM Amul Sul wrote:
> Ok, did the same in the attached 0001 patch.
>
> There is no harm in calling LocalSetXLogInsertAllowed() calling
> multiple times, but the problem I can see is that with this patch user
> is allowed to call LocalSetXLogInsertAllowed() at the time
On Tue, Oct 19, 2021 at 3:50 AM Robert Haas wrote:
>
> On Mon, Oct 18, 2021 at 9:54 AM Amul Sul wrote:
> > I tried this in the attached version, but I'm a bit skeptical with
> > changes that are needed for CreateCheckPoint(), those don't seem to be
> > clean.
>
> Yeah, that doesn't look great. I
On Mon, Oct 18, 2021 at 9:54 AM Amul Sul wrote:
> I tried this in the attached version, but I'm a bit skeptical with
> changes that are needed for CreateCheckPoint(), those don't seem to be
> clean.
Yeah, that doesn't look great. I don't think it's entirely correct,
actually, because surely you
On Thu, Oct 14, 2021 at 11:10 PM Robert Haas wrote:
>
> On Tue, Oct 12, 2021 at 8:18 AM Amul Sul wrote:
> > In the attached version I have fixed this issue by restoring
> > missingContrecPtr.
> >
> > To handle abortedRecPtr and missingContrecPtr newly added global
> > variables thought the
On Tue, Oct 12, 2021 at 8:18 AM Amul Sul wrote:
> In the attached version I have fixed this issue by restoring
> missingContrecPtr.
>
> To handle abortedRecPtr and missingContrecPtr newly added global
> variables thought the commit # ff9f111bce24, we don't need to store
> them in the shared
On Thu, Oct 7, 2021 at 6:21 PM Amul Sul wrote:
>
> On Thu, Oct 7, 2021 at 5:56 AM Jaime Casanova
> wrote:
> >
> > On Tue, Oct 05, 2021 at 04:11:58PM +0530, Amul Sul wrote:
> > >On Mon, Oct 4, 2021 at 1:57 PM Rushabh Lathia
> > > wrote:
> > > >
> > > > I tried to apply the patch on the
On Thu, Oct 7, 2021 at 5:56 AM Jaime Casanova
wrote:
>
> On Tue, Oct 05, 2021 at 04:11:58PM +0530, Amul Sul wrote:
> >On Mon, Oct 4, 2021 at 1:57 PM Rushabh Lathia
> > wrote:
> > >
> > > I tried to apply the patch on the master branch head and it's failing
> > > with conflicts.
> > >
> >
> >
On Tue, Oct 05, 2021 at 04:11:58PM +0530, Amul Sul wrote:
>On Mon, Oct 4, 2021 at 1:57 PM Rushabh Lathia
> wrote:
> >
> > I tried to apply the patch on the master branch head and it's failing
> > with conflicts.
> >
>
> Thanks, Rushabh, for the quick check, I have attached a rebased version
On Mon, Oct 4, 2021 at 1:57 PM Rushabh Lathia
wrote:
>
>
>
> On Fri, Oct 1, 2021 at 2:29 AM Robert Haas wrote:
>>
>> On Thu, Sep 30, 2021 at 7:59 AM Amul Sul wrote:
>> > To find the value of InRecovery after we clear it, patch still uses
>> > ControlFile's DBState, but now the check
On Fri, Oct 1, 2021 at 2:29 AM Robert Haas wrote:
> On Thu, Sep 30, 2021 at 7:59 AM Amul Sul wrote:
> > To find the value of InRecovery after we clear it, patch still uses
> > ControlFile's DBState, but now the check condition changed to a more
> > specific one which is less confusing.
> >
> >
On Thu, Sep 30, 2021 at 7:59 AM Amul Sul wrote:
> To find the value of InRecovery after we clear it, patch still uses
> ControlFile's DBState, but now the check condition changed to a more
> specific one which is less confusing.
>
> In casual off-list discussion, the point was made to check
>
On Fri, Sep 24, 2021 at 5:07 PM Amul Sul wrote:
>
> On Thu, Sep 23, 2021 at 11:56 PM Robert Haas wrote:
> >
> > On Mon, Sep 20, 2021 at 11:20 AM Amul Sul wrote:
> > > Ok, understood, I have separated my changes into 0001 and 0002 patch,
> > > and the refactoring patches start from 0003.
> >
> >
On Thu, Sep 23, 2021 at 11:56 PM Robert Haas wrote:
>
> On Mon, Sep 20, 2021 at 11:20 AM Amul Sul wrote:
> > Ok, understood, I have separated my changes into 0001 and 0002 patch,
> > and the refactoring patches start from 0003.
>
> I think it would be better in the other order, with the
On Mon, Sep 20, 2021 at 11:20 AM Amul Sul wrote:
> Ok, understood, I have separated my changes into 0001 and 0002 patch,
> and the refactoring patches start from 0003.
I think it would be better in the other order, with the refactoring
patches at the beginning of the series.
> In the 0001
On Wed, Sep 22, 2021 at 7:33 PM Mark Dilger
wrote:
>
>
>
> > On Sep 22, 2021, at 6:39 AM, Amul Sul wrote:
> >
> > Yes, that is a bit longer, here is the snip from v35-0010 patch
>
> Right, that's longer, and only tests one interaction. The isolation spec I
> posted upthread tests multiple
> On Sep 22, 2021, at 6:39 AM, Amul Sul wrote:
>
> Yes, that is a bit longer, here is the snip from v35-0010 patch
Right, that's longer, and only tests one interaction. The isolation spec I
posted upthread tests multiple interactions between the session which uses
cursors and the system
On Wed, Sep 22, 2021 at 6:59 PM Mark Dilger
wrote:
>
>
>
> > On Sep 22, 2021, at 6:14 AM, Amul Sul wrote:
> >
> >> Attached patch v34-0010 adds a test of cursors opened FOR UPDATE
> >> interacting with a system that is set read-only by a different session.
> >> The expected output is worth
> On Sep 22, 2021, at 6:14 AM, Amul Sul wrote:
>
>> Attached patch v34-0010 adds a test of cursors opened FOR UPDATE interacting
>> with a system that is set read-only by a different session. The expected
>> output is worth reviewing to see how this plays out. I don't see anything
>> in
On Wed, Sep 15, 2021 at 4:34 AM Mark Dilger
wrote:
>
>
>
> > On Jun 16, 2020, at 6:55 AM, amul sul wrote:
> >
> > (2) if the session is idle, we also need the top-level abort
> > record to be written immediately, but can't send an error to the client
> > until the next
> > command is issued
On Wed, Sep 15, 2021 at 9:38 PM Robert Haas wrote:
>
> On Wed, Sep 15, 2021 at 10:32 AM Robert Haas wrote:
> > Putting these changes into 0001 seems to make no sense. It seems like
> > they should be part of 0003, or maybe a new 0004 patch.
>
> After looking at this a little bit more, I think
On Wed, Sep 15, 2021 at 10:32 AM Robert Haas wrote:
> Putting these changes into 0001 seems to make no sense. It seems like
> they should be part of 0003, or maybe a new 0004 patch.
After looking at this a little bit more, I think it's really necessary
to separate out all of your changes into
On Wed, Sep 15, 2021 at 6:49 AM Amul Sul wrote:
> Initially, I thought to
> use SharedRecoveryState which is always set to RECOVERY_STATE_ARCHIVE,
> if the archive recovery requested. But there is another case where
> SharedRecoveryState could be RECOVERY_STATE_ARCHIVE irrespective of
>
, On Sat, Jul 24, 2021 at 1:33 AM Robert Haas wrote:
>
> On Thu, Jun 17, 2021 at 1:23 AM Amul Sul wrote:
> > Attached is rebase for the latest master head. Also, I added one more
> > refactoring code that deduplicates the code setting database state in the
> > control file. The same code set
> On Jun 16, 2020, at 6:55 AM, amul sul wrote:
>
> (2) if the session is idle, we also need the top-level abort
> record to be written immediately, but can't send an error to the client until
> the next
> command is issued without losing wire protocol synchronization. For now, we
> just use
On Fri, Sep 10, 2021 at 1:16 PM Mark Dilger
wrote:
> uses "immediately" and "will kill the running transaction" which reenforced
> the impression that this mechanism is heavier handed than it is.
It's intended to be just as immediate as e.g. pg_cancel_backend() and
pg_terminate_backend(), which
> On Sep 10, 2021, at 9:56 AM, Robert Haas wrote:
>
> I think the relevant question here is not "could a signal handler
> fire?" but "can we hit a CHECK_FOR_INTERRUPTS()?". If the relevant
> question is the former, then there's no hope of ever making it work
> because there's always a race
On Fri, Sep 10, 2021 at 12:20 PM Mark Dilger
wrote:
> A better example may be found in ginmetapage.c:
>
> needwal = RelationNeedsWAL(indexrel);
> if (needwal)
> {
> CheckWALPermitted();
> computeLeafRecompressWALData(leaf);
> }
>
>
> On Sep 10, 2021, at 8:42 AM, Mark Dilger wrote:
>
> Take for example a code stanza from heapam.c:
>
>if (needwal)
>CheckWALPermitted();
>
>/* NO EREPORT(ERROR) from here till changes are logged */
>START_CRIT_SECTION();
>
> Now, I know that interrupts won't be
> On Sep 10, 2021, at 7:36 AM, Amul Sul wrote:
>
>> v33-0005
>>
>> This patch makes bool XLogInsertAllowed() more complicated than before. The
>> result used to depend mostly on the value of LocalXLogInsertAllowed except
>> that when that value was negative, the result was determined by
On Thu, Sep 9, 2021 at 11:12 PM Mark Dilger
wrote:
>
>
Thank you, for looking at the patch. Please see my reply inline below:
>
> > On Sep 8, 2021, at 6:44 AM, Amul Sul wrote:
> >
> > Here is the rebased version.
>
> v33-0004
>
> This patch moves the include of "catalog/pg_control.h" from
> On Sep 9, 2021, at 11:21 AM, Robert Haas wrote:
>
> They have to check whether WAL has become prohibited
> and error out if so, and they need to do so before entering the
> critical section - because if the problem were detected for the first
> time inside the critical section it would
On Thu, Sep 9, 2021 at 1:42 PM Mark Dilger wrote:
> v33-0006:
>
> The new code comments in brin.c and elsewhere should use the verb "require"
> rather than "have", otherwise "building indexes" reads as a noun phrase
> rather than as a gerund: /* Building indexes will have an XID */
Honestly
> On Sep 8, 2021, at 6:44 AM, Amul Sul wrote:
>
> Here is the rebased version.
v33-0004
This patch moves the include of "catalog/pg_control.h" from transam/xlog.c into
access/xlog.h, making pg_control.h indirectly included from a much larger set
of files. Maybe that's ok. I don't know.
On Tue, 7 Sep 2021 at 8:43 PM, Mark Dilger
wrote:
>
>
> > On Aug 31, 2021, at 5:15 AM, Amul Sul wrote:
> >
> > Attached is the rebased version for the latest master head.
>
> Hi Amul!
>
> Could you please rebase again?
>
Ok will do that tomorrow, thanks.
Regards,
Amul
> On Aug 31, 2021, at 5:15 AM, Amul Sul wrote:
>
> Attached is the rebased version for the latest master head.
Hi Amul!
Could you please rebase again?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Aug 31, 2021 at 8:16 AM Amul Sul wrote:
> Attached is the rebased version for the latest master head. Also,
> added tap tests to test some part of this feature and a separate patch
> to test recovery_end_command execution.
It looks like you haven't given any thought to writing that in a
Hi,
On Thu, Jul 29, 2021 at 9:46 PM Robert Haas wrote:
> On Wed, Jul 28, 2021 at 7:33 AM Amul Sul wrote:
> > I was too worried about how I could miss that & after thinking more
> > about that, I realized that the operation for ArchiveRecoveryRequested
> > is never going to be skipped in the
On Wed, Jul 28, 2021 at 7:33 AM Amul Sul wrote:
> I was too worried about how I could miss that & after thinking more
> about that, I realized that the operation for ArchiveRecoveryRequested
> is never going to be skipped in the startup process and that never
> left for the checkpoint process to
On Thu, Jul 29, 2021 at 4:47 PM Dilip Kumar wrote:
>
> On Wed, Jul 28, 2021 at 5:03 PM Amul Sul wrote:
> >
> > I was too worried about how I could miss that & after thinking more
> > about that, I realized that the operation for ArchiveRecoveryRequested
> > is never going to be skipped in the
On Wed, Jul 28, 2021 at 5:03 PM Amul Sul wrote:
>
> I was too worried about how I could miss that & after thinking more
> about that, I realized that the operation for ArchiveRecoveryRequested
> is never going to be skipped in the startup process and that never
> left for the checkpoint process
On Wed, Jul 28, 2021 at 4:37 PM Amul Sul wrote:
>
> On Wed, Jul 28, 2021 at 2:26 AM Robert Haas wrote:
> >
> > On Fri, Jul 23, 2021 at 4:03 PM Robert Haas wrote:
> > > My 0003 is where I see some lingering problems. It creates
> > > XLogAcceptWrites(), moves the appropriate stuff there, and
On Wed, Jul 28, 2021 at 2:26 AM Robert Haas wrote:
>
> On Fri, Jul 23, 2021 at 4:03 PM Robert Haas wrote:
> > My 0003 is where I see some lingering problems. It creates
> > XLogAcceptWrites(), moves the appropriate stuff there, and doesn't
> > need the xlogreader. But it doesn't really solve the
On Fri, Jul 23, 2021 at 4:03 PM Robert Haas wrote:
> My 0003 is where I see some lingering problems. It creates
> XLogAcceptWrites(), moves the appropriate stuff there, and doesn't
> need the xlogreader. But it doesn't really solve the problem of how
> checkpointer.c would be able to call this
On Thu, Jun 17, 2021 at 1:23 AM Amul Sul wrote:
> Attached is rebase for the latest master head. Also, I added one more
> refactoring code that deduplicates the code setting database state in the
> control file. The same code set the database state is also needed for this
> feature.
I started
On Mon, May 17, 2021 at 11:48 AM Amul Sul wrote:
>
> On Sat, May 15, 2021 at 3:12 PM Dilip Kumar wrote:
> >
> > On Thu, May 13, 2021 at 2:56 PM Dilip Kumar wrote:
> > >
> > > Great thanks. I will review the remaining patch soon.
> >
> > I have reviewed v28-0003, and I have some comments on
On Thu, May 13, 2021 at 2:56 PM Dilip Kumar wrote:
>
> Great thanks. I will review the remaining patch soon.
I have reviewed v28-0003, and I have some comments on this.
===
@@ -126,9 +127,14 @@ XLogBeginInsert(void)
Assert(mainrdata_last == (XLogRecData *) _head);
On Thu, May 13, 2021 at 2:54 PM Amul Sul wrote:
>
> On Thu, May 13, 2021 at 12:36 PM Dilip Kumar wrote:
> >
> > On Wed, May 12, 2021 at 5:55 PM Amul Sul wrote:
> > >
> >
> > Thanks for the updated patch, while going through I noticed this comment.
> >
> > + /*
> > + * WAL prohibit state changes
On Wed, May 12, 2021 at 5:55 PM Amul Sul wrote:
>
Thanks for the updated patch, while going through I noticed this comment.
+ /*
+ * WAL prohibit state changes not allowed during recovery except the crash
+ * recovery case.
+ */
+ PreventCommandDuringRecovery("pg_prohibit_wal()");
Why do we
On Thu, May 13, 2021 at 2:26 AM Robert Haas wrote:
>
> On Wed, May 12, 2021 at 1:39 AM Dilip Kumar wrote:
> > Your idea makes sense, but IMHO, if we are first writing
> > XLogAcceptWrites() and then pushing out the barrier, then I don't
> > understand the meaning of having state #4. I mean
On Wed, May 12, 2021 at 1:39 AM Dilip Kumar wrote:
> Your idea makes sense, but IMHO, if we are first writing
> XLogAcceptWrites() and then pushing out the barrier, then I don't
> understand the meaning of having state #4. I mean whenever any
> backend receives the barrier the system will always
On Tue, May 11, 2021 at 11:54 PM Robert Haas wrote:
>
> On Tue, May 11, 2021 at 11:17 AM Amul Sul wrote:
> > I think I have much easier solution than this, will post that with update
> > version patch set tomorrow.
>
> I don't know what you have in mind, but based on this discussion, it
> seems
On Tue, May 11, 2021 at 11:17 AM Amul Sul wrote:
> I think I have much easier solution than this, will post that with update
> version patch set tomorrow.
I don't know what you have in mind, but based on this discussion, it
seems to me that we should just have 5 states instead of 4:
1. WAL is
On Tue, 11 May 2021 at 7:50 PM, Dilip Kumar wrote:
> On Tue, May 11, 2021 at 6:56 PM Amul Sul wrote:
> >
> > On Tue, May 11, 2021 at 6:48 PM Dilip Kumar
> wrote:
> > >
> > > On Tue, May 11, 2021 at 4:50 PM Amul Sul wrote:
> > > >
> > > > On Tue, May 11, 2021 at 4:13 PM Dilip Kumar
> wrote:
>
On Tue, May 11, 2021 at 6:56 PM Amul Sul wrote:
>
> On Tue, May 11, 2021 at 6:48 PM Dilip Kumar wrote:
> >
> > On Tue, May 11, 2021 at 4:50 PM Amul Sul wrote:
> > >
> > > On Tue, May 11, 2021 at 4:13 PM Dilip Kumar wrote:
> > > > I might be missing something, but assume the behavior should be
On Tue, May 11, 2021 at 6:48 PM Dilip Kumar wrote:
>
> On Tue, May 11, 2021 at 4:50 PM Amul Sul wrote:
> >
> > On Tue, May 11, 2021 at 4:13 PM Dilip Kumar wrote:
> > > I might be missing something, but assume the behavior should be like this
> > >
> > > 1. If the state is getting changed from
On Tue, May 11, 2021 at 4:50 PM Amul Sul wrote:
>
> On Tue, May 11, 2021 at 4:13 PM Dilip Kumar wrote:
> > I might be missing something, but assume the behavior should be like this
> >
> > 1. If the state is getting changed from WALPROHIBIT_STATE_READ_WRITE
> > -> WALPROHIBIT_STATE_READ_ONLY,
On Tue, May 11, 2021 at 4:13 PM Dilip Kumar wrote:
>
> On Tue, May 11, 2021 at 3:38 PM Amul Sul wrote:
> >
> > On Tue, May 11, 2021 at 2:26 PM Dilip Kumar wrote:
> > >
> > > On Tue, May 11, 2021 at 2:16 PM Amul Sul wrote:
> > >
> > > > I get why you think that, I wasn't very precise in
On Tue, May 11, 2021 at 3:38 PM Amul Sul wrote:
>
> On Tue, May 11, 2021 at 2:26 PM Dilip Kumar wrote:
> >
> > On Tue, May 11, 2021 at 2:16 PM Amul Sul wrote:
> >
> > > I get why you think that, I wasn't very precise in briefing the problem.
> > >
> > > Any new backend that gets connected right
On Tue, May 11, 2021 at 2:26 PM Dilip Kumar wrote:
>
> On Tue, May 11, 2021 at 2:16 PM Amul Sul wrote:
>
> > I get why you think that, I wasn't very precise in briefing the problem.
> >
> > Any new backend that gets connected right after the shared memory
> > state changes to
On Tue, May 11, 2021 at 2:16 PM Amul Sul wrote:
> I get why you think that, I wasn't very precise in briefing the problem.
>
> Any new backend that gets connected right after the shared memory
> state changes to WALPROHIBIT_STATE_GOING_READ_WRITE will be by
> default allowed to do the WAL
On Tue, May 11, 2021 at 11:33 AM Dilip Kumar wrote:
>
> On Mon, May 10, 2021 at 10:25 PM Amul Sul wrote:
> >
> > Yes, we don't want any write slip in before UpdateFullPageWrites().
> > Recently[1], we have decided to let the Checkpointed process call
> > XLogAcceptWrites() unconditionally.
> >
>
On Mon, May 10, 2021 at 10:25 PM Amul Sul wrote:
>
> Yes, we don't want any write slip in before UpdateFullPageWrites().
> Recently[1], we have decided to let the Checkpointed process call
> XLogAcceptWrites() unconditionally.
>
> Here problem is that when a backend executes the
>
On Mon, May 10, 2021 at 9:21 PM Robert Haas wrote:
>
> On Sun, May 9, 2021 at 1:26 AM Amul Sul wrote:
> > The state in the control file also gets cleared. Though, after
> > clearing in memory the state patch doesn't really do the immediate
> > change to the control file, it relies on the next
On Sun, May 9, 2021 at 1:26 AM Amul Sul wrote:
> The state in the control file also gets cleared. Though, after
> clearing in memory the state patch doesn't really do the immediate
> change to the control file, it relies on the next UpdateControlFile()
> to do that.
But when will that happen? If
On Fri, May 7, 2021 at 1:23 AM Robert Haas wrote:
>
> On Mon, Apr 12, 2021 at 10:04 AM Amul Sul wrote:
> > Rebased again.
>
> I started to look at this today, and didn't get very far, but I have a
> few comments. The main one is that I don't think this patch implements
> the design proposed in
>
On Mon, Apr 12, 2021 at 10:04 AM Amul Sul wrote:
> Rebased again.
I started to look at this today, and didn't get very far, but I have a
few comments. The main one is that I don't think this patch implements
the design proposed in
On Mon, Apr 5, 2021 at 11:02 AM Amul Sul wrote:
>
> Attached is the rebase version for the latest master head(commit #
> 9f6f1f9b8e6).
Some minor comments on 0001:
Isn't it "might not be running"?
+ errdetail("Checkpointer might not running."),
Isn't it "Try again after
Hi all,
While testing this feature with v20-patch, the server is crashing with
below steps.
Steps to reproduce:
1. Configure master-slave replication setup.
2. Connect to Slave.
3. Execute below statements, it will crash the server:
SELECT pg_prohibit_wal(true);
SELECT pg_prohibit_wal(false);
--
On Wed, Mar 3, 2021 at 8:56 PM Robert Haas wrote:
>
> On Tue, Mar 2, 2021 at 7:22 AM Dilip Kumar wrote:
> > Why do we need to move promote related code in XLogAcceptWrites?
> > IMHO, this promote related handling should be in StartupXLOG only.
> > That will look cleaner.
>
> The key design
On Wed, Mar 3, 2021 at 7:56 PM Dilip Kumar wrote:
>
> On Wed, Mar 3, 2021 at 4:50 PM Amul Sul wrote:
> >
> > On Wed, Mar 3, 2021 at 12:08 PM Dilip Kumar wrote:
> > >
> > Yes, it is possible to allow wal temporarily for itself by setting
> > LocalXLogInsertAllowed, but when we request
On Tue, Mar 2, 2021 at 7:22 AM Dilip Kumar wrote:
> Why do we need to move promote related code in XLogAcceptWrites?
> IMHO, this promote related handling should be in StartupXLOG only.
> That will look cleaner.
The key design question here, at least in my mind, is what exactly
happens after
On Wed, Mar 3, 2021 at 4:50 PM Amul Sul wrote:
>
> On Wed, Mar 3, 2021 at 12:08 PM Dilip Kumar wrote:
> >
> Yes, it is possible to allow wal temporarily for itself by setting
> LocalXLogInsertAllowed, but when we request Checkpointer for the
> end-of-recovery
> checkpoint, the first thing it
On Wed, Mar 3, 2021 at 12:08 PM Dilip Kumar wrote:
>
> On Tue, Mar 2, 2021 at 9:01 PM Dilip Kumar wrote:
>
> > >
> > > We don't want that to happen in cases where previous
> > > recovery-end-checkpoint is
> > > skipped in startup. We want Checkpointer first to convey the barrier to
> > > all
>
On Tue, Mar 2, 2021 at 9:01 PM Dilip Kumar wrote:
> >
> > We don't want that to happen in cases where previous
> > recovery-end-checkpoint is
> > skipped in startup. We want Checkpointer first to convey the barrier to all
> > backends but, the backend shouldn't write wal until the Checkpointer
On Tue, Mar 2, 2021 at 7:54 PM Amul Sul wrote:
> XLogAcceptWrites() tried to club all the WAL write operations that happen at
> the
> end of StartupXLOG(). The only exception is that promotion checkpoint.
Okay, I was expecting that XLogAcceptWrites should have all the WAL
write-related
On Tue, Mar 2, 2021 at 5:52 PM Dilip Kumar wrote:
>
> On Fri, Feb 19, 2021 at 5:43 PM Amul Sul wrote:
> >
> > In the attached version I have made the changes accordingly what Robert has
> > summarised in his previous mail[1].
> >
> > In addition to that, I also move the code that updates the
On Fri, Feb 19, 2021 at 5:43 PM Amul Sul wrote:
>
> In the attached version I have made the changes accordingly what Robert has
> summarised in his previous mail[1].
>
> In addition to that, I also move the code that updates the control file to
> XLogAcceptWrites() which will also get skipped
Hi,
On 2021-02-16 17:11:06 -0500, Robert Haas wrote:
> I can't promise that what I'm about to write is an entirely faithful
> representation of what he said, but hopefully it's not so far off that
> he gets mad at me or something.
Seems accurate - and also I'm way too tired that I'd be mad ;)
On Thu, Jan 28, 2021 at 7:17 AM Amul Sul wrote:
> I am still on this. The things that worried me here are the wal records
> sequence
> being written in the startup process -- UpdateFullPageWrites() generate record
> just before the recovery check-point record and XLogReportParameters() just
>
On Thu, Jan 21, 2021 at 9:47 AM Amul Sul wrote:
> It is not like that, let me explain. When a user backend requests to alter WAL
> prohibit state by using ASRO/ASRW DDL with the previous patch or calling
> pg_alter_wal_prohibit_state() then WAL prohibit state in shared memory will be
> set to the
On Thu, Jan 14, 2021 at 6:29 AM Amul Sul wrote:
> To move development, testing, and the review forward, I have commented out the
> code acquiring CheckpointLock from CreateCheckPoint() in the 0003 patch and
> added the changes for the checkpointer so that system read-write state change
> request
On Thu, Jan 14, 2021 at 6:29 AM Amul Sul wrote:
> To move development, testing, and the review forward, I have commented out the
> code acquiring CheckpointLock from CreateCheckPoint() in the 0003 patch and
> added the changes for the checkpointer so that system read-write state change
> request
On Mon, Dec 14, 2020 at 11:28 AM Amul Sul wrote:
>
> On Thu, Dec 10, 2020 at 6:04 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2020-12-09 16:13:06 -0500, Robert Haas wrote:
> > > That's not good. On a typical busy system, a system is going to be in
> > > the middle of a checkpoint most of the
On Thu, Dec 10, 2020 at 6:04 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-12-09 16:13:06 -0500, Robert Haas wrote:
> > That's not good. On a typical busy system, a system is going to be in
> > the middle of a checkpoint most of the time, and the checkpoint will
> > take a long time to finish -
Hi,
On 2020-12-09 16:13:06 -0500, Robert Haas wrote:
> That's not good. On a typical busy system, a system is going to be in
> the middle of a checkpoint most of the time, and the checkpoint will
> take a long time to finish - maybe minutes.
Or hours, even. Due to the cost of FPWs it can make a
On 2020-11-20 11:23:44 -0500, Robert Haas wrote:
> Andres, do you like the new loop better?
I do!
On Sat, Sep 12, 2020 at 1:23 AM Amul Sul wrote:
> > So, if we're in the middle of a paced checkpoint with a large
> > checkpoint_timeout - a sensible real world configuration - we'll not
> > process ASRO until that checkpoint is over? That seems very much not
> > practical. What am I missing?
>
1 - 100 of 161 matches
Mail list logo
