On Fri, Sep 16, 2022 at 1:55 AM Tom Lane wrote:
> John Naylor writes:
> > On Thu, Sep 15, 2022 at 3:11 PM Ibrar Ahmed wrote:
> >> The patch does not apply successfully; please rebase the patch.
>
> > There's a good reason for that -- the latest one was committed two
> > weeks ago. The status
John Naylor writes:
> On Thu, Sep 15, 2022 at 3:11 PM Ibrar Ahmed wrote:
>> The patch does not apply successfully; please rebase the patch.
> There's a good reason for that -- the latest one was committed two
> weeks ago. The status should still be waiting on author, though,
> namely for:
> On
On Thu, Sep 15, 2022 at 3:11 PM Ibrar Ahmed wrote:
> The patch does not apply successfully; please rebase the patch.
There's a good reason for that -- the latest one was committed two
weeks ago. The status should still be waiting on author, though,
namely for:
On Fri, Aug 26, 2022 at 5:28 AM
On Mon, Aug 29, 2022 at 3:13 AM Thomas Munro wrote:
> On Mon, Aug 29, 2022 at 9:40 AM Tom Lane wrote:
> > Here's another bit of baggage handling: fixing up the places that
> > were afraid to use fflush(NULL). We could doubtless have done
> > this years ago (indeed, I found several places
On Mon, Aug 29, 2022 at 9:40 AM Tom Lane wrote:
> Here's another bit of baggage handling: fixing up the places that
> were afraid to use fflush(NULL). We could doubtless have done
> this years ago (indeed, I found several places already using it)
> but as long as we're making a push to get rid
Here's another bit of baggage handling: fixing up the places that
were afraid to use fflush(NULL). We could doubtless have done
this years ago (indeed, I found several places already using it)
but as long as we're making a push to get rid of obsolete code,
doing it now seems appropriate.
One
On Fri, Aug 26, 2022 at 7:47 AM Andres Freund wrote:
> On 2022-08-18 18:13:38 +1200, Thomas Munro wrote:
> > Here's a slightly better AF_INET6 one. I'm planning to push it
> > tomorrow if there are no objections.
>
> You didn't yet, I think. Any chance you could? The HAVE_IPV6 stuff is
>
Hi,
On 2022-08-18 18:13:38 +1200, Thomas Munro wrote:
> Here's a slightly better AF_INET6 one. I'm planning to push it
> tomorrow if there are no objections.
You didn't yet, I think. Any chance you could? The HAVE_IPV6 stuff is
wrong/ugly in the meson build, right now, and I'd rather not spend
On Sun, Aug 14, 2022 at 6:07 AM Tom Lane wrote:
> Thomas Munro writes:
> > I tried to figure out how to get rid of
> > PGAC_STRUCT_SOCKADDR_STORAGE_MEMBERS, but there we're into genuine
> > non-standard cross-platform differences.
>
> Right. I don't think it's worth sweating over.
I managed to
On Tue, Aug 16, 2022 at 4:14 PM Thomas Munro wrote:
> On Tue, Aug 16, 2022 at 1:16 PM Andres Freund wrote:
> > > But let's suppose we want to play by a timid interpretation of that page's
> > > "do not issue low-level or STDIO.H I/O routines". It also says that
> > > SIGINT
> > > is special
On Mon, Aug 15, 2022 at 5:53 PM Thomas Munro wrote:
> Remove configure probe for IPv6.
> Remove dead ifaddrs.c fallback code.
> Remove configure probe for net/if.h.
> Fix macro problem with gai_strerror on Windows.
> Remove configure probe for netinet/tcp.h.
> mstcpip.h is not missing
On Tue, Aug 16, 2022 at 1:16 PM Andres Freund wrote:
> > But let's suppose we want to play by a timid interpretation of that page's
> > "do not issue low-level or STDIO.H I/O routines". It also says that SIGINT
> > is special and runs the handler in a new thread (in a big warning box
> > because
Hi,
On 2022-08-16 13:02:55 +1200, Thomas Munro wrote:
> On Fri, Aug 12, 2022 at 7:42 PM Thomas Munro wrote:
> > On Fri, Aug 12, 2022 at 5:14 AM Andres Freund wrote:
> > > I don't really know what to do about the warnings around remove_temp() and
> > > trapsig(). I think we actually may be
On Fri, Aug 12, 2022 at 7:42 PM Thomas Munro wrote:
> On Fri, Aug 12, 2022 at 5:14 AM Andres Freund wrote:
> > I don't really know what to do about the warnings around remove_temp() and
> > trapsig(). I think we actually may be overreading the restrictions. To me
> > the
> > documented
On Tue, Aug 16, 2022 at 7:51 AM Thomas Munro wrote:
> [1] https://cirrus-ci.com/task/4643322672185344?logs=main#L16
Derp, I noticed that that particular horrendous quick and dirty test
code was invalidated by a closesocket() call, but in another version I
commented that out and it didn't help.
On Tue, Aug 16, 2022 at 7:25 AM Andres Freund wrote:
> On 2022-08-15 13:48:22 +1200, Thomas Munro wrote:
> > 2022-08-13 20:44:35.174 GMT [4760][postmaster] LOG: listening on Unix
> > socket "@c:/cirrus/.s.PGSQL.61696"
>
> What I find odd is that you said your naive program rejected this...
No,
Hi,
On 2022-08-15 13:48:22 +1200, Thomas Munro wrote:
> On Sun, Aug 14, 2022 at 10:36 AM Andres Freund wrote:
> > On 2022-08-14 10:03:19 +1200, Thomas Munro wrote:
> > > I hadn't paid attention to our existing abstract Unix socket support
> > > before and now I'm curious: do we have a confirmed
On Mon, Aug 15, 2022 at 8:36 PM Peter Eisentraut
wrote:
> On 15.08.22 03:48, Thomas Munro wrote:
> >> I vaguely remember successfully trying it in the past. But I just tried it
> >> unsuccessfully in a VM and there's a bunch of other places saying it's not
> >> working...
> >>
On 15.08.22 03:48, Thomas Munro wrote:
I vaguely remember successfully trying it in the past. But I just tried it
unsuccessfully in a VM and there's a bunch of other places saying it's not
working...
https://github.com/microsoft/WSL/issues/4240
I think we'd better remove our claim that it works
On Sun, Aug 14, 2022 at 10:03 AM Thomas Munro wrote:
> All green on CI... Next stop, build farm.
All good so far (except for an admonishment from crake, for which my
penance was to fix headerscheck, see separate thread...). I did
figure out one thing that I mentioned I was confused by before:
On Sun, Aug 14, 2022 at 10:36 AM Andres Freund wrote:
> On 2022-08-14 10:03:19 +1200, Thomas Munro wrote:
> > I hadn't paid attention to our existing abstract Unix socket support
> > before and now I'm curious: do we have a confirmed sighting of that
> > working on Windows?
>
> I vaguely remember
Hi,
On 2022-08-14 10:03:19 +1200, Thomas Munro wrote:
> I hadn't paid attention to our existing abstract Unix socket support
> before and now I'm curious: do we have a confirmed sighting of that
> working on Windows?
I vaguely remember successfully trying it in the past. But I just tried it
On Sun, Aug 14, 2022 at 6:07 AM Tom Lane wrote:
> Thomas Munro writes:
> > I pushed these, except I chopped out the HAVE_UNIX_SOCKETS part as
> > requested. Here it is in a separate patch, with a commit message that
> > explains the rationale (essentially, what you said, it's basically a
> >
Thomas Munro writes:
> I pushed these, except I chopped out the HAVE_UNIX_SOCKETS part as
> requested. Here it is in a separate patch, with a commit message that
> explains the rationale (essentially, what you said, it's basically a
> runtime matter for a hypothetical AF_UNIX-less system to
On Sun, Aug 14, 2022 at 12:23 AM Thomas Munro wrote:
> Remove HAVE_UNIX_SOCKETS.
> Remove configure probe for struct sockaddr_storage.
> Remove configure probe for getaddrinfo, and replacement code.
Plus one more that falls out of the above (it was only used by
src/port/getaddrinfo.c):
On Fri, Aug 12, 2022 at 8:03 PM Thomas Munro wrote:
> On Fri, Aug 12, 2022 at 7:15 PM Peter Eisentraut
> wrote:
> > But maybe it would be better to make that a separate patch from the
> > sys/un.h configure changes, just so there is more clarity around it.
>
> Cool, I'll do that.
I pushed
Thomas Munro writes:
> I'm curious, though... if we used compiler builtins, would
> -march/-mcpu etc know about this kind of thing, for people who wanted
> to compile on ancient hardware, or, I guess more interestingly, newer
> tricks that we haven't got around to learning about yet?
No idea,
On Sat, Aug 13, 2022 at 8:08 AM Tom Lane wrote:
> I wrote:
> > I see that prairiedog was the only buildfarm animal failing the
> > HAVE_PPC_LWARX_MUTEX_HINT test, and it seems pretty unlikely that
> > there are any assemblers remaining in the wild that can't parse that.
>
> Actually, after
I wrote:
> I see that prairiedog was the only buildfarm animal failing the
> HAVE_PPC_LWARX_MUTEX_HINT test, and it seems pretty unlikely that
> there are any assemblers remaining in the wild that can't parse that.
Actually, after further investigation and testing, I think we could
drop the
Continuing the project of removing dead configure tests ...
I see that prairiedog was the only buildfarm animal failing the
HAVE_PPC_LWARX_MUTEX_HINT test, and it seems pretty unlikely that
there are any assemblers remaining in the wild that can't parse that.
(I've confirmed that
On Fri, Aug 12, 2022 at 7:15 PM Peter Eisentraut
wrote:
> On 11.08.22 12:02, Thomas Munro wrote:
> > * The concept of a no-Unix-socket build is removed. We should be
> > able to do that now, right? Peter E seemed to say approximately that
> > in the commit message for 797129e5. Or is there a
On Fri, Aug 12, 2022 at 5:14 AM Andres Freund wrote:
> On 2022-08-11 10:52:51 -0400, Tom Lane wrote:
> > Thomas Munro writes:
> > > The most interesting things to say about these ones are:
> > > * The concept of a no-Unix-socket build is removed. We should be
> > > able to do that now, right?
On 11.08.22 12:02, Thomas Munro wrote:
* The concept of a no-Unix-socket build is removed. We should be
able to do that now, right? Peter E seemed to say approximately that
in the commit message for 797129e5. Or is there a thought that a new
operating system might show up that doesn't have
On Thu, Aug 4, 2022 at 11:09 AM Tom Lane wrote:
>
> clock_gettime is required by SUSv2 (1997), so I have to admit that
> macOS 10.4 doesn't have a lot of excuse not to have it. In any case,
> prairiedog is just sitting there doing its thing until I find cycles
> to install a newer OS. If you
On 11.08.22 19:19, Tom Lane wrote:
Andres Freund writes:
On 2022-08-11 10:52:51 -0400, Tom Lane wrote:
-- I won't be too surprised if we get pushback on that after 15.0 is out.
From what angle?
If I knew that, it'd be because we'd already received the pushback.
I'm just suspicious that
Andres Freund writes:
> On 2022-08-11 10:52:51 -0400, Tom Lane wrote:
>> -- I won't be too surprised if we get pushback on that after 15.0 is out.
> From what angle?
If I knew that, it'd be because we'd already received the pushback.
I'm just suspicious that very little beta testing happens on
Hi,
On 2022-08-11 10:52:51 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > The most interesting things to say about these ones are:
> > * The concept of a no-Unix-socket build is removed. We should be
> > able to do that now, right? Peter E seemed to say approximately that
> > in the commit
Thomas Munro writes:
> The most interesting things to say about these ones are:
> * The concept of a no-Unix-socket build is removed. We should be
> able to do that now, right? Peter E seemed to say approximately that
> in the commit message for 797129e5. Or is there a thought that a new
>
Here's a new batch of these:
Remove configure probe for sys/uio.h.
Remove configure probes for sys/un.h and struct sockaddr_un.
Remove configure probe for sys/select.h.
Remove configure probes for sys/ipc.h, sys/sem.h, sys/shm.h.
Remove configure probe for sys/resource.h and refactor.
Remove
Thomas Munro writes:
> Yeah, that's not true anymore, and QueryPerformanceCounter() is faster
> than GetSystemTimePreciseAsFileTime()[1], but there doesn't
> really seem to be any point in mentioning that or gettimeofday() at
> all here. I propose to cut it down to just:
> * This file
On Mon, Aug 8, 2022 at 12:27 PM Tom Lane wrote:
> BTW, that commit really should have updated the explanation at the top of
> instr_time.h:
>
> * This file provides an abstraction layer to hide portability issues in
> * interval timing. On Unix we use clock_gettime() if available, else
> *
Thomas Munro writes:
> On Thu, Aug 4, 2022 at 4:09 PM Tom Lane wrote:
>> clock_gettime is required by SUSv2 (1997), so I have to admit that
>> macOS 10.4 doesn't have a lot of excuse not to have it. In any case,
>> prairiedog is just sitting there doing its thing until I find cycles
>> to
Hi,
On 2022-08-06 18:29:14 -0700, Andres Freund wrote:
> 0003: aix: aix3.2.5, aix4.1 are not even of historical interest at this point
> - 4.1 was released before the first commit in our commit history
hoverfly clearly doesn't like this:
Hi,
On 2022-08-06 23:20:26 -0700, Andres Freund wrote:
> The good: That is just because we haven't applied enough, or the right,
> magic. To have mingw to not interfere with things one also has to pass
> -D_UCRT and -lucrt - then the tests pass, even without HAVE_BUGGY_STRTOF.
Looks like only
Hi,
On 2022-08-06 20:39:48 -0700, Andres Freund wrote:
> On 2022-08-06 22:58:12 -0400, Tom Lane wrote:
> > You could pull it out and see if the buildfarm breaks, but my money
> > is on it breaking. That HAVE_BUGGY_STRTOF stuff isn't very old.
>
> We only recently figured out that we should use
Hi,
On 2022-08-06 22:58:12 -0400, Tom Lane wrote:
> You could pull it out and see if the buildfarm breaks, but my money
> is on it breaking. That HAVE_BUGGY_STRTOF stuff isn't very old.
We only recently figured out that we should use the ucrt runtime (and that it
exists, I guess).
fairywren and
Andres Freund writes:
> On 2022-08-07 11:47:31 +1200, Thomas Munro wrote:
>> So what about strtof? That's gotta be dead code too. I gather we
>> still need commit 72880ac1's HAVE_BUGGY_STRTOF.
> Well, right now we don't refuse to build against the "wrong" runtimes, so it's
> hard to say
Hi,
On 2022-08-07 14:29:20 +1200, Thomas Munro wrote:
> On Sun, Aug 7, 2022 at 1:29 PM Andres Freund wrote:
> > 0001: __func__ is C99, so we don't need to support fallbacks
>
> +1, and my scraped data agrees.
>
> I believe our minimum MSVC is current 2015, and this says it has it
> (it doesn't
Hi,
On 2022-08-07 11:47:31 +1200, Thomas Munro wrote:
> So what about strtof? That's gotta be dead code too. I gather we
> still need commit 72880ac1's HAVE_BUGGY_STRTOF.
> From a cursory glance at MinGW's implementation, it still has the
> complained-about behaviour, if I've understood the
On Sun, Aug 7, 2022 at 1:29 PM Andres Freund wrote:
> 0001: __func__ is C99, so we don't need to support fallbacks
+1, and my scraped data agrees.
I believe our minimum MSVC is current 2015, and this says it has it
(it doesn't let you select older versions in the version drop-down,
but we don't
Hi,
Here's another set patches for cruft I discovered going line-by-line through
the autoconf vs meson test differences. They'd all be simple to port to meson
too, but I think it's better to clean them up.
0001: __func__ is C99, so we don't need to support fallbacks
0002: windows: We've
Thomas Munro writes:
> On Sun, Aug 7, 2022 at 11:22 AM Tom Lane wrote:
>> Thomas Munro writes:
>>> I also wonder if half the stuff in win32gettimeofday.c can be deleted.
> This looks good on CI (well I haven't waited for it to finish yet, but
> MSVC compiles it without warning and we're most
On Sun, Aug 7, 2022 at 11:22 AM Tom Lane wrote:
> Thomas Munro writes:
> > I also wonder if half the stuff in win32gettimeofday.c can be deleted.
> > From some light googling, it looks like
> > GetSystemTimePreciseAsFileTime() can just be called directly on
> > Windows 8+ (and we now require
Thomas Munro writes:
> So what about strtof? That's gotta be dead code too. I gather we
> still need commit 72880ac1's HAVE_BUGGY_STRTOF. From a cursory glance
> at MinGW's implementation, it still has the complained-about
> behaviour, if I've understood the complaint, and if I'm looking at
Thomas Munro writes:
> On Sun, Aug 7, 2022 at 10:42 AM Tom Lane wrote:
>> * There is a race condition for recently-forked children: they might not
>> * have executed setsid() yet. So we signal the child directly as well as
>> * the group. We assume such a child will handle the signal before
On Sat, Aug 6, 2022 at 9:08 AM Andres Freund wrote:
> [stuff about strtoll, strtoull]
So what about strtof? That's gotta be dead code too. I gather we
still need commit 72880ac1's HAVE_BUGGY_STRTOF. From a cursory glance
at MinGW's implementation, it still has the complained-about
behaviour,
On Sun, Aug 7, 2022 at 10:42 AM Tom Lane wrote:
> Thomas Munro writes:
> > Did I understand correctly that the places that do kill(-pid) followed
> > by kill(pid) really only need the kill(-pid)?
>
> Uh ... did you read the comment right above signal_child?
>
> * There is a race condition for
Thomas Munro writes:
> I also wonder if half the stuff in win32gettimeofday.c can be deleted.
> From some light googling, it looks like
> GetSystemTimePreciseAsFileTime() can just be called directly on
> Windows 8+ (and we now require 10+), and that kernel32.dll malarky was
> for older systems?
On Sun, Aug 7, 2022 at 11:08 AM Tom Lane wrote:
> Andres Freund writes:
> > Thanks. Next in my quest for reducing autoconf vs meson pg_config.h
> > differences is GETTIMEOFDAY stuff.
>
> I just noticed that this could be simplified:
>
> #ifdef _MSC_VER
> struct timezone;
> /* Last
Andres Freund writes:
> Thanks. Next in my quest for reducing autoconf vs meson pg_config.h
> differences is GETTIMEOFDAY stuff.
I just noticed that this could be simplified:
#ifdef _MSC_VER
struct timezone;
/* Last parameter not used */
extern int gettimeofday(struct timeval
Thomas Munro writes:
> Did I understand correctly that the places that do kill(-pid) followed
> by kill(pid) really only need the kill(-pid)?
Uh ... did you read the comment right above signal_child?
* There is a race condition for recently-forked children: they might not
* have executed
On Sat, Aug 6, 2022 at 2:54 AM Robert Haas wrote:
> On Fri, Aug 5, 2022 at 10:48 AM Tom Lane wrote:
> > Hmm ... I agree with you that the end result could be nicer code,
> > but what's making it nicer is a pretty substantial amount of human
> > effort for each and every call site. Is anybody
Andres Freund writes:
> I've renamed the file to win32gettimeofday now. I wonder if we should rename
> files that are specific to msvc to indicate that? But that's for later.
+1, but you didn't change the file's own comments containing its name.
regards, tom lane
On Sat, Aug 6, 2022 at 12:03 PM Andres Freund wrote:
> HAVE_GETTIMEOFDAY currently is only defined for mingw as the configure test is
> gated to windows - that's somewhat weird imo. mingw has had it since at least
> 2007. The attached patch makes the gettimeofday() fallback specific to msvc.
+1
Hi,
On 2022-08-03 14:25:01 +1200, Thomas Munro wrote:
> It'd be good to find a new home for pg_get_user_name() and
> pg_get_user_home_dir(), which really shouldn't be left in the now
> bogusly named src/port/thread.c. Any suggestions?
Leaving the name aside, the win32 handling of these
Hi,
On 2022-08-05 14:08:23 -0700, Andres Freund wrote:
> Hah, I was about to push it. Thanks for catching these. Happy for you to push
> this soon!
Thanks. Next in my quest for reducing autoconf vs meson pg_config.h
differences is GETTIMEOFDAY stuff.
HAVE_GETTIMEOFDAY currently is only defined
Hi,
On 2022-08-06 09:02:32 +1200, Thomas Munro wrote:
> On Sat, Aug 6, 2022 at 12:01 AM Thomas Munro wrote:
> > On Thu, Aug 4, 2022 at 2:30 PM Andres Freund wrote:
> >> [strtoll cleanup patch]
> >
> > LGTM. This is just C99 stuff, and my scraped config data
> > set agrees with your
On Sat, Aug 6, 2022 at 12:01 AM Thomas Munro wrote:
> On Thu, Aug 4, 2022 at 2:30 PM Andres Freund wrote:
>> [strtoll cleanup patch]
>
> LGTM. This is just C99 stuff, and my scraped config data
> set agrees with your observation.
I found a couple of explicit references to these macros left in
On Fri, Aug 5, 2022 at 10:48 AM Tom Lane wrote:
> Hmm ... I agree with you that the end result could be nicer code,
> but what's making it nicer is a pretty substantial amount of human
> effort for each and every call site. Is anybody stepping forward
> to put in that amount of work?
>
> My
Robert Haas writes:
> Overall, I don't think it's a great idea to keep all of these
> HAVE_WHATEVER macros around if the configure tests are gone. It might
> be necessary in the short term to make sure we don't regress the
> readability of the code, but I think it would be better to come up
>
On Sat, Jul 23, 2022 at 8:23 PM Tom Lane wrote:
> More generally, I'm not exactly convinced that changes like
> this are a readability improvement:
>
> -#ifdef HAVE_SETSID
> +#ifndef WIN32
>
> I'd rather not have the code cluttered with a sea of
> indistinguishable "#ifndef WIN32" tests when some
On Thu, Aug 4, 2022 at 2:30 PM Andres Freund wrote:
> On 2022-08-03 21:52:04 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Another potential cleanup is the fallback for strtoll/strtoull.
> >
> > +1, I suspect the alternate spellings are dead.
>
> Looks like that includes systems where
I've now pushed all of these except the --disable-thread-safety one,
which I'm still contemplating. So far all green on the farm (except
known unrelated breakage). But that's just the same-day animals...
On Thu, Aug 4, 2022 at 3:43 PM Andres Freund wrote:
> > We retain a HAVE_SHM_OPEN macro, because it's clearer to readers than
> > something like !defined(WIN32).
>
> I don't like these. I don't find them clearer - if we really just assume this
> to be the case on windows, it's easier to
On Thu, Aug 4, 2022 at 4:09 PM Tom Lane wrote:
> Andres Freund writes:
> >> XXX This can only be committed once prairedog is decommissioned, because
> >> macOS 10.4 didn't have clock_gettime().
>
> > Maybe put it later in the queue?
>
> clock_gettime is required by SUSv2 (1997), so I have to
Andres Freund writes:
>> XXX This can only be committed once prairedog is decommissioned, because
>> macOS 10.4 didn't have clock_gettime().
> Maybe put it later in the queue?
clock_gettime is required by SUSv2 (1997), so I have to admit that
macOS 10.4 doesn't have a lot of excuse not to have
Hi,
Can we get a few more of these committed soon? It's all tests that I need to
sync with the meson stuff, and I'd rather get it over with :). And it reduces
the set of tests that need to be compared... Or is there a blocker (leaving
the prairedog one aside)?
On 2022-08-03 14:25:01 +1200,
Hi,
On 2022-08-03 21:52:04 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Another potential cleanup is the fallback for strtoll/strtoull.
>
> +1, I suspect the alternate spellings are dead.
Looks like that includes systems where there's no declaration for strtoll,
strtoull. The test was
Andres Freund writes:
> Another potential cleanup is the fallback for strtoll/strtoull.
+1, I suspect the alternate spellings are dead.
regards, tom lane
Hi,
Another potential cleanup is the fallback for strtoll/strtoull. Some of the
spellings were introduced because of "ancient HPUX":
commit 06f66cff9e0b93db81db1595156b2aff8ba1786e
Author: Tom Lane
Date: 2018-05-19 14:22:18 -0400
Support platforms where strtoll/strtoull are spelled
On 2022-07-25 Mo 10:35, Thomas Munro wrote:
> On Sun, Jul 24, 2022 at 12:23 PM Tom Lane wrote:
>> After looking through these briefly, I'm pretty concerned about
>> whether this won't break our Cygwin build in significant ways.
>> For example, lorikeet reports "HAVE_SETSID 1", a condition that
On Sun, Jul 24, 2022 at 12:23 PM Tom Lane wrote:
> After looking through these briefly, I'm pretty concerned about
> whether this won't break our Cygwin build in significant ways.
> For example, lorikeet reports "HAVE_SETSID 1", a condition that
> you want to replace with !WIN32. The question
Thomas Munro writes:
> Here are some more, a couple of which I posted before but I've now
> gone a bit further with them in terms of removing configure checks
> etc:
After looking through these briefly, I'm pretty concerned about
whether this won't break our Cygwin build in significant ways.
For
Thomas Munro writes:
> Some of these depend on SUSv2 options (not just "base"), but we
> already do that (fsync, ...) and they're all features that are by now
> ubiquitous, which means the fallback code is untested and the probes
> are pointless.
Reading this, it occurred to me that it'd be
Andres Freund writes:
> Redefining functions, be it by linking in something or by redefining function
> names via macros, is a mess. There's places where we then have to undefine
> some of these things to be able to include external headers etc. Some
> functions are only replaced in backends,
Hi,
On 2022-07-12 08:01:40 -0400, Robert Haas wrote:
> On Mon, Jul 11, 2022 at 9:11 PM Thomas Munro wrote:
> > Hmm, but that's not what we're doing in general. For example, on
> > Windows we're redirecting open() to a replacement function of our own,
> > we're not using "pg_open()" in our code.
Robert Haas writes:
> On Mon, Jul 11, 2022 at 9:11 PM Thomas Munro wrote:
>> Hmm, but that's not what we're doing in general. For example, on
>> Windows we're redirecting open() to a replacement function of our own,
>> we're not using "pg_open()" in our code. That's not an example based
>> on
On Mon, Jul 11, 2022 at 9:11 PM Thomas Munro wrote:
> Hmm, but that's not what we're doing in general. For example, on
> Windows we're redirecting open() to a replacement function of our own,
> we're not using "pg_open()" in our code. That's not an example based
> on AC_REPLACE_FUNCS, but there
On 12.07.22 03:10, Thomas Munro wrote:
AFAIK we generally only use pg_whatever() when there's a good reason,
such as an incompatibility, a complication or a different abstraction
that you want to highlight to a reader. The reason here was
temporary: we couldn't implement standard pread/pwrite
On Tue, Jul 12, 2022 at 4:46 AM Robert Haas wrote:
> I don't think that 0001 is buying us a whole lot, really. I prefer the
> style where we have PG-specific functions that behave differently on
> different platforms to the one where we call something that looks like
> a native OS function call
On Sat, Jul 9, 2022 at 9:46 PM Thomas Munro wrote:
> The pwritev/preadv functions are unfortunately not standardised by
> POSIX (I dunno why, it's the obvious combination of the p* and *v
> functions) despite every OS in the list having them except for Solaris
> and old macOS. Oh well.
I don't
(Reading the patch it seems both those points are already addressed)
On Sat, 9 Jul 2022 at 21:46, Thomas Munro wrote:
>
> Hello,
>
> I wonder how much dead code for ancient operating systems we could now
> drop.
> 0002-Remove-dead-getrusage-replacement-code.patch
I thought the getrusage replacement code was for Windows. Does
getrusage on Windows actually do
I wrote:
> Having said that, I'll be happy to try out this patch series on
> that platform and see if it burps.
HEAD + patches 0001-0006 seems fine on prairiedog's host.
Builds clean (or as clean as HEAD does anyway), passes make check.
I did not trouble with check-world.
(I haven't actually
Thomas Munro writes:
> I wonder how much dead code for ancient operating systems we could now
> drop.
+1, it seems like this is the cycle for some housecleaning.
> * prairiedog, macOS 10.4 (vintage system most likely to cause problems)
FWIW, I am expecting to retire prairiedog once the meson
95 matches
Mail list logo
