On Fri, Sep 28, 2018 at 5:16 PM Amit Kapila wrote:
>
> On Fri, Sep 28, 2018 at 4:23 AM Michael Paquier wrote:
> >
> > On Thu, Sep 27, 2018 at 07:38:31PM +0530, Amit Kapila wrote:
> > > Okay, I am planning to commit the attached patch tomorrow unless you
> > > or anybody else has any objections to
On Fri, Sep 28, 2018 at 4:23 AM Michael Paquier wrote:
>
> On Thu, Sep 27, 2018 at 07:38:31PM +0530, Amit Kapila wrote:
> > Okay, I am planning to commit the attached patch tomorrow unless you
> > or anybody else has any objections to it.
>
> None from here. Thanks for taking care of it.
>
Thank
On Thu, Sep 27, 2018 at 07:38:31PM +0530, Amit Kapila wrote:
> Okay, I am planning to commit the attached patch tomorrow unless you
> or anybody else has any objections to it.
None from here. Thanks for taking care of it.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 27, 2018 at 6:22 PM Michael Paquier wrote:
>
> On Thu, Sep 27, 2018 at 04:19:02PM +0530, Amit Kapila wrote:
> > I think this is mostly fine, but it seems "if the instance just got
> > out of recovery" doesn't fit well because it can happen anytime after
> > recovery, this code gets cal
On Thu, Sep 27, 2018 at 04:19:02PM +0530, Amit Kapila wrote:
> I think this is mostly fine, but it seems "if the instance just got
> out of recovery" doesn't fit well because it can happen anytime after
> recovery, this code gets called from checkpointer. I think we can
> slightly tweak it as belo
On Thu, Sep 27, 2018 at 1:32 PM Michael Paquier wrote:
>
> On Thu, Sep 27, 2018 at 11:18:02AM +0530, Amit Kapila wrote:
> > Your proposed solution makes sense to me. IIUC, this is quite similar
> > to what Dilip has also proposed [1].
>
> Indeed. I would just add with the patch a comment like th
On Thu, Sep 27, 2018 at 01:30:13PM +0530, Amit Kapila wrote:
> I can take care of committing something along the lines of Dilip's
> patch if you are okay.
Sure, feel free to if you have some room. I am fine to take care of it
as well, so that's up to you to decide. Adding a comment like what I
p
On Thu, Sep 27, 2018 at 11:18:02AM +0530, Amit Kapila wrote:
> Your proposed solution makes sense to me. IIUC, this is quite similar
> to what Dilip has also proposed [1].
Indeed. I would just add with the patch a comment like that:
"Perform this call outside the critical section so as if the in
On Thu, Sep 27, 2018 at 11:18 AM Amit Kapila wrote:
>
> On Thu, Sep 27, 2018 at 10:34 AM Michael Paquier wrote:
> >
> > On Thu, Sep 27, 2018 at 10:03:59AM +0530, Amit Kapila wrote:
> > > I think, in this case, it might be advisable to just fix the problem
> > > (a) which is what has been reported
On Thu, Sep 27, 2018 at 10:34 AM Michael Paquier wrote:
>
> On Thu, Sep 27, 2018 at 10:03:59AM +0530, Amit Kapila wrote:
> > I think, in this case, it might be advisable to just fix the problem
> > (a) which is what has been reported originally in the thread and
> > AFAICS, the fix for that is cle
On Thu, Sep 27, 2018 at 10:03:59AM +0530, Amit Kapila wrote:
> I think, in this case, it might be advisable to just fix the problem
> (a) which is what has been reported originally in the thread and
> AFAICS, the fix for that is clear as compared to the problem (b). If
> you agree, then we can dis
On Wed, Sep 19, 2018 at 10:50 AM Michael Paquier wrote:
> > Agreed. "If we need to do that in the start process," we need to
> > change the shared flag and issue FPW_CHANGE always when the
> > database state is different from configuration file, regardless
> > of what StartXLOG() did until the poi
On Tue, Sep 18, 2018 at 12:46 PM Kyotaro HORIGUCHI
wrote:
>
> At Fri, 14 Sep 2018 16:30:37 +0530, Amit Kapila
> wrote in
> > On Fri, Sep 14, 2018 at 12:57 PM Michael Paquier
> > wrote:
> > >
> > > On Thu, Sep 06, 2018 at 04:37:28PM -0700, Michael Paquier wrote:
> > > > /*
> > > > * Properly
On Wed, Sep 19, 2018 at 02:20:34PM +0900, Michael Paquier wrote:
> On Tue, Sep 18, 2018 at 04:15:42PM +0900, Kyotaro HORIGUCHI wrote:
>> My latest patch tries to remove the window by imposing all
>> responsibility to apply config file changes to the shared FPW
>> flag on the checkpointer. RecoveryI
On Tue, Sep 18, 2018 at 04:15:42PM +0900, Kyotaro HORIGUCHI wrote:
> My latest patch tries to remove the window by imposing all
> responsibility to apply config file changes to the shared FPW
> flag on the checkpointer. RecoveryInProgress() is changed to be
> called prior to UpdateFullPageWrites on
At Fri, 14 Sep 2018 16:30:37 +0530, Amit Kapila wrote
in
> On Fri, Sep 14, 2018 at 12:57 PM Michael Paquier wrote:
> >
> > On Thu, Sep 06, 2018 at 04:37:28PM -0700, Michael Paquier wrote:
> > > /*
> > > * Properly accept or ignore signals the postmaster might send us.
> > > */
> > > - p
On Tue, Sep 18, 2018 at 01:06:09PM +0900, Kyotaro HORIGUCHI wrote:
> I was wrong here. It was handled in HandleStartupProcInterrupts
> called from StartupXLOG. So, it should be just removed from the
> set. Sorry for the bogus patch.
Thanks for confirming.
Still, it looks like a waste to abuse on
On Fri, Sep 14, 2018 at 04:30:37PM +0530, Amit Kapila wrote:
> On Fri, Sep 14, 2018 at 12:57 PM Michael Paquier wrote:
>> So, I have been working on this problem again and I have reviewed the
>> thread, and there have been many things discussed in the last couple of
>> months:
>> 1) We do not want
Hello.
At Tue, 18 Sep 2018 11:38:50 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180918.113850.164570138.horiguchi.kyot...@lab.ntt.co.jp>
> At Thu, 6 Sep 2018 16:37:28 -0700, Michael Paquier
> wrote in <20180906233728.gr2...@paquier.xyz>
> > I am finally coming back to this patc
At Thu, 6 Sep 2018 16:37:28 -0700, Michael Paquier wrote
in <20180906233728.gr2...@paquier.xyz>
> On Tue, Aug 28, 2018 at 07:34:36PM +0900, Kyotaro HORIGUCHI wrote:
> > Thanks for prompting. The difference is in a comment and I'm fine
> > with the change.
>
> /*
> * Properly accept or ignore si
On Fri, Sep 14, 2018 at 12:57 PM Michael Paquier wrote:
>
> On Thu, Sep 06, 2018 at 04:37:28PM -0700, Michael Paquier wrote:
> > /*
> > * Properly accept or ignore signals the postmaster might send us.
> > */
> > - pqsignal(SIGHUP, StartupProcSigHupHandler); /* reload config file */
> > +
On Thu, Sep 06, 2018 at 04:37:28PM -0700, Michael Paquier wrote:
> /*
> * Properly accept or ignore signals the postmaster might send us.
> */
> - pqsignal(SIGHUP, StartupProcSigHupHandler); /* reload config file */
> + pqsignal(SIGHUP, SIG_IGN); /* ignore reload config */
>
> I am
On Thu, Sep 13, 2018 at 04:38:30PM +0530, Amit Kapila wrote:
> So, the problem started appearing after some rearrangement of code in
> both the above-mentioned commits. I verified that this problem
> doesn't exist in versions <=9.4, so backpatch-through 9.5.
Thanks Amit for taking care of this fi
On Mon, Sep 10, 2018 at 11:54 AM Amit Kapila wrote:
>
> Thanks, but what I wanted you to verify is the commit that broke it in
> 9.5. On again looking at it, I think it is below code in commit
> 2076db2aea that caused this problem. If possible, can you once test
> it before and at this commit or
On Tue, Aug 28, 2018 at 4:05 PM Kyotaro HORIGUCHI
wrote:
>
> Hello.
>
> At Sat, 25 Aug 2018 14:50:53 +0530, Amit Kapila
> wrote in
> > On Wed, Aug 1, 2018 at 12:56 PM Kyotaro HORIGUCHI
> > wrote:
> > >
> > > Thank you, Amit, Michael.
> > >
> >
> > Can you verify the first patch that I have pos
On Tue, Aug 28, 2018 at 07:34:36PM +0900, Kyotaro HORIGUCHI wrote:
> Thanks for prompting. The difference is in a comment and I'm fine
> with the change.
/*
* Properly accept or ignore signals the postmaster might send us.
*/
- pqsignal(SIGHUP, StartupProcSigHupHandler); /* reload config f
Hello.
At Sat, 25 Aug 2018 14:50:53 +0530, Amit Kapila wrote
in
> On Wed, Aug 1, 2018 at 12:56 PM Kyotaro HORIGUCHI
> wrote:
> >
> > Thank you, Amit, Michael.
> >
>
> Can you verify the first patch that I have posted above [1]? We can
> commit it separately.
Thanks for prompting. The differ
On Wed, Aug 1, 2018 at 12:56 PM Kyotaro HORIGUCHI
wrote:
>
> Thank you, Amit, Michael.
>
Can you verify the first patch that I have posted above [1]? We can
commit it separately.
>
> It's a long time ago.. Let me have a bit of time to blow dust off..
>
> https://www.postgresql.org/message-id/20
Thank you, Amit, Michael.
At Sun, 29 Jul 2018 08:19:11 +0900, Michael Paquier wrote
in <20180728231911.gb1...@paquier.xyz>
> On Sat, Jul 28, 2018 at 07:10:24PM +0530, Amit Kapila wrote:
> > I have just responded to your first patch (0001). Can you once again
> > summarize what the 0002 exactly
On Sat, Jul 28, 2018 at 07:10:24PM +0530, Amit Kapila wrote:
> I have just responded to your first patch (0001). Can you once again
> summarize what the 0002 exactly accomplishes? I think one of the
> goals is to fix the original problem reported in this thread and other
> is you have found the c
On Tue, Apr 24, 2018 at 7:10 AM, Kyotaro HORIGUCHI
wrote:
> At Tue, 24 Apr 2018 08:52:17 +0900, Michael Paquier
> wrote in <20180423235217.gb1...@paquier.xyz>
>> On Mon, Apr 23, 2018 at 12:21:04PM -0400, Robert Haas wrote:
>> > Fine, but that doesn't answer the question of whether we actually ne
On Fri, Apr 20, 2018 at 6:06 PM, Amit Kapila wrote:
> On Fri, Apr 20, 2018 at 11:40 AM, Kyotaro HORIGUCHI
> wrote:
>> By the way, I think I found a bug of FPW.
>>
>> The following steps yields INSERT record that doesn't have a FPI
>> after a checkpoint.
>>
>> (Start server with full_page_writes =
At Tue, 24 Apr 2018 08:52:17 +0900, Michael Paquier wrote
in <20180423235217.gb1...@paquier.xyz>
> On Mon, Apr 23, 2018 at 12:21:04PM -0400, Robert Haas wrote:
> > Fine, but that doesn't answer the question of whether we actually need
> > to or should change the behavior in the first place.
>
>
On Mon, Apr 23, 2018 at 12:21:04PM -0400, Robert Haas wrote:
> Fine, but that doesn't answer the question of whether we actually need
> to or should change the behavior in the first place.
Per the last arguments that would be "No, we don't want to change it as
it would surprise some users":
https:
On Wed, Apr 18, 2018 at 9:49 PM, Michael Paquier wrote:
> On Wed, Apr 18, 2018 at 10:52:51AM -0400, Robert Haas wrote:
>> I would just document the risks. If the documentation says that you
>> can't rely on the value until after the next checkpoint, or whatever
>> the rule is, then I think we're
On Fri, Apr 20, 2018 at 11:40 AM, Kyotaro HORIGUCHI
wrote:
> By the way, I think I found a bug of FPW.
>
> The following steps yields INSERT record that doesn't have a FPI
> after a checkpoint.
>
> (Start server with full_page_writes = off)
> CREATE TABLE t (a int);
> CHECKPOINT;
> INSERT INTO t V
I noticed that the previous patch is a mixture with another
patch.. sorry.
At Thu, 19 Apr 2018 19:11:43 +0530, Amit Kapila wrote
in
> On Thu, Apr 19, 2018 at 7:19 AM, Michael Paquier wrote:
> > On Wed, Apr 18, 2018 at 10:52:51AM -0400, Robert Haas wrote:
> >> I would just document the risks.
By the way, I think I found a bug of FPW.
The following steps yields INSERT record that doesn't have a FPI
after a checkpoint.
(Start server with full_page_writes = off)
CREATE TABLE t (a int);
CHECKPOINT;
INSERT INTO t VALUES (1);
ALTER SYSTEM SET full_page_writes TO on;
SELECT pg_reload_conf();
On Thu, Apr 19, 2018 at 07:11:43PM +0530, Amit Kapila wrote:
> On Thu, Apr 19, 2018 at 7:19 AM, Michael Paquier wrote:
>> And, er, actually, I was thinking again about the case where a user
>> wants to disable full_page_writes temporarily to do some bulk load and
>> then re-enable it. With the pa
On Thu, Apr 19, 2018 at 7:19 AM, Michael Paquier wrote:
> On Wed, Apr 18, 2018 at 10:52:51AM -0400, Robert Haas wrote:
>> I would just document the risks. If the documentation says that you
>> can't rely on the value until after the next checkpoint, or whatever
>> the rule is, then I think we're
On Wed, Apr 18, 2018 at 10:52:51AM -0400, Robert Haas wrote:
> I would just document the risks. If the documentation says that you
> can't rely on the value until after the next checkpoint, or whatever
> the rule is, then I think we're fine. I don't think that we really
> have the infrastructure
On Wed, Apr 18, 2018 at 10:37 AM, Amit Kapila wrote:
> On Fri, Apr 13, 2018 at 10:36 PM, Robert Haas wrote:
>> On Thu, Apr 12, 2018 at 9:29 PM, Michael Paquier wrote:
>>> Still does it matter when the change is effective?
>>
>> I don't really care deeply about when the change takes effect, but I
On Fri, Apr 13, 2018 at 10:36 PM, Robert Haas wrote:
> On Thu, Apr 12, 2018 at 9:29 PM, Michael Paquier wrote:
>> Still does it matter when the change is effective?
>
> I don't really care deeply about when the change takes effect, but I
> do care about whether the time when the system *says* the
On Thu, Apr 12, 2018 at 9:29 PM, Michael Paquier wrote:
> Still does it matter when the change is effective?
I don't really care deeply about when the change takes effect, but I
do care about whether the time when the system *says* the change took
effect is the same as when it *actually* took eff
Sorry, the patch attached to the previous main is slightly
old. The attached is the correct one.
# They differ only in some phrase in a comment.
At Fri, 13 Apr 2018 17:28:40 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180413.172840.228724367.horiguchi.kyot...@lab.ntt.co.jp>
At Fri, 13 Apr 2018 13:47:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180413.134751.76149471.horiguchi.kyot...@lab.ntt.co.jp>
> At Fri, 13 Apr 2018 08:31:02 +0530, Amit Kapila
> wrote in
> > On Fri, Apr 13, 2018 at 6:59 AM, Michael Paquier
> > wrote:
> > > On Thu, Apr 12,
At Fri, 13 Apr 2018 08:31:02 +0530, Amit Kapila wrote
in
> On Fri, Apr 13, 2018 at 6:59 AM, Michael Paquier wrote:
> > On Thu, Apr 12, 2018 at 02:55:53PM -0400, Robert Haas wrote:
> >> I think it may actually be confusing. If you run pg_ctl reload and it
> >> reports that the value has changed
On Fri, Apr 13, 2018 at 6:59 AM, Michael Paquier wrote:
> On Thu, Apr 12, 2018 at 02:55:53PM -0400, Robert Haas wrote:
>> I think it may actually be confusing. If you run pg_ctl reload and it
>> reports that the value has changed, you'll expect it to have taken
>> effect. But really, it will tak
On Thu, Apr 12, 2018 at 02:55:53PM -0400, Robert Haas wrote:
> I think it may actually be confusing. If you run pg_ctl reload and it
> reports that the value has changed, you'll expect it to have taken
> effect. But really, it will take effect at some later time.
It is true that sometimes some p
On Wed, Apr 11, 2018 at 7:09 AM, Heikki Linnakangas wrote:
> I think the new behavior where the GUC only takes effect at next checkpoint
> is OK. It seems quite intuitive.
I think it may actually be confusing. If you run pg_ctl reload and it
reports that the value has changed, you'll expect it t
On Thu, Apr 12, 2018 at 04:59:10PM +0900, Kyotaro HORIGUCHI wrote:
> At Thu, 12 Apr 2018 14:07:53 +0900, Michael Paquier
> wrote in <20180412050753.ga19...@paquier.xyz>
>> I have been able to spend a couple of hours on your patch, wrapping my
>> mind on your stuff. So what I had in mind was some
Hello.
At Thu, 12 Apr 2018 14:07:53 +0900, Michael Paquier wrote
in <20180412050753.ga19...@paquier.xyz>
> On Thu, Apr 12, 2018 at 10:34:30AM +0900, Kyotaro HORIGUCHI wrote:
> > Checkpointer never calls CreateCheckPoint while
> > RecoveryInProgress() == true. In other words, checkpointer is not
On Thu, Apr 12, 2018 at 10:34:30AM +0900, Kyotaro HORIGUCHI wrote:
> Checkpointer never calls CreateCheckPoint while
> RecoveryInProgress() == true. In other words, checkpointer is not
> an updator of shared FPW at the time StartupXLOG calls
> CreateCheckPoint for fallback_promote.
I have been abl
Hello. Thanks to Heikkit for picking this up and thanks for the
commnet to Michael.
# The attached is changed only in a comment, and rebased.
At Thu, 12 Apr 2018 05:24:14 +0900, Michael Paquier wrote
in <20180411202414.ga32...@paquier.xyz>
> On Wed, Apr 11, 2018 at 02:09:48PM +0300, Heikki Linn
On Wed, Apr 11, 2018 at 02:09:48PM +0300, Heikki Linnakangas wrote:
> I think the new behavior where the GUC only takes effect at next checkpoint
> is OK. It seems quite intuitive.
>
> > [rebased patch version]
>
> Looks good at a quick glance. Assuming no objections from others, I'll take
> a cl
On 09/04/18 11:13, Kyotaro HORIGUCHI wrote:
At Fri, 6 Apr 2018 17:59:58 +0530, Amit Kapila wrote in
On Fri, Apr 6, 2018 at 1:50 PM, Kyotaro HORIGUCHI
wrote:
Hello.
At Wed, 04 Apr 2018 17:26:46 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180404.172646.238325981.horiguchi.
At Fri, 6 Apr 2018 17:59:58 +0530, Amit Kapila wrote
in
> On Fri, Apr 6, 2018 at 1:50 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello.
> >
> > At Wed, 04 Apr 2018 17:26:46 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> > wrote in
> > <20180404.172646.238325981.horiguchi.kyot...@lab.ntt.co.jp>
>
On Fri, Apr 6, 2018 at 1:50 PM, Kyotaro HORIGUCHI
wrote:
> Hello.
>
> At Wed, 04 Apr 2018 17:26:46 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20180404.172646.238325981.horiguchi.kyot...@lab.ntt.co.jp>
>> > In general, I was wondering why in the first place this variable
>> > (
Hello.
At Wed, 04 Apr 2018 17:26:46 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180404.172646.238325981.horiguchi.kyot...@lab.ntt.co.jp>
> > In general, I was wondering why in the first place this variable
> > (full_page_writes) is a SIGHUP variable? I think if the user tries to
At Sat, 31 Mar 2018 17:43:58 +0530, Amit Kapila wrote
in
> On Wed, Mar 28, 2018 at 12:10 PM, Kyotaro HORIGUCHI
> wrote:
> > At Tue, 27 Mar 2018 22:02:26 +0900, Michael Paquier
> > wrote in <20180327130226.ga1...@paquier.xyz>
> >> On Tue, Mar 27, 2018 at 09:01:20PM +0900, Kyotaro HORIGUCHI wro
On Wed, Mar 28, 2018 at 12:10 PM, Kyotaro HORIGUCHI
wrote:
> At Tue, 27 Mar 2018 22:02:26 +0900, Michael Paquier
> wrote in <20180327130226.ga1...@paquier.xyz>
>> On Tue, Mar 27, 2018 at 09:01:20PM +0900, Kyotaro HORIGUCHI wrote:
>> > The current UpdateFullPageWrites is safe on standby and promo
At Wed, 28 Mar 2018 15:59:48 +0900, Michael Paquier wrote
in <20180328065948.gm1...@paquier.xyz>
> On Wed, Mar 28, 2018 at 03:40:59PM +0900, Kyotaro HORIGUCHI wrote:
> > The attached does that. I don't like that it uses ControlFileLock
> > to exlucde concurrent UpdateFullPageWrites and StartupXLO
On Wed, Mar 28, 2018 at 03:40:59PM +0900, Kyotaro HORIGUCHI wrote:
> The attached does that. I don't like that it uses ControlFileLock
> to exlucde concurrent UpdateFullPageWrites and StartupXLOG but
> WALInsertLock cannot be used since UpdateFullPageWrites may take
> the same lock.
You visibly fo
At Tue, 27 Mar 2018 22:02:26 +0900, Michael Paquier wrote
in <20180327130226.ga1...@paquier.xyz>
> On Tue, Mar 27, 2018 at 09:01:20PM +0900, Kyotaro HORIGUCHI wrote:
> > The current UpdateFullPageWrites is safe on standby and promotion
> > so what we should consider is only the non-standby case.
On Tue, Mar 27, 2018 at 09:01:20PM +0900, Kyotaro HORIGUCHI wrote:
> The current UpdateFullPageWrites is safe on standby and promotion
> so what we should consider is only the non-standby case. I think
> what we should do is just calling RecoveryInProgress() at the
> beginning of CheckPointerMain,
At Tue, 27 Mar 2018 16:46:30 +0900, Michael Paquier wrote
in <20180327074630.gd9...@paquier.xyz>
> I have finally been able to spend more time on this issue, and checked
> for a couple of hours all the calls to RecoveryInProgress() that could
> be triggered within a critical section to see if the
On Mon, Mar 26, 2018 at 02:32:22PM +0530, Dilip Kumar wrote:
> On Fri, Mar 23, 2018 at 1:19 PM, Michael Paquier
> wrote:
> In StartupXLOG, just before the CreateCheckPoint() call, we are calling
> LocalSetXLogInsertAllowed(). So, I am thinking can we just remove
> InitXLogInsert from CreateCheck
On Fri, Mar 23, 2018 at 1:19 PM, Michael Paquier
wrote:
> On Tue, Mar 20, 2018 at 12:00:47PM +0530, Dilip Kumar wrote:
> > Yeah, you are right. Fixed.
>
> So I have been spending a couple of hours playing with your patch, and
> tested various configurations manually, like switch the fpw switch t
On Tue, Mar 20, 2018 at 12:00:47PM +0530, Dilip Kumar wrote:
> Yeah, you are right. Fixed.
So I have been spending a couple of hours playing with your patch, and
tested various configurations manually, like switch the fpw switch to on
and off while running in parallel pgbench. I have also tested
On Tue, Mar 20, 2018 at 11:26 AM, Michael Paquier
wrote:
> On Tue, Mar 20, 2018 at 10:43:55AM +0530, Dilip Kumar wrote:
> > I think like WALWriterProcess, we need to call InitXLogInsert for the
> > CheckpointerProcess as well as for the BgWriterProcess
> > because earlier they were calling InitXL
On Tue, Mar 20, 2018 at 10:43:55AM +0530, Dilip Kumar wrote:
> I think like WALWriterProcess, we need to call InitXLogInsert for the
> CheckpointerProcess as well as for the BgWriterProcess
> because earlier they were calling InitXLogInsert while check
> RecoveryInProgress before inserting the WAL.
On Fri, Mar 16, 2018 at 10:53 AM, Michael Paquier
wrote:
> On Tue, Mar 13, 2018 at 05:04:04PM +0900, Michael Paquier wrote:
> > Instead of doing what you are suggesting, why not moving
> > InitXLogInsert() out of InitXLOGAccess() and change InitPostgres() so as
> > the allocations for WAL inserts
On Tue, Mar 13, 2018 at 05:04:04PM +0900, Michael Paquier wrote:
> Instead of doing what you are suggesting, why not moving
> InitXLogInsert() out of InitXLOGAccess() and change InitPostgres() so as
> the allocations for WAL inserts is done unconditionally? This has
> the cost of also making this
On Fri, Mar 09, 2018 at 01:42:04PM +0530, Dilip Kumar wrote:
> While setting the full_page_write with SIGHUP I hit an assert in checkpoint
> process. And, that is because inside a CRITICAL section we are calling
> RecoveryInProgress which intern allocates memory. So I have moved
> RecoveryInProgre
While setting the full_page_write with SIGHUP I hit an assert in checkpoint
process. And, that is because inside a CRITICAL section we are calling
RecoveryInProgress which intern allocates memory. So I have moved
RecoveryInProgress call out of the CRITICAL section and the problem got
solved.
comm
75 matches
Mail list logo
