Re: snapper vs. HEAD

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgbf(at)twiska(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: snapper vs. HEAD
Date: 2020-03-30 00:25:32
Message-ID: 14239.1585527932@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2020-03-28 23:50:32 -0400, Tom Lane wrote:
>> ... Curiously, its sibling
>> skate is *not* failing, despite being on the same machine and compiler.

> Hm. There's some difference in code-gen specific options.

Yeah, I confirmed that on my VM install too: using our typical codegen
options (just -O2 -g), the regression tests pass, matching skate's
results. It fell over after I matched snapper's CFLAGS, CPPFLAGS,
and LDFLAGS. I didn't try to break things down more finely as to
which option(s) trigger the bad code, since it looks like it's probably
some purely-internal compiler state ...

> What options were you using? Reproducing snapper as exactly as possible?

Yeah, see above.

> If you still have the environment it might make sense to check wether
> it's related to one of the other options. But otherwise I wouldn't be
> against the proposal.

I could, but it's mighty slow, so I don't especially want to try all 2^N
combinations. Do you have any specific cases in mind?

(I guess we can exclude LDFLAGS, since the assembly output is visibly
bad.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-03-30 00:29:45 Re: shared-memory based stats collector
Previous Message Andres Freund 2020-03-29 23:22:03 Re: DROP DATABASE doesn't force other backends to close FDs