gettext instructions for Windows seems wrong
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/14/install-windows-full.html
Description:
I have to build Postgres on Windows 10. I got everything building from a git
checkout without NLS. I followed the instructions the way I understood them
(possibly incorrectly).
To add NLS support, I read this:
Gettext is required to build with NLS support, and can be downloaded from
http://gnuwin32.sourceforge.net. Note that binaries, dependencies and
developer files are all needed.
So, I went to that site and downloaded the binaries, dependencies, and
developer files as three separate ZIPs. I created a folder,
C:\Users\Documents\Code\libintl and then extracted all three ZIPs into that
directory. In that folder, there end up being directories for: bin, contrib,
include, lib, man, manifest, share. This makes sense to me; all the
extracted files are merged into one coherent directory tree rooted at
C:\Users\Documents\Code\libintl.
The instructions say that I have to edit config.pl (actually, I had to
create it), and I added this line:
$config->{nls} = 'C:\Users\dcbow\Documents\Code\libintl';
Then when I run "build", I get:
fe-misc.obj : error LNK2019: unresolved external symbol
__imp_libintl_dgettext referenced in function libpq_gettext
[c:\Users\dcbow\Documents\Code\postgres\libpq.vcxproj]
fe-misc.obj : error LNK2019: unresolved external symbol
__imp_libintl_dngettext referenced in function libpq_ngettext
[c:\Users\dcbow\Documents\Code\postgres\libpq.vcxproj]
fe-misc.obj : error LNK2019: unresolved external symbol
__imp_libintl_bindtextdomain referenced in function libpq_binddomain
[c:\Users\dcbow\Documents\Code\postgres\libpq.vcxproj]
libpgport.lib(strerror.obj) : error LNK2019: unresolved external symbol
__imp_libintl_gettext referenced in function pg_strerror_r
[c:\Users\dcbow\Documents\Code\postgres\libpq.vcxproj]
libpgport.lib(chklocale.obj) : error LNK2001: unresolved external symbol
__imp_libintl_gettext
[c:\Users\dcbow\Documents\Code\postgres\libpq.vcxproj]
C:\Users\dcbow\Documents\Code\libintl\lib\libintl.lib : warning LNK4272:
library machine type 'x86' conflicts with target machine type 'x64'
[c:\Users\dcbow\Documents\Code\postgres\libpq.vcxproj]
.\Debug\libpq\libpq.dll : fatal error LNK1120: 4 unresolved externals
[c:\Users\dcbow\Documents\Code\postgres\libpq.vcxproj]
Based on the line containing LNK4272, I learned two things here: 1. It seems
like extracting the files that I did in the place that I did and also
setting the line in config.pl that I did all seem right; at least the build
can find the files. 2. It's 32 bit, not 64, which seems to create another
problem. The documentation says: "To use a server-side third party library
such as python or OpenSSL, this library must also be 64-bit. There is no
support for loading a 32-bit library in a 64-bit server. "
I'm trying to build this, rather than use the installer, in order to find
whatever commit introduced a particular bug in libpq. I downloaded the
binary (ZIP) files from EnterpriseDB at
https://www.enterprisedb.com/download-postgresql-binaries, and they include
libintl-9.dll. In fact, in at least 12.9, 13.5 and 14.1, it's the exact same
binary. But the libintl DLL that's in http://gnuwin32.sourceforge.net/ is
named libintl3.dll and was built 17 years ago.
So, my chief complaint is that the gettext/libintl download that's listed in
the documentation is a creaky antique that, due to API changes and bitness
issues in the given build, will not work. I'm investigating
https://mlocati.github.io/articles/gettext-iconv-windows.html, which are
just more modern builds, or building all of it myself with MSYS2.
Any guidance would be appreciated, as would some sort of update to the docs
that do not have such an outdated dependency reference. Thanks for such
otherwise excellent documentation!
COMMENT ON lock
I wanted to know what lock the COMMENT ON command took and I had to look in the source code, makes sense to me that it should be documented. I've also added it to the list of commands that take a SHARE UPDATE EXCLUSIVE lock. Regards, Nikolaidiff --git i/doc/src/sgml/mvcc.sgml w/doc/src/sgml/mvcc.sgml index cfdcb742..06ed5985 100644 --- i/doc/src/sgml/mvcc.sgml +++ w/doc/src/sgml/mvcc.sgml @@ -951,7 +951,7 @@ ERROR: could not serialize access due to read/write dependencies among transact Acquired by VACUUM (without FULL), ANALYZE, CREATE INDEX CONCURRENTLY, REINDEX CONCURRENTLY, - CREATE STATISTICS, and certain ALTER + CREATE STATISTICS, COMMENT ON, and certain ALTER INDEX and ALTER TABLE variants (for full details see the documentation of these commands). diff --git i/doc/src/sgml/ref/comment.sgml w/doc/src/sgml/ref/comment.sgml index e07fc47f..04361e73 100644 --- i/doc/src/sgml/ref/comment.sgml +++ w/doc/src/sgml/ref/comment.sgml @@ -88,6 +88,7 @@ COMMENT ON issue a new COMMENT command for the same object. To remove a comment, write NULL in place of the text string. Comments are automatically dropped when their object is dropped. + A SHARE UPDATE EXCLUSIVE lock is acquired on the object. signature.asc Description: OpenPGP digital signature
Re: COMMENT ON lock
On Tue, 2022-01-18 at 14:11 +, nikolai.berkoff wrote: > I wanted to know what lock the COMMENT ON command took and I had to look in > the > source code, makes sense to me that it should be documented. I've also added > it to the list of commands that take a SHARE UPDATE EXCLUSIVE lock. +1, but SHARE ACCESS EXCLUSIVE should be marked up with . Yours, Laurenz Albe
Re: Typo in "27.2.8. Synchronous Replication"
Hi Magnus, You are correct that doing a Pull Request would involve more overhead in terms of checking out code, doing builds, etc, however GitHub automates much of that and it all runs in the cloud so you can do it in a browser on your phone while on the train if you wanted to. It literally takes a few clicks from start to finish. Here's the flow from a real example: 1. There was a typo in the "Restore and Recovery Overview (SQL Server)" docs here https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-and-recovery-overview-sql-server?view=sql-server-ver15 2. I noticed the typo and on the top right of the page there's an "edit" link. Click that and it takes you to GitHub where the Markdown text is. GitHub automatically creates a fork of the repo for me and opens an editor where I can edit the Markdown, get a diff so I can review the changes, then commit with a message. 3. After committing, GitHub shows a "Create Pull Request" button. Click that and it automatically copies the commit message, opens an editor that allows me to edit further if needed. For simple typos you usually just submit the PR, which I did here https://github.com/MicrosoftDocs/sql-docs/pull/6840 4. When a PR is submitted, one or more actions run automatically to check for merge conflicts, to run any build steps, tests, etc. Note: up to this point, nobody on the docs team has been involved: it's just me and the automated processes on GitHub. 5. If the automated actions complete successfully THEN the responsible person is notified. They can review the PR and merge it with one click. GitHub also makes it super simple to discuss the edits, make further commits, etc if the PR has issues. A complete history is made visible right there in the browser. The SQL Server Docs Team also has an automated process to push changes to the live site, usually in a matter of hours and the really nice touch is that once the changes are live, the committer is credited on the live site with their GitHub avatar and name (e.g. for that fix, you can see mine here: https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-and-recovery-overview-sql-server?view=sql-server-ver15 - it's the third avatar from the left with name ericmutta). Postgres existed long before GitHub and long before the CI/CD development flow (which GitHub makes really easy) became mainstream, so it may take some time and effort to adopt it. I do think the time will be well spent because it will allow the already great Postgres docs to get even better and do so FASTER (note that you pushed the fix on 27/Dec last year but over three weeks later, the live site here https://www.postgresql.org/docs/14/warm-standby.html still doesn't reflect the fix). Hopefully that provides food for thought, and I will be happy to contribute/help further in any way I can. Many thanks, Eric. On Sun, Jan 16, 2022 at 8:31 PM Magnus Hagander wrote: > On Mon, Jan 3, 2022 at 1:40 PM Eric Mutta wrote: > > > > Hi Magnus, happy new year! Thanks for pushing the fix. > > > > Coming from an SQL Server background where the docs are hosted on GitHub > and minor changes like this can be made by simply submitting a pull > request, I am wondering is there anything similar for the Postgres docs? > > > > Going through a mailing list just to fix a typo feels like a lot of > overhead! > > Hi! > > Personally, I would find sending an email to a mailing list or like > you did, filling out the form on the website, would be *less* overhead > than having to do a Pull Request (which would include checkout, > verifying builds etc, no?). > > Can you enlighten me on exactly which part of the flow of that you > think would make it easier? Perhaps it's something we can adopt > something out of to make it easier for us as well. But I wonder if it > more has to do with the structure of the docs than the actual tool? > (That is, the error is on warm-standby.html, but the source is > actually in a file called high-availability.sgml) > > //Magnus >
Re: Typo in "27.2.8. Synchronous Replication"
On Tue, Jan 18, 2022 at 4:01 PM Eric Mutta wrote: > > 2. I noticed the typo and on the top right of the page there's an "edit" > link. Click that and it takes you to GitHub where the Markdown text is. > I suspect a large part of your expectation is based upon this and that GitHub can display processed markdown natively. That is a huge difference between the experience you describe here and our SGML-based documentation. > 4. When a PR is submitted, one or more actions run automatically to check > for merge conflicts, to run any build steps, tests, etc. Note: up to this > point, nobody on the docs team has been involved: it's just me and the > automated processes on GitHub. > Honestly, if this part works well (and even the immediate single-page editing), a functioning demonstration on a fork of our repo on GitHub would go a long way. Even if that fork is only used to get to the point of producing a pull request which the coder can then copy and paste into an email message to -hackers to be formally applied to the codebase, back-patched if necessary (we don't make authors worry about back-patching). 5. If the automated actions complete successfully THEN the responsible > person is notified. They can review the PR and merge it with one click. > GitHub also makes it super simple to discuss the edits, make further > commits, etc if the PR has issues. A complete history is made visible right > there in the browser. > Having both the PR and the mailing list be places where code reviews might happen would be a concern - but the author can deal with that. > Postgres existed long before GitHub and long before the CI/CD development > flow (which GitHub makes really easy) became mainstream, so it may take > some time and effort to adopt it. > The desire to avoid entanglements on third-party services is a point made by comitters that is impossible to avoid if leveraging GitHub. And the barriers are much higher if we host our own (e.g., GitLab). But again, people who only know how to compile PostgreSQL (a low bar to meet) and are familiar with this ecosystem (a prerequisite if going down this path) can experiment and proof-of-concept. FYI, there is some current work being done to use Meson in the build process (I haven't kept up with the details). > (note that you pushed the fix on 27/Dec last year but over three weeks > later, the live site here > https://www.postgresql.org/docs/14/warm-standby.html still doesn't > reflect the fix). > The docs and the source code are maintained in the same manner. Once release 12.10 is published the v12 website and the source code will update to that latest version. That is arguably a policy decision that any new tooling would continue to adhere to. You can check that the current HEAD has the patch because we do publish a development branch for that. In short, the committers tend to get trivial fixes to the docs applied without any difficulty or delay, even when presented with just a url link and some suggestion text. The sgml overhead on those is minimal. While I appreciate we could be even more cool if we used a more modern set of features, the effort it would take to do so doesn't seem to match the benefit we would get. Our documentation is, on the whole, a strength. David J.
Re: COMMENT ON lock
On Tue, Jan 18, 2022 at 03:37:35PM +0100, Laurenz Albe wrote: > On Tue, 2022-01-18 at 14:11 +, nikolai.berkoff wrote: >> I wanted to know what lock the COMMENT ON command took and I had to look in >> the >> source code, makes sense to me that it should be documented. I've also added >> it to the list of commands that take a SHARE UPDATE EXCLUSIVE lock. > > +1. No objections to add more details for all that. Will fix. -- Michael signature.asc Description: PGP signature
