Hi,
On 2022-09-14 01:02:39 -0400, Tom Lane wrote:
> John Naylor writes:
> > If we're going to go to this length, it seems more straightforward to
> > just check the .c/.h files into version control, like every other
> > project that I have such knowledge of.
>
> Strong -1 on that, because then
On Thu, Sep 15, 2022 at 04:53:09PM +1200, Thomas Munro wrote:
> Not sure it's OK to put random junk in ccache's directory, and in any
> case we'd certainly want to teach it to trim itself before doing that
> on CI...
> I suppose a version good enough to live in src/tools would need to
> trim the
On Wed, Sep 14, 2022 at 4:34 PM Justin Pryzby wrote:
> On Wed, Sep 14, 2022 at 03:08:06PM +1200, Thomas Munro wrote:
> > On Wed, Sep 14, 2022 at 10:23 AM Thomas Munro
> > wrote:
> > > Given the simplicity of this case, though, I suppose we could
> > > have a little not-very-general
John Naylor writes:
> If we're going to go to this length, it seems more straightforward to
> just check the .c/.h files into version control, like every other
> project that I have such knowledge of.
Strong -1 on that, because then we'd have to mandate that every
committer use exactly the same
On Wed, Sep 14, 2022 at 5:24 AM Thomas Munro wrote:
>
> On Tue, Sep 6, 2022 at 9:34 AM Tom Lane wrote:
> > Peter Eisentraut writes:
> > > Why is this being proposed?
> >
> > Andres is annoyed by the long build time of ecpg, which he has to
> > wait for whether he wants to test it or not. I
On Wed, Sep 14, 2022 at 03:08:06PM +1200, Thomas Munro wrote:
> On Wed, Sep 14, 2022 at 10:23 AM Thomas Munro wrote:
> > Given the simplicity of this case, though, I suppose we could
> > have a little not-very-general shell/python/whatever wrapper script --
> > just compute a checksum of the
On Wed, Sep 14, 2022 at 10:23 AM Thomas Munro wrote:
> Given the simplicity of this case, though, I suppose we could
> have a little not-very-general shell/python/whatever wrapper script --
> just compute a checksum of the input and keep the output files around.
Something as dumb as this
On Tue, Sep 6, 2022 at 9:34 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > Why is this being proposed?
>
> Andres is annoyed by the long build time of ecpg, which he has to
> wait for whether he wants to test it or not. I could imagine that
> I might disable ecpg testing on my slowest
On Wed, Sep 7, 2022 at 1:45 PM Peter Eisentraut
wrote:
>
> On 05.09.22 23:34, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> Why is this being proposed?
> >
> > Andres is annoyed by the long build time of ecpg, which he has to
> > wait for whether he wants to test it or not. I could imagine
On 05.09.22 23:34, Tom Lane wrote:
Peter Eisentraut writes:
Why is this being proposed?
Andres is annoyed by the long build time of ecpg, which he has to
wait for whether he wants to test it or not. I could imagine that
I might disable ecpg testing on my slowest buildfarm animals, too.
I
Peter Eisentraut writes:
> Why is this being proposed?
Andres is annoyed by the long build time of ecpg, which he has to
wait for whether he wants to test it or not. I could imagine that
I might disable ecpg testing on my slowest buildfarm animals, too.
I suppose maybe we could compromise on
Hi,
On 2022-09-05 22:52:03 +0200, Peter Eisentraut wrote:
> On 04.09.22 16:55, Tom Lane wrote:
> > I guess we could proceed like this:
> >
> > 1. Invent the --with option. Temporarily make "make check" in ecpg
> > print a message but not fail if the option wasn't selected.
> >
> > 2. Update
On 04.09.22 16:55, Tom Lane wrote:
I guess we could proceed like this:
1. Invent the --with option. Temporarily make "make check" in ecpg
print a message but not fail if the option wasn't selected.
2. Update buildfarm client to recognize the option and skip ecpg-check
if not selected.
3.
On Sun, Sep 04, 2022 at 10:55:43AM -0400, Tom Lane wrote:
> There'd need to be a separate discussion around how much to
> encourage buildfarm owners to add --with-ecpg to their
> configurations. One thing that would make that easier is
> adding --with-ecpg as a no-op option to the back branches,
Andrew Dunstan writes:
> On 2022-09-04 Su 09:56, Tom Lane wrote:
>> You would need to make the ecpg-check step
>> conditional, though, so it's moot: we'd have to fix the buildfarm
>> first in any case, unless it's default-enabled which would seem
>> a bit odd.
> *nod*
I guess we could proceed
On 2022-09-04 Su 09:56, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-09-02 Fr 13:56, Tom Lane wrote:
>>> ... However, those aren't arguments against
>>> making it optional-to-build like the PLs are.
>> That seems reasonable. Note that the buildfarm client would then need an
>> extra
Andrew Dunstan writes:
> On 2022-09-02 Fr 13:56, Tom Lane wrote:
>> ... However, those aren't arguments against
>> making it optional-to-build like the PLs are.
> That seems reasonable. Note that the buildfarm client would then need an
> extra build step.
Not sure why there'd be an extra build
On 2022-09-02 Fr 13:56, Tom Lane wrote:
> Andres Freund writes:
>> I also wonder if we shouldn't just make ecpg optional at some point. Or even
>> move it out of the tree.
> The reason it's in the tree is to ensure its grammar stays in sync
> with the core grammar, and perhaps more to the
Andres Freund writes:
> I also wonder if we shouldn't just make ecpg optional at some point. Or even
> move it out of the tree.
The reason it's in the tree is to ensure its grammar stays in sync
with the core grammar, and perhaps more to the point, that it's
possible to build its grammar at all.
Hi,
On 2022-08-07 14:47:36 +0700, John Naylor wrote:
> Playing around with the compiler flags on preproc.c, I get these
> compile times, gcc memory usage as reported by /usr/bin/time -v , and
> symbol sizes (non-debug build):
>
> -O2:
> time 8.0s
> Maximum resident set size (kbytes): 255884
>
>
Hi,
On 2022-08-08 11:14:58 -0400, Andrew Dunstan wrote:
> I'm waiting for that first commit so I can start working on the
> buildfarm client changes. Ideally (from my POV) this would happen by
> early Sept when I will be leaving on a trip for some weeks, and this
> would be a good project to take
On 2022-08-07 Su 02:46, Andres Freund wrote:
>
>> I think if we want to get this past the finish line, we need to
>> acknowledge that the initial commit isn't going to be perfect.
>> The whole point of continuing to maintain the Makefiles is to
>> give us breathing room to fix remaining issues
On Sun, Aug 7, 2022 at 7:05 AM Tom Lane wrote:
> Even on a modern Linux:
>
> $ size src/backend/parser/gram.o
>textdata bss dec hex filename
> 656568 0 0 656568 a04b8 src/backend/parser/gram.o
> $ size src/interfaces/ecpg/preproc/preproc.o
>textdata
Hi,
On 2022-08-07 01:17:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-08-06 22:55:14 -0400, Tom Lane wrote:
> >> IMO, it'd be entirely reasonable for Andres to say that *he* doesn't
> >> want to fix the meson build scripts for niche platform X. Then
> >> it'd be up to people who
Andres Freund writes:
> On 2022-08-06 22:55:14 -0400, Tom Lane wrote:
>> IMO, it'd be entirely reasonable for Andres to say that *he* doesn't
>> want to fix the meson build scripts for niche platform X. Then
>> it'd be up to people who care about platform X to make that happen.
>> Given the
On Sat, Aug 06, 2022 at 08:12:54PM -0700, Andres Freund wrote:
> The "problem" in this case is that maintaining pgxs compatibility, as we'd
> discussed at pgcon, requires emitting stuff for all the @whatever@ things in
> Makefile.global.in, including with_gnu_ld. Which lead me down the rabbithole
Hi,
On 2022-08-06 22:55:14 -0400, Tom Lane wrote:
> IMO, it'd be entirely reasonable for Andres to say that *he* doesn't
> want to fix the meson build scripts for niche platform X. Then
> it'd be up to people who care about platform X to make that happen.
> Given the current plan of supporting
Noah Misch writes:
> On Sat, Aug 06, 2022 at 06:09:27PM -0700, Andres Freund wrote:
>> And it's not a cost free thing to support, e.g. I tried to build because
>> solaris with suncc forces me to generate with_gnu_ld when generating a
>> compatible Makefile.global for pgxs with meson.
> There may
On Sat, Aug 06, 2022 at 06:09:27PM -0700, Andres Freund wrote:
> On 2022-08-06 17:59:54 -0700, Noah Misch wrote:
> > On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote:
> > > Sure, we can hack around it in some way. But if we need such hackery to
> > > compile postgres with a compiler,
Noah Misch writes:
> On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote:
>> Sure, we can hack around it in some way. But if we need such hackery to
>> compile postgres with a compiler, what's the point of supporting that
>> compiler? It's not like sunpro provides with awesome static
On 2022-08-06 17:59:54 -0700, Noah Misch wrote:
> On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote:
> > Sure, we can hack around it in some way. But if we need such hackery to
> > compile postgres with a compiler, what's the point of supporting that
> > compiler? It's not like sunpro
On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote:
> On 2022-08-06 17:25:52 -0700, Noah Misch wrote:
> > On Sat, Aug 06, 2022 at 08:05:14PM -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > Yikes. And it's not like newer compiler versions are likely to be
> > > > forthcoming
Hi,
On 2022-08-06 17:25:52 -0700, Noah Misch wrote:
> On Sat, Aug 06, 2022 at 08:05:14PM -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Yikes. And it's not like newer compiler versions are likely to be
> > > forthcoming
> > > (12.6 is newest and is from 2017...). Wonder if we should
Hi,
On 2022-08-06 20:05:14 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-08-06 16:09:24 -0700, Noah Misch wrote:
> >> From the earliest days of wrasse, the compiler used too much RAM to build
> >> preproc.o with --enable-debug. As of 2021-04, the compiler's "acomp" phase
> >>
On Sat, Aug 06, 2022 at 08:05:14PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-08-06 16:09:24 -0700, Noah Misch wrote:
> >> From the earliest days of wrasse, the compiler used too much RAM to build
> >> preproc.o with --enable-debug. As of 2021-04, the compiler's "acomp" phase
>
On Sun, Aug 7, 2022 at 11:52 AM Andres Freund wrote:
> Yikes. And it's not like newer compiler versions are likely to be forthcoming
> (12.6 is newest and is from 2017...). Wonder if we should just require gcc on
> solaris... There's a decent amount of stuff we could rip out in that case.
Andres Freund writes:
> On 2022-08-06 16:09:24 -0700, Noah Misch wrote:
>> From the earliest days of wrasse, the compiler used too much RAM to build
>> preproc.o with --enable-debug. As of 2021-04, the compiler's "acomp" phase
>> needed 10G in one process, and later phases needed 11.6G across
Hi,
On 2022-08-06 16:09:24 -0700, Noah Misch wrote:
> On Sat, Aug 06, 2022 at 02:07:24PM -0700, Andres Freund wrote:
> > I tried PG on the gcc compile farm solaris 11.31 host. When compiling with
> > sun
> > studio I can build the backend etc, but preproc.c fails to compile:
> >
> > ccache
On Sat, Aug 06, 2022 at 02:07:24PM -0700, Andres Freund wrote:
> I tried PG on the gcc compile farm solaris 11.31 host. When compiling with sun
> studio I can build the backend etc, but preproc.c fails to compile:
>
> ccache /opt/developerstudio12.6/bin/cc -m64 -Xa -g -v -O0
>
39 matches
Mail list logo
