public inbox for [email protected]help / color / mirror / Atom feed
When to drop src/tools/msvc support 21+ messages / 11 participants [nested] [flat]
* When to drop src/tools/msvc support @ 2023-04-08 19:10 Andres Freund <[email protected]> 0 siblings, 3 replies; 21+ messages in thread From: Andres Freund @ 2023-04-08 19:10 UTC (permalink / raw) To: pgsql-hackers; Tom Lane <[email protected]>; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> Hi, I'd planned to write this soon anyway, but it was just brought up in [1]. Originally we had planned to drop src/tools/msvc support shortly after meson went in. Unfortunately, it took a bit longer than originally hoped for to merge meson support and then longer than hoped to add buildfarm support. I don't think there's been any buildfarm client release with meson support yet - but we do have windows buildfarm animals using it. Do we want to drop src/tools/msvc support in 16 (i.e. now), or do it early in 17? I do have a set of patches removing src/tools/msvc. There are a few loose ends that I know of (my eyes glaze over every time I try to reconcile the src/tools/perl.m4 comments with the referenced comments in Mkvcbuild.pm), and probably more small references that grep terms didn't find. Greetings, Andres Freund [1] https://postgr.es/m/3598664.1680976414%40sss.pgh.pa.us ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-08 19:19 Jonathan S. Katz <[email protected]> parent: Andres Freund <[email protected]> 2 siblings, 0 replies; 21+ messages in thread From: Jonathan S. Katz @ 2023-04-08 19:19 UTC (permalink / raw) To: Andres Freund <[email protected]>; pgsql-hackers; Tom Lane <[email protected]>; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> On 4/8/23 3:10 PM, Andres Freund wrote: > Hi, > > I'd planned to write this soon anyway, but it was just brought up in [1]. > > Originally we had planned to drop src/tools/msvc support shortly after meson > went in. Unfortunately, it took a bit longer than originally hoped for to > merge meson support and then longer than hoped to add buildfarm support. I > don't think there's been any buildfarm client release with meson support yet - > but we do have windows buildfarm animals using it. > > Do we want to drop src/tools/msvc support in 16 (i.e. now), or do it early in > 17? > > I do have a set of patches removing src/tools/msvc. There are a few loose ends > that I know of (my eyes glaze over every time I try to reconcile the > src/tools/perl.m4 comments with the referenced comments in Mkvcbuild.pm), and > probably more small references that grep terms didn't find. (reads [1]) Can we treat this as an "open item" for completing the transition to meson for builds as part of v16? With my personal hat on, it seems silly to wait until v17 to do this, and I don't see why we would want to wait. If there's limited risk in doing this and it'll make our builds both more stable + faster, it seems like we should just do it. Thanks, Jonathan Attachments: [application/pgp-signature] OpenPGP_signature (840B, ../../[email protected]/2-OpenPGP_signature) download ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-08 19:30 Tom Lane <[email protected]> parent: Andres Freund <[email protected]> 2 siblings, 1 reply; 21+ messages in thread From: Tom Lane @ 2023-04-08 19:30 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: pgsql-hackers; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> Andres Freund <[email protected]> writes: > Do we want to drop src/tools/msvc support in 16 (i.e. now), or do it early in > 17? On the one hand, it feels like something we shouldn't do after feature freeze. On the other hand, continuing to maintain three build systems is a real drag (although you could argue that there shouldn't be much churn there until the tree opens for 17). We clearly can't consider it in any case until the buildfarm is prepared, with all the Windows animals updated to a compatible client script. I don't know what timeline Andrew has in mind for that. I guess I'd vote for pulling the trigger in v16 if we can get that done by the end of April. Once we're close to beta I think it must wait for v17 to open. regards, tom lane ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-10 16:34 Robert Haas <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: Robert Haas @ 2023-04-10 16:34 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; pgsql-hackers; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> On Sat, Apr 8, 2023 at 3:30 PM Tom Lane <[email protected]> wrote: > I guess I'd vote for pulling the trigger in v16 if we can get that > done by the end of April. Once we're close to beta I think it > must wait for v17 to open. I think that sounds reasonable. It would be to the project's advantage not to have to maintain three build systems for an extra year, but we can't still be whacking things around right up until the moment we expect to ship a beta. However, if this is the direction we're going, we probably need to give pgsql-packagers a heads up ASAP, because anybody who is still relying on the MSVC system to build Windows binaries is presumably going to need some time to adjust. If we rip out the build system somebody is using a couple of weeks before beta, that might make it difficult for that person to get the beta out promptly. And I think there's probably more than just EDB who would be in that situation. -- Robert Haas EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-10 16:56 Tom Lane <[email protected]> parent: Robert Haas <[email protected]> 0 siblings, 2 replies; 21+ messages in thread From: Tom Lane @ 2023-04-10 16:56 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: Andres Freund <[email protected]>; pgsql-hackers; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> Robert Haas <[email protected]> writes: > However, if this is the direction we're going, we probably need to > give pgsql-packagers a heads up ASAP, because anybody who is still > relying on the MSVC system to build Windows binaries is presumably > going to need some time to adjust. If we rip out the build system > somebody is using a couple of weeks before beta, that might make it > difficult for that person to get the beta out promptly. And I think > there's probably more than just EDB who would be in that situation. Oh ... that's a good point. Is there anyone besides EDB shipping MSVC-built executables? Would it even be practical to switch to meson with a month-or-so notice? Seems kind of tight, and it's not like the packagers volunteered to make this switch. Maybe we have to bite the bullet and keep MSVC for v16. If we drop it as soon as v17 opens, there's probably not that much incremental work involved compared to dropping for v16. regards, tom lane ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-10 17:34 Robert Haas <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 1 reply; 21+ messages in thread From: Robert Haas @ 2023-04-10 17:34 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; pgsql-hackers; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> On Mon, Apr 10, 2023 at 12:56 PM Tom Lane <[email protected]> wrote: > Robert Haas <[email protected]> writes: > > However, if this is the direction we're going, we probably need to > > give pgsql-packagers a heads up ASAP, because anybody who is still > > relying on the MSVC system to build Windows binaries is presumably > > going to need some time to adjust. If we rip out the build system > > somebody is using a couple of weeks before beta, that might make it > > difficult for that person to get the beta out promptly. And I think > > there's probably more than just EDB who would be in that situation. > > Oh ... that's a good point. Is there anyone besides EDB shipping > MSVC-built executables? Would it even be practical to switch to > meson with a month-or-so notice? Seems kind of tight, and it's > not like the packagers volunteered to make this switch. I can't really speak to those questions with confidence. Perhaps instead of telling pgsql-packagers what we're doing, we could instead ask them if it would work for them if we did XYZ. Then we could use that information to inform our decision-making. -- Robert Haas EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-10 18:55 Dave Page <[email protected]> parent: Robert Haas <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: Dave Page @ 2023-04-10 18:55 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Andres Freund <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Peter Geoghegan <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers On Mon, 10 Apr 2023 at 18:34, Robert Haas <[email protected]> wrote: > On Mon, Apr 10, 2023 at 12:56 PM Tom Lane <[email protected]> wrote: > > Robert Haas <[email protected]> writes: > > > However, if this is the direction we're going, we probably need to > > > give pgsql-packagers a heads up ASAP, because anybody who is still > > > relying on the MSVC system to build Windows binaries is presumably > > > going to need some time to adjust. If we rip out the build system > > > somebody is using a couple of weeks before beta, that might make it > > > difficult for that person to get the beta out promptly. And I think > > > there's probably more than just EDB who would be in that situation. > > > > Oh ... that's a good point. Is there anyone besides EDB shipping > > MSVC-built executables? Would it even be practical to switch to > > meson with a month-or-so notice? Seems kind of tight, and it's > > not like the packagers volunteered to make this switch. > > I can't really speak to those questions with confidence. > > Perhaps instead of telling pgsql-packagers what we're doing, we could > instead ask them if it would work for them if we did XYZ. Then we > could use that information to inform our decision-making. Projects other than the EDB installers use the MSVC build system - e.g. pgAdmin uses it’s own builds of libpq and other tools (psql, pg_dump etc) that are pretty heavily baked into a fully automated build system (even the build servers and all their requirements are baked into Ansible). Changing that lot would be non-trivial, though certainly possible, and I suspect we’re not the only ones doing that sort of thing. -- -- Dave Page https://pgsnake.blogspot.com EDB Postgres https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-10 20:39 Magnus Hagander <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 1 reply; 21+ messages in thread From: Magnus Hagander @ 2023-04-10 20:39 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Robert Haas <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> On Mon, Apr 10, 2023 at 6:56 PM Tom Lane <[email protected]> wrote: > > Robert Haas <[email protected]> writes: > > However, if this is the direction we're going, we probably need to > > give pgsql-packagers a heads up ASAP, because anybody who is still > > relying on the MSVC system to build Windows binaries is presumably > > going to need some time to adjust. If we rip out the build system > > somebody is using a couple of weeks before beta, that might make it > > difficult for that person to get the beta out promptly. And I think > > there's probably more than just EDB who would be in that situation. > > Oh ... that's a good point. Is there anyone besides EDB shipping > MSVC-built executables? Would it even be practical to switch to > meson with a month-or-so notice? Seems kind of tight, and it's > not like the packagers volunteered to make this switch. > > Maybe we have to bite the bullet and keep MSVC for v16. > If we drop it as soon as v17 opens, there's probably not that > much incremental work involved compared to dropping for v16. Not involved with any such build tasks anymore, but I think we can definitely assume there are others than EDB who do that. It's also used by people who build add-on modules to be loaded in the EDB-installer-installed systems, I'm sure. It seems a bit aggressive to those to drop the entire build system out just before beta. Thus, +1 on actually keeping it up and dropping it immediately as v17 opens, giving them a year of advantage. And probably updating the docs (if anybody were to read them.. but at least then we tried) stating that it's deprecated and will be removed in v17. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-10 20:50 Tom Lane <[email protected]> parent: Magnus Hagander <[email protected]> 0 siblings, 2 replies; 21+ messages in thread From: Tom Lane @ 2023-04-10 20:50 UTC (permalink / raw) To: Magnus Hagander <[email protected]>; +Cc: Robert Haas <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> Magnus Hagander <[email protected]> writes: > Thus, +1 on actually keeping it up and dropping it immediately as v17 > opens, giving them a year of advantage. And probably updating the docs > (if anybody were to read them.. but at least then we tried) stating > that it's deprecated and will be removed in v17. Yeah, I think that's the only feasible answer at this point. Maybe a month or two back we could have done differently, but there's not a lot of runway now. Once we do drop src/tools/msvc from HEAD, we should make a point of reminding -packagers about it, in hopes that they'll work on the transition sooner than next May. regards, tom lane ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-10 22:27 Andres Freund <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: Andres Freund @ 2023-04-10 22:27 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Robert Haas <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Peter Geoghegan <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers Hi, On 2023-04-10 19:55:35 +0100, Dave Page wrote: > Projects other than the EDB installers use the MSVC build system - e.g. > pgAdmin uses it’s own builds of libpq and other tools (psql, pg_dump etc) > that are pretty heavily baked into a fully automated build system (even the > build servers and all their requirements are baked into Ansible). > > Changing that lot would be non-trivial, though certainly possible, and I > suspect we’re not the only ones doing that sort of thing. Do you have a link to the code for that, if it's open? Just to get an impression for how hard it'd be to switch over? Greetings, Andres Freund ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-10 22:32 Andres Freund <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 1 reply; 21+ messages in thread From: Andres Freund @ 2023-04-10 22:32 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Robert Haas <[email protected]>; pgsql-hackers; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> Hi, On 2023-04-10 16:50:20 -0400, Tom Lane wrote: > Yeah, I think that's the only feasible answer at this point. > Maybe a month or two back we could have done differently, > but there's not a lot of runway now. > > Once we do drop src/tools/msvc from HEAD, we should make a point > of reminding -packagers about it, in hopes that they'll work on > the transition sooner than next May. So the plan is: - add note to docs in HEAD that the src/tools/msvc style of build is deprecated - give -packagers a HEADS up, once the deprecation notice has been added to the docs - have a patch ready to drop src/tools/msvc from HEAD once 16 has branched off (i.e. a polished version of what I posted upthread) On IM Thomas made some point about CI - I wonder if we should add building 16 with src/tools/msvc as an optional CI task? We can't enable it by default (yet), because we'd not have enough resources to also run that for cfbot. Once 16 forked, we then could set to run automatically in the 16 branch, as cfbot won't run those. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-10 23:52 Michael Paquier <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: Michael Paquier @ 2023-04-10 23:52 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; Robert Haas <[email protected]>; pgsql-hackers; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> On Mon, Apr 10, 2023 at 03:32:19PM -0700, Andres Freund wrote: > On IM Thomas made some point about CI - I wonder if we should add building 16 > with src/tools/msvc as an optional CI task? We can't enable it by default > (yet), because we'd not have enough resources to also run that for cfbot. Once > 16 forked, we then could set to run automatically in the 16 branch, as cfbot > won't run those. Getting a CI job able to do some validation for MSVC would be indeed nice. What's the plan in the buildfarm with this coverage? Would all the animals switch to meson (Chocolatey + StrawberryPerl, I assume) for the job or will there still be some coverage with MSVC for v16 there? -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-10 23:53 Jonathan S. Katz <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 0 replies; 21+ messages in thread From: Jonathan S. Katz @ 2023-04-10 23:53 UTC (permalink / raw) To: Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; +Cc: Robert Haas <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> On 4/10/23 4:50 PM, Tom Lane wrote: > Magnus Hagander <[email protected]> writes: >> Thus, +1 on actually keeping it up and dropping it immediately as v17 >> opens, giving them a year of advantage. And probably updating the docs >> (if anybody were to read them.. but at least then we tried) stating >> that it's deprecated and will be removed in v17. > > Yeah, I think that's the only feasible answer at this point. > Maybe a month or two back we could have done differently, > but there's not a lot of runway now. > > Once we do drop src/tools/msvc from HEAD, we should make a point > of reminding -packagers about it, in hopes that they'll work on > the transition sooner than next May. [personal opinion, not RMT] The last point would be my reasoning for "why not now" given deadlines are a pretty good motivator to get things done. That said, if the plan is to do this "shortly thereafter" for v17 and it makes the transition easier, I'm all for that. Jonathan Attachments: [application/pgp-signature] OpenPGP_signature (840B, ../../[email protected]/2-OpenPGP_signature) download ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-11 07:09 Magnus Hagander <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 1 reply; 21+ messages in thread From: Magnus Hagander @ 2023-04-11 07:09 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Dave Page <[email protected]>; Robert Haas <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Peter Geoghegan <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers On Tue, Apr 11, 2023 at 12:27 AM Andres Freund <[email protected]> wrote: > > Hi, > > On 2023-04-10 19:55:35 +0100, Dave Page wrote: > > Projects other than the EDB installers use the MSVC build system - e.g. > > pgAdmin uses it’s own builds of libpq and other tools (psql, pg_dump etc) > > that are pretty heavily baked into a fully automated build system (even the > > build servers and all their requirements are baked into Ansible). > > > > Changing that lot would be non-trivial, though certainly possible, and I > > suspect we’re not the only ones doing that sort of thing. > > Do you have a link to the code for that, if it's open? Just to get an > impression for how hard it'd be to switch over? The pgadmin docs/readme refers to https://github.com/pgadmin-org/pgadmin4/tree/master/pkg/win32 It clearly doesn't have the full automation stuff, but appears to have the parts about building the postgres dependency. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-11 08:05 Dave Page <[email protected]> parent: Magnus Hagander <[email protected]> 0 siblings, 2 replies; 21+ messages in thread From: Dave Page @ 2023-04-11 08:05 UTC (permalink / raw) To: Magnus Hagander <[email protected]>; +Cc: Andres Freund <[email protected]>; Robert Haas <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Peter Geoghegan <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers On Tue, 11 Apr 2023 at 08:09, Magnus Hagander <[email protected]> wrote: > On Tue, Apr 11, 2023 at 12:27 AM Andres Freund <[email protected]> wrote: > > > > Hi, > > > > On 2023-04-10 19:55:35 +0100, Dave Page wrote: > > > Projects other than the EDB installers use the MSVC build system - e.g. > > > pgAdmin uses it’s own builds of libpq and other tools (psql, pg_dump > etc) > > > that are pretty heavily baked into a fully automated build system > (even the > > > build servers and all their requirements are baked into Ansible). > > > > > > Changing that lot would be non-trivial, though certainly possible, and > I > > > suspect we’re not the only ones doing that sort of thing. > > > > Do you have a link to the code for that, if it's open? Just to get an > > impression for how hard it'd be to switch over? > > > The pgadmin docs/readme refers to > https://github.com/pgadmin-org/pgadmin4/tree/master/pkg/win32 > > It clearly doesn't have the full automation stuff, but appears to have > the parts about building the postgres dependency. > Yeah, that's essentially the manual process, though I haven't tested it in a while. The Ansible stuff is not currently public. I suspect (or rather, hope) that we can pull in all the additional packages required using Chocolatey which shouldn't be too onerous. Probably my main concern is that the Meson build can use the same version of the VC++ compiler that we use (v14), which is carefully matched for compatibility with all the various components, just in case anything passes CRT pointers around. Python is the one thing we don't build ourselves on Windows and the process will build modules like gssapi and psycopg (which links with libpq of course), so we're basically following what they use. -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-11 10:58 Andrew Dunstan <[email protected]> parent: Dave Page <[email protected]> 1 sibling, 1 reply; 21+ messages in thread From: Andrew Dunstan @ 2023-04-11 10:58 UTC (permalink / raw) To: Dave Page <[email protected]>; Magnus Hagander <[email protected]>; +Cc: Andres Freund <[email protected]>; Robert Haas <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Jonathan S. Katz <[email protected]>; Peter Geoghegan <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers On 2023-04-11 Tu 04:05, Dave Page wrote: > > > On Tue, 11 Apr 2023 at 08:09, Magnus Hagander <[email protected]> wrote: > > On Tue, Apr 11, 2023 at 12:27 AM Andres Freund > <[email protected]> wrote: > > > > Hi, > > > > On 2023-04-10 19:55:35 +0100, Dave Page wrote: > > > Projects other than the EDB installers use the MSVC build > system - e.g. > > > pgAdmin uses it’s own builds of libpq and other tools (psql, > pg_dump etc) > > > that are pretty heavily baked into a fully automated build > system (even the > > > build servers and all their requirements are baked into Ansible). > > > > > > Changing that lot would be non-trivial, though certainly > possible, and I > > > suspect we’re not the only ones doing that sort of thing. > > > > Do you have a link to the code for that, if it's open? Just to > get an > > impression for how hard it'd be to switch over? > > > The pgadmin docs/readme refers to > https://github.com/pgadmin-org/pgadmin4/tree/master/pkg/win32 > > It clearly doesn't have the full automation stuff, but appears to have > the parts about building the postgres dependency. > > > Yeah, that's essentially the manual process, though I haven't tested > it in a while. The Ansible stuff is not currently public. I suspect > (or rather, hope) that we can pull in all the additional packages > required using Chocolatey which shouldn't be too onerous. > > Probably my main concern is that the Meson build can use the same > version of the VC++ compiler that we use (v14), which is carefully > matched for compatibility with all the various components, just in > case anything passes CRT pointers around. Python is the one thing we > don't build ourselves on Windows and the process will build modules > like gssapi and psycopg (which links with libpq of course), so we're > basically following what they use. > > For meson you just need to to "pip install meson ninja" in your python distro and you should be good to go (they will be installed in python's Scripts directory). Don't use chocolatey to install meson/ninja - I ran into issues doing that. AFAICT meson will use whatever version of VC you have installed, although I have only been testing with VC2019. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-11 11:54 Dave Page <[email protected]> parent: Andrew Dunstan <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: Dave Page @ 2023-04-11 11:54 UTC (permalink / raw) To: Andrew Dunstan <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Andres Freund <[email protected]>; Robert Haas <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Jonathan S. Katz <[email protected]>; Peter Geoghegan <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers On Tue, 11 Apr 2023 at 11:58, Andrew Dunstan <[email protected]> wrote: > > On 2023-04-11 Tu 04:05, Dave Page wrote: > > > > On Tue, 11 Apr 2023 at 08:09, Magnus Hagander <[email protected]> wrote: > >> On Tue, Apr 11, 2023 at 12:27 AM Andres Freund <[email protected]> >> wrote: >> > >> > Hi, >> > >> > On 2023-04-10 19:55:35 +0100, Dave Page wrote: >> > > Projects other than the EDB installers use the MSVC build system - >> e.g. >> > > pgAdmin uses it’s own builds of libpq and other tools (psql, pg_dump >> etc) >> > > that are pretty heavily baked into a fully automated build system >> (even the >> > > build servers and all their requirements are baked into Ansible). >> > > >> > > Changing that lot would be non-trivial, though certainly possible, >> and I >> > > suspect we’re not the only ones doing that sort of thing. >> > >> > Do you have a link to the code for that, if it's open? Just to get an >> > impression for how hard it'd be to switch over? >> >> >> The pgadmin docs/readme refers to >> https://github.com/pgadmin-org/pgadmin4/tree/master/pkg/win32 >> >> It clearly doesn't have the full automation stuff, but appears to have >> the parts about building the postgres dependency. >> > > Yeah, that's essentially the manual process, though I haven't tested it in > a while. The Ansible stuff is not currently public. I suspect (or rather, > hope) that we can pull in all the additional packages required using > Chocolatey which shouldn't be too onerous. > > Probably my main concern is that the Meson build can use the same version > of the VC++ compiler that we use (v14), which is carefully matched for > compatibility with all the various components, just in case anything passes > CRT pointers around. Python is the one thing we don't build ourselves on > Windows and the process will build modules like gssapi and psycopg (which > links with libpq of course), so we're basically following what they use. > > > > For meson you just need to to "pip install meson ninja" in your python > distro and you should be good to go (they will be installed in python's > Scripts directory). Don't use chocolatey to install meson/ninja - I ran > into issues doing that. > > AFAICT meson will use whatever version of VC you have installed, although > I have only been testing with VC2019. > OK, that sounds easy enough then (famous last words!) Thanks! -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-11 16:23 Andres Freund <[email protected]> parent: Dave Page <[email protected]> 1 sibling, 0 replies; 21+ messages in thread From: Andres Freund @ 2023-04-11 16:23 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Robert Haas <[email protected]>; Alvaro Herrera <[email protected]>; Amit Kapila <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Peter Geoghegan <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers Hi, On 2023-04-11 09:05:31 +0100, Dave Page wrote: > Probably my main concern is that the Meson build can use the same version > of the VC++ compiler that we use (v14), which is carefully matched for > compatibility with all the various components, just in case anything passes > CRT pointers around. FWIW, Independent of meson, I don't think support for VC 2015 in postgres is long for the world. Later versions of msvc have increased the C standard compliance a fair bit... It's also a few years out of normal support. I've not tested building with 2015, but I don't know of anything that should prevent building with meson with it. I am fairly sure that it can't build tab-complete.c, but you're presumably not building with tab completion support anyway? Greetings, Andres Freund ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-11 17:44 Alvaro Herrera <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: Alvaro Herrera @ 2023-04-11 17:44 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Tom Lane <[email protected]>; Magnus Hagander <[email protected]>; Robert Haas <[email protected]>; pgsql-hackers; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]> On 2023-Apr-11, Michael Paquier wrote: > Getting a CI job able to do some validation for MSVC would be indeed > nice. What's the plan in the buildfarm with this coverage? Would all > the animals switch to meson (Chocolatey + StrawberryPerl, I assume) > for the job or will there still be some coverage with MSVC for v16 > there? If we keep MSVC support in 16, then I agree we should have a CI task for it -- and IMO we should make ti automatically triggers whenever any Makefile or meson.build is modified. Hopefully we won't touch them much now that the branch is feature-frozen, but it could still happen. Do we have code for it already, even if incomplete? -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: When to drop src/tools/msvc support @ 2023-04-12 08:54 Peter Eisentraut <[email protected]> parent: Andres Freund <[email protected]> 2 siblings, 0 replies; 21+ messages in thread From: Peter Eisentraut @ 2023-04-12 08:54 UTC (permalink / raw) To: Andres Freund <[email protected]>; pgsql-hackers; Tom Lane <[email protected]>; Peter Geoghegan <[email protected]>; Andrew Dunstan <[email protected]>; Jonathan S. Katz <[email protected]>; Amit Kapila <[email protected]>; Alvaro Herrera <[email protected]> On 08.04.23 21:10, Andres Freund wrote: > Do we want to drop src/tools/msvc support in 16 (i.e. now), or do it early in > 17? Can you build using meson from a distribution tarball on Windows? ^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: [PATCH] Preserve replication origin OIDs in pg_upgrade @ 2026-07-10 08:28 Shlok Kyal <[email protected]> 0 siblings, 0 replies; 21+ messages in thread From: Shlok Kyal @ 2026-07-10 08:28 UTC (permalink / raw) To: Ajin Cherian <[email protected]>; +Cc: shveta malik <[email protected]>; Amit Kapila <[email protected]>; Hayato Kuroda (Fujitsu) <[email protected]>; Zsolt Parragi <[email protected]>; [email protected] <[email protected]> On Thu, 9 Jul 2026 at 17:07, Ajin Cherian <[email protected]> wrote: > > Attaching v11 with all comments addressed. > Thanks Ajin. I reviewed the patch. Here are some comment for it: 1. pg_dumpall.c dumpRoleGUCPrivs(conn); + } + /* Dump replication origins */ + if (!tablespaces_only && !roles_only && binary_upgrade) + dumpReplicationOrigins(conn); The blank line below 'dumpRoleGUCPrivs(conn);' is not required 2. Maybe we can initialize the variables during declaration itself: + ReplOriginId roident; + const char *roname; + + roident = atooid(PQgetvalue(res, i, i_roident)); + roname = PQgetvalue(res, i, i_roname); 3. We should add a comment on top of this function. Just like other dumpXXX functions +static void +dumpReplicationOrigins(PGconn *conn) 4. In check.c: + /* + * Compare against the number of active origins in the old cluster not the + * total number of origins in pg_replication_origin. An origin can exist I think we can reword it like: Compare against the number of active replication origins in the old cluster, rather than the total number of origins in pg_replication_origin. 5. In pg_upgrade_support.c: +#include "utils/syscache.h" We can remove this include. Thanks, Shlok Kyal ^ permalink raw reply [nested|flat] 21+ messages in thread
end of thread, other threads:[~2026-07-10 08:28 UTC | newest] Thread overview: 21+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-04-08 19:10 When to drop src/tools/msvc support Andres Freund <[email protected]> 2023-04-08 19:19 ` Jonathan S. Katz <[email protected]> 2023-04-08 19:30 ` Tom Lane <[email protected]> 2023-04-10 16:34 ` Robert Haas <[email protected]> 2023-04-10 16:56 ` Tom Lane <[email protected]> 2023-04-10 17:34 ` Robert Haas <[email protected]> 2023-04-10 18:55 ` Dave Page <[email protected]> 2023-04-10 22:27 ` Andres Freund <[email protected]> 2023-04-11 07:09 ` Magnus Hagander <[email protected]> 2023-04-11 08:05 ` Dave Page <[email protected]> 2023-04-11 10:58 ` Andrew Dunstan <[email protected]> 2023-04-11 11:54 ` Dave Page <[email protected]> 2023-04-11 16:23 ` Andres Freund <[email protected]> 2023-04-10 20:39 ` Magnus Hagander <[email protected]> 2023-04-10 20:50 ` Tom Lane <[email protected]> 2023-04-10 22:32 ` Andres Freund <[email protected]> 2023-04-10 23:52 ` Michael Paquier <[email protected]> 2023-04-11 17:44 ` Alvaro Herrera <[email protected]> 2023-04-10 23:53 ` Jonathan S. Katz <[email protected]> 2023-04-12 08:54 ` Peter Eisentraut <[email protected]> 2026-07-10 08:28 Re: [PATCH] Preserve replication origin OIDs in pg_upgrade Shlok Kyal <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox