Alvaro Herrera writes:
> However, we already have a large number of proc_exit() calls in switch
> blocks that are not followed by breaks. In fact, the majority are
> already like that.
Oh, hmm ... consistency is good.
regards, tom lane
On 2020-Jan-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > In modern times, we define pg_attribute_noreturn() like this:
>
> > /* GCC, Sunpro and XLC support aligned, packed and noreturn */
> > #if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
> > #define
Alvaro Herrera writes:
> In modern times, we define pg_attribute_noreturn() like this:
> /* GCC, Sunpro and XLC support aligned, packed and noreturn */
> #if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
> #define pg_attribute_noreturn() __attribute__((noreturn))
> #define
On 2019-Nov-12, Andres Freund wrote:
> We still have the curious
> proc_exit(0);
> abort();/* keep the compiler
> quiet */
>
> pattern in WalSndShutdown() - wouldn't the right approach to instead
> proc_exit() with pg_attribute_noreturn()?
At Wed, 13 Nov 2019 14:21:13 +0530, Amit Kapila wrote
in
> On Wed, Nov 13, 2019 at 12:57 AM Andres Freund wrote:
> >
> > On 2019-11-11 13:53:40 -0300, Alvaro Herrera wrote:
> >
> > > /* Get a more recent flush pointer. */
> > > if (!RecoveryInProgress())
> > >
On Wed, Nov 13, 2019 at 12:57 AM Andres Freund wrote:
>
> On 2019-11-11 13:53:40 -0300, Alvaro Herrera wrote:
>
> > /* Get a more recent flush pointer. */
> > if (!RecoveryInProgress())
> > RecentFlushPtr = GetFlushRecPtr();
> > else
> >
Ah, my stupid.
At Wed, 13 Nov 2019 16:34:49 +0900, Michael Paquier wrote
in
> On Tue, Nov 12, 2019 at 11:27:16AM -0800, Andres Freund wrote:
> > It seems to me it'd be better to just remove the "get a more recent
> > flush pointer" block - it doesn't seem to currently surve a meaningful
> >
On Tue, Nov 12, 2019 at 11:27:16AM -0800, Andres Freund wrote:
> It seems to me it'd be better to just remove the "get a more recent
> flush pointer" block - it doesn't seem to currently surve a meaningful
> purpose.
+1. That was actually my suggestion upthread :)
--
Michael
signature.asc
Hi,
On 2019-11-11 13:53:40 -0300, Alvaro Herrera wrote:
> On 2019-Nov-11, Amit Kapila wrote:
>
> > On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier wrote:
>
> > > So your suggestion would be to call GetFlushRecPtr() before the first
> > > check on RecentFlushPtr and before entering the loop?
>
On Tue, Nov 12, 2019 at 7:47 AM Michael Paquier wrote:
>
> On Mon, Nov 11, 2019 at 01:53:40PM -0300, Alvaro Herrera wrote:
> > On 2019-Nov-11, Amit Kapila wrote:
> >
> >> On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier
> >> wrote:
> >>> So your suggestion would be to call GetFlushRecPtr()
At Tue, 12 Nov 2019 11:17:26 +0900, Michael Paquier wrote
in
> On Mon, Nov 11, 2019 at 01:53:40PM -0300, Alvaro Herrera wrote:
> > On 2019-Nov-11, Amit Kapila wrote:
> >
> >> On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier
> >> wrote:
> >>> So your suggestion would be to call
On Mon, Nov 11, 2019 at 01:53:40PM -0300, Alvaro Herrera wrote:
> On 2019-Nov-11, Amit Kapila wrote:
>
>> On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier wrote:
>>> So your suggestion would be to call GetFlushRecPtr() before the first
>>> check on RecentFlushPtr and before entering the loop?
>>
On 2019-Nov-11, Amit Kapila wrote:
> On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier wrote:
> > So your suggestion would be to call GetFlushRecPtr() before the first
> > check on RecentFlushPtr and before entering the loop?
>
> No. What I meant was to keep the current code as-is and have an
>
On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier wrote:
>
> On Sun, Nov 10, 2019 at 10:43:33AM +0530, Amit Kapila wrote:
> > On Sun, Nov 10, 2019 at 5:51 AM Jeff Janes wrote:
> >> in src/backend/replication/walsender.c, there is the section
> >> quoted below. It looks like nothing interesting
On Sun, Nov 10, 2019 at 10:43:33AM +0530, Amit Kapila wrote:
> On Sun, Nov 10, 2019 at 5:51 AM Jeff Janes wrote:
>> in src/backend/replication/walsender.c, there is the section
>> quoted below. It looks like nothing interesting happens between
>> the GetFlushRecPtr just before the loop starts,
On Sun, Nov 10, 2019 at 5:51 AM Jeff Janes wrote:
>
> in src/backend/replication/walsender.c, there is the section quoted below.
> It looks like nothing interesting happens between the GetFlushRecPtr just
> before the loop starts, and the one inside the loop the first time through
> the loop.
in src/backend/replication/walsender.c, there is the section quoted below.
It looks like nothing interesting happens between the GetFlushRecPtr just
before the loop starts, and the one inside the loop the first time through
the loop. If we want to avoid doing CHECK_FOR_INTERRUPTS(); etc.
17 matches
Mail list logo
