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 pg_attribute_noreturn(
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 HAVE_PG
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()?
pro
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())
> > > RecentFl
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
> > RecentFlushPtr
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
> > pur
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
Descr
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() before
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 GetFlushRecPtr()
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 hap
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, an
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.
needless
17 matches
Mail list logo
