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.
16 matches
Mail list logo
