pg_monitor role description
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/default-roles.html Description: "This role is a member of pg_read_all_settings, pg_read_all_stats and pg_stat_scan_tables." Is it correct sentence? It seems for me that pg_read_all_stats is a member of pg_monitor. But not vice versa.
pg_type_d.h location incorrect
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/libpq-exec.html Description: >The OIDs of the built-in data types are defined in the file include/server/catalog/pg_type_d.h in the install directory. The location of "pg_type_d.h" is not correct if a user installs the PG from src and the install directory path didn't contain "postgres"/"pgsql" according to Makefile as below. >pkgincludedir = $(includedir) >ifeq "$(findstring pgsql, $(pkgincludedir))" "" >ifeq "$(findstring postgres, $(pkgincludedir))" "" >override pkgincludedir := $(pkgincludedir)/postgresql My test results are as below, please take it as your reference. [install Dir contains postgres/pgsql]/include/server/catalog/pg_type_d.h [install Dir doesn't contain postgres/pgsql]/include/postgresql/server/catalog/pg_type_d.h
Re: Error building for 64-bit Windows (10)
On Thu, May 20, 2021 at 11:04:05AM +0900, 近藤雄太 wrote: >> @ Owners of hamerkop, could you look at updating the krb5 installation >> on this animal? This include path used seems out of date compared to >> the MSI installers upstream provides. > > OK. We'll have it done in a few days. Thanks! -- Michael signature.asc Description: PGP signature
Re: Error building for 64-bit Windows (10)
Hi Michael, > @ Owners of hamerkop, could you look at updating the krb5 installation > on this animal? This include path used seems out of date compared to > the MSI installers upstream provides. OK. We'll have it done in a few days. -- Kondo Yuta
Re: more detailed description of tup_returned and tup_fetched
On 2021/05/18 20:10, Fujii Masao wrote: > > > On 2021/05/18 18:23, Masahiro Ikeda wrote: >> >> >> On 2021/05/18 16:01, Fujii Masao wrote: >>> On 2021/05/18 13:20, Masahiro Ikeda wrote: Tid Range Scan increments the tup_returned, and pg_stat_all_tables.seq_tup_read is also incremented. I thought it's ok because Tid Range Scan is like sequential scan. >>> >>> Yes, you're right. One interesting thing I found is; >>> when Tid Range Scan happens, seq_tup_read is incremented >>> but seq_scan is not. I'm not sure if this is expected behavior or not. >> >> The following comment says that this behavior is expected. But, I agree it's >> odd and it's natural both seq_tup_read and seq_scan are incremented at the >> same time or not... >> >> /* >> * Currently, we only have a stats counter for sequential heap scans (but >> * e.g for bitmap scans the underlying bitmap index scans will be counted, >> * and for sample scans we update stats for tuple fetches). >> */ >> if (scan->rs_base.rs_flags & SO_TYPE_SEQSCAN) >> pgstat_count_heap_scan(scan->rs_base.rs_rd); >> >> That's the reason why the document of pg_stat_all_tables.seq_tup_read says "Number of live rows fetched by sequential scans" >>> >>> Regarding the original issue, as far as I understand correctly, >>> >>> * pg_stat_database.tup_returned = sum(pg_stat_all_tables.seq_tup_read) + >>> sum(pg_stat_all_indexes.idx_tup_read) >>> * pg_stat_database.tup_fetched = sum(pg_stat_all_tables.idx_tup_fetch) >>> >>> But the counters for some system catalogs like pg_database shared >>> across all databases of a cluster are excluded from that calculation. >>> Is this my understanding right? If right, probably we can reuse >>> the existing descriptions for those counters to document >>> pg_stat_database counters. For example, >> >> Yes, my understanding is same now. >> >> >>> pg_stat_database.tup_returned:> Number of live rows fetched by sequential >>> and index scans in this database >> >> I wonder "live rows fetched by index scans" may mislead. I think "live" means >> it's not dead tuple and "rows" mean the tuple user want to get. >> >> But, pg_stat_all_indexes.idx_tup_read says that "index entires returned by >> scans on this index". There is no meaning of "live" and "rows", so I thought >> it's better to distinguish them. >> >> So, why don't you change to "Number of live rows fetched by sequential scans >> and index entries returned by index scans in this database"? > > Yes, LGTM. > > >>> pg_stat_database.tup_fetched: >>> Number of index entries returned by scans on indexes in this database >> Is this the sum of pg_stat_all_indexes.idx_tup_read? This is accounted to >> pg_stat_database.tup_returned. > > I was thinking that pg_stat_database.tup_fetched is the same as > the sum of pg_stat_all_tables.idx_tup_fetch. Because they both > are incremented by bitmap index scans, but pg_stat_all_indexes.idx_tup_read > is not. Yes. So, "Number of index entries returned by scans on indexes in this database" is incorrect, and "Number of live rows fetched by index scans in this database" is correct? Regards, -- Masahiro Ikeda NTT DATA CORPORATION
Re: Error building for 64-bit Windows (10)
On Wed, May 19, 2021 at 10:56:23AM -0400, Andrew Dunstan wrote: > I have no idea - it's not my animal. Maybe ask the owner > Oops, I thought that this was yours. I am adding those folks in CC of this thread. > I guess maybe I should look at adding kerberos to one of the animals I > do control. That would be nice. I think that hamerkop should really update its installation of krb5 as a first step. @ Owners of hamerkop, could you look at updating the krb5 installation on this animal? This include path used seems out of date compared to the MSI installers upstream provides. -- Michael signature.asc Description: PGP signature
Re: Improve documentation for pg_upgrade, standbys and rsync
On Wed, 2021-05-19 at 10:31 -0400, Stephen Frost wrote: > * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > > I revently tried to upgrade a standby following the documentation, > > but I found it hard to understand, [...] > > Haven't had a chance to look at this in depth but improving things here > would be good. > > An additional thing that we should really be mentioning is to tell > people to go in and TRUNCATE all of their UNLOGGED tables before going > through this process, otherwise the rsync will end up spending a bunch > of time copying the files for UNLOGGED relations which you really don't > want. Thanks for the feedback and the suggestion. CCing -hackers so that I can add it to the commitfest. Yours, Laurenz Albe
Re: Error building for 64-bit Windows (10)
On 5/18/21 8:15 PM, Michael Paquier wrote: > Hi Andrew, > > On Tue, May 18, 2021 at 08:15:35AM -0500, Brian Ye wrote: >> Thanks for the reply. >> Yes I also saw that after installing 64-bit, the 32-bit "bin" and "include" >> directories were removed. >> I think the content of the "include" are common for both 32- and 64-bit. >> Windows can run both 32-bit and >> 64-bit binaries so removing these 2 directories is probably okay. Just my >> guess. >> Again, thanks! >> Brian Ye > hamerkop is the only buildfarm member testing krb5 builds with MSVC on > Windows. The path used in this case is c:\Program Files\MIT\Kerberos\ > so the patch of this thread is going to break the builds there if this > relies on "inc/" for the include path. Is this the original include > folder used for this installation of krb5? > I have no idea - it's not my animal. Maybe ask the owner I guess maybe I should look at adding kerberos to one of the animals I do control. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Re: Improve documentation for pg_upgrade, standbys and rsync
Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > I revently tried to upgrade a standby following the documentation, > but I found it hard to understand, and it took me several tries to > get it right. This is of course owing to my lack of expertise with > rsync, but I think the documentation and examples could be clearer. > > I think it would be a good idea to recommend the --relative option > of rsync. > > Here is a patch that does that, as well as update the versions in > the code samples to something more recent. Also, I think it makes > sense to place the data directory in the sample in /var/lib/postgresql, > which is similar to what many people will have in real life. Haven't had a chance to look at this in depth but improving things here would be good. An additional thing that we should really be mentioning is to tell people to go in and TRUNCATE all of their UNLOGGED tables before going through this process, otherwise the rsync will end up spending a bunch of time copying the files for UNLOGGED relations which you really don't want. Thanks, Stephen signature.asc Description: PGP signature
