Re: pg_stat_statements: more test coverage

On Sat, Dec 30, 2023 at 08:39:47PM +0100, Peter Eisentraut wrote: > Ok, I have committed these two patches. Please note that the buildfarm has turned red, as in: https://buildfarm.postgresql.org/cgi-bin/show_stagxe_log.pl?nm=pipit=2023-12-31%2001%3A12%3A22=misc-check pg_stat_statements's

Re: Build versionless .so for Android

On Sun, Dec 31, 2023 at 06:08:04AM +0100, Matthias Kuhn wrote: > In order to ship libpq on Android, it needs to be built without a version > suffix on the .so file. > The attached patch will make sure that no version is added when built for > Android. FWIW, I have mixed feelings about patching

Re: Build versionless .so for Android

Matthias Kuhn writes: > In order to ship libpq on Android, it needs to be built without a version > suffix on the .so file. > The attached patch will make sure that no version is added when built for > Android. This ... seems incredibly brain-dead. Does Android really not cope with

Simplify documentation related to Windows builds

Hi all, As promised around thread [1] that has moved the docs related to Windows into a new sub-section for Visual, here is a follow-up to improve portions of its documentation, for discussion in the next CF. Some of my notes: - How much does command line editing work on Windows? When it came

Re: Why do parallel scans require syncscans (but not really)?

Hi, Zhang Mingli www.hashdata.xyz Hi, Tomas On Dec 31, 2023 at 07:10 +0800, Tomas Vondra , wrote: > Sadly, there's no explanation why parallel scans do not allow disabling > sync scans just like serial scans - and it's not quite obvious to me. Feel confused too. ```

Re: pg_class.reltuples of brin indexes

On Sun, Dec 31, 2023 at 02:08:41AM +0100, Tomas Vondra wrote: > I'm not sure. I think the current behavior is (still) wrong - I just > rediscovered it during testing BRIN. I haven't checked, but I guess GIN > is still affected too. > > What's not clear to me is if this is merely cosmetic issue

Build versionless .so for Android

Hi, In order to ship libpq on Android, it needs to be built without a version suffix on the .so file. The attached patch will make sure that no version is added when built for Android. I was wondering if there are a) any comments on the approach and if I should be handed in for a commitfest

Re: Remove unneeded PGDATABASE setting from TAP tests

On Sun, Dec 31, 2023 at 07:24:08AM +0530, Bharath Rupireddy wrote: > Some of the TAP tests are explicitly setting PGDATABASE environment > variable to 'postgres', which isn't needed because the TAP test's perl > library PostgreSQL::Test::Cluster already sets it once and for all. > I've attached a

Re: Exclude generated wait_event files from pgindent

On Sun, Dec 31, 2023 at 07:24:02AM +0530, Bharath Rupireddy wrote: > I think we need to add pgstat_wait_event.c, wait_event_types.h and > wait_event_funcs_data.c to pgindent/exclude_file_patterns, otherwise, > pgindent on the entire source tree after the source code compilation > shows up these

Remove unneeded PGDATABASE setting from TAP tests

Hi, Some of the TAP tests are explicitly setting PGDATABASE environment variable to 'postgres', which isn't needed because the TAP test's perl library PostgreSQL::Test::Cluster already sets it once and for all. I've attached a patch that removes all such unneeded PGDATABASE settings. Thoughts?

Exclude generated wait_event files from pgindent

Hi, I think we need to add pgstat_wait_event.c, wait_event_types.h and wait_event_funcs_data.c to pgindent/exclude_file_patterns, otherwise, pgindent on the entire source tree after the source code compilation shows up these generated files. I've attached a patch to fix it. Thoughts? -- Bharath

Re: pg_class.reltuples of brin indexes

On 11/21/23 21:48, Bruce Momjian wrote: > On Tue, Mar 27, 2018 at 08:58:11PM +0900, Masahiko Sawada wrote: >> ... >> >> If I understand correctly pg_class.reltuples of indexes should have >> the number of index tuples but especially for brin indexes it would be >> hard to estimate it in the

Re: Show WAL write and fsync stats in pg_stat_io

On Tue, Dec 26, 2023 at 03:35:52PM +0300, Nazir Bilal Yavuz wrote: > On Tue, 26 Dec 2023 at 13:10, Michael Paquier wrote: >> I am not sure while the whole point of the exercise is to have all the >> I/O related data in a single view. Something that I've also found a >> bit disturbing yesterday

Re: Commitfest 2024-01 starting in 3 days!

On Fri, Dec 29, 2023 at 02:41:55PM +0530, vignesh C wrote: > Commitfest 2024-01 is starting in 3 days! > Please register the patches which have not yet registered. Also if > someone has some pending patch that is not yet submitted, please > submit and register for 2024-01 Commitfest. > I will be

Re: Next step towards 64bit XIDs: Switch to FullTransactionId for PGPROC->xid and XLogRecord->xl_xid

On Fri, Dec 29, 2023 at 02:36:19PM +0100, Matthias van de Meent wrote: > I don't think this is an actionable change, as this wastes 4 more bytes (or > 8 with alignment) in nearly all WAL records that don't use the > HEAP/HEAP2/XLOG rmgrs, which would then be up to 10 (if not 14, when >

Re: Add PQsendSyncMessage() to libpq

On Fri, Dec 29, 2023 at 12:52:30PM +0100, Jelte Fennema-Nio wrote: > On Mon, 13 Nov 2023 at 09:20, Anthonin Bonnefoy > wrote: > > \syncpipeline > > tps = 2607.587877 (without initial connection time) > > ... > > \endpipeline > > \startpipeline > > tps = 2290.527462 (without initial connection

Re: pg_stat_statements: more test coverage

On Sat, Dec 30, 2023 at 08:39:47PM +0100, Peter Eisentraut wrote: > On 29.12.23 06:14, Julien Rouhaud wrote: >> I agree with Michael on this one, the only times I saw this pattern >> was to comply with some company internal policy for minimal coverage >> numbers. > > Ok, skipped that. Just to

Re: Fix copy and paste error (src/bin/pg_basebackup/pg_basebackup.c)

On Sat, Dec 30, 2023 at 01:38:00PM +0100, Jelte Fennema-Nio wrote: > On Sat, 30 Dec 2023 at 12:44, Ranier Vilela wrote: > > The function StartLogStreamer in (src/bin/pg_basebackup/pg_basebackup.c) > > Has a copy and paste error. > > Nice catch. Patch looks good to me. Please see my reply here:

Re: Fix resource leak (src/bin/pg_combinebackup/pg_combinebackup.c)

Hi Ranier, On Sat, Dec 30, 2023 at 10:34:12AM -0300, Ranier Vilela wrote: > The function scan_for_existing_tablespaces in > (src/bin/pg_combinebackup/pg_combinebackup.c) > Has a resource leak. > > The function opendir opendir >

Why do parallel scans require syncscans (but not really)?

Hi, While investigating something, I noticed it's not really possible to disable syncscans for a particular parallel scan. That is, with serial scans, we can do this: table_index_build_scan(heap, index, indexInfo, false, true, callback, state, NULL); where false

Re: Fix Brin Private Spool Initialization (src/backend/access/brin/brin.c)

Em sáb., 30 de dez. de 2023 19:19, Tomas Vondra < tomas.von...@enterprisedb.com> escreveu: > On 12/29/23 18:02, Ranier Vilela wrote: > > > > ... > > > > As I wrote, the new patch version was for consideration. > > It seems more like a question of style, so it's better to remove it. > > > > Anyway

Re: Revise the Asserts added to bimapset manipulation functions

On Fri, 29 Dec 2023 at 23:38, Richard Guo wrote: > After applying this process to the first RestrictInfo, the bitmapset now > becomes {t2, t3}. Consequently, the second RestrictInfo also perceives > {t2, t3} as its required_relids. As a result, when attempting to remove > it from the joininfo

Re: Parallel CREATE INDEX for BRIN indexes

Hi, While cleaning up some unnecessary bits of the code and slightly inaccurate comments, I ran into a failure when the parallel scan (used by the parallel build) happened to be a synchronized scan. When the scan did not start on page 0, the parallel callback failed to correctly handle tuples

Re: Fix Brin Private Spool Initialization (src/backend/access/brin/brin.c)

On 12/29/23 18:02, Ranier Vilela wrote: > > ... > > As I wrote, the new patch version was for consideration. > It seems more like a question of style, so it's better to remove it. > > Anyway +1 for your original patch. > I've pushed my original patch. Thanks for the report. regards --

Re: SET ROLE x NO RESET

> On 30 Dec 2023, at 17:16, Eric Hanson wrote: > > What do you think of adding a NO RESET option to the SET ROLE command? What I proposed some time ago is SET ROLE … GUARDED BY ‘password’, so that you could later: RESET ROLE WITH ‘password'

Re: Windows sockets (select missing events?)

Hi Ranier, I doubt it really matters, unless perhaps it's upsetting some static analysis tool? It's bounded by FD_SETSIZE, a small number. FWIW, I would like to delete pgwin32_select() in PG17. Before PG16 (commit 7389aad6), the postmaster used it to receive incoming connections, but that was

Re: Experiments with Postgres and SSL

On 05/07/2023 02:33, Michael Paquier wrote: On Tue, Jul 04, 2023 at 05:15:49PM +0300, Heikki Linnakangas wrote: I don't see the point of the libpq 'sslalpn' option either. Let's send ALPN always. Admittedly having the options make testing different of combinations of old and new clients and

Re: pg_stat_statements: more test coverage

On 29.12.23 06:14, Julien Rouhaud wrote: It looks good to me. One minor complaint, I'm a bit dubious about those queries: SELECT count(*) <= 100 AND count(*) > 0 FROM pg_stat_statements; Is it to actually test that pg_stat_statements won't store more than pg_stat_statements.max records?

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Sat, 30 Dec 2023 at 16:05, Jacob Burroughs wrote: > What if we allowed the client to send `ParameterStatus` messages to > the server to reconfigure protocol extensions that were requested at > startup? Sending ParameterStatus from the frontend is not possible, because Sync already claimed the

Re: SET ROLE x NO RESET

On 12/30/23 11:16, Eric Hanson wrote: Hi, What do you think of adding a NO RESET option to the SET ROLE command? Right now Postgres can enforce data security with roles and RLS, but role-per-end-user doesn't really scale:  Db connections are per-role, so a connection pooler can't share

SET ROLE x NO RESET

Hi, What do you think of adding a NO RESET option to the SET ROLE command? Right now Postgres can enforce data security with roles and RLS, but role-per-end-user doesn't really scale: Db connections are per-role, so a connection pooler can't share connections across users. We can work around

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

> How about instead of talking about protocol-only GUCs (which are > indeed currently a theoretical concept), we start considering this > patch as a way to modify parameters for protocol extensions. Protocol > extension parameters (starting with _pq_.) can currently only be > configured using the

Re: Things I don't like about \du's "Attributes" column

On Sat, 30 Dec 2023 at 09:23, Pavel Luzanov wrote: > I think that writing the value "infinity" in places where there is no > value is > not a good thing. This hides the real value of the column. In addition, > there is no reason to set "infinity" when the password is always valid with > default

Re: Things I don't like about \du's "Attributes" column

Now I'm ready for discussion. On 23.06.2023 03:50, Tom Lane wrote: Nearby I dissed psql's \du command for its incoherent "Attributes" column [1]. It's too late to think about changing that for v16, but here's some things I think we should consider for v17: * It seems weird that some

Re: Windows sockets (select missing events?)

Em qui., 28 de dez. de 2023 às 14:45, Ranier Vilela escreveu: > Hi, > > The type of field fd_count is defined in winsock.h: > typedef unsigned intu_int; > > So in the struct fd_set, > the field fd_count is unsigned int. > > The pgwin32_select function has loops that use *int* as indices. >

Fix resource leak (src/bin/pg_combinebackup/pg_combinebackup.c)

Hi, Per Coverity. The function scan_for_existing_tablespaces in (src/bin/pg_combinebackup/pg_combinebackup.c) Has a resource leak. The function opendir opendir Must be freed with closedir

Re: Fix copy and paste error (src/bin/pg_basebackup/pg_basebackup.c)

On Sat, 30 Dec 2023 at 12:44, Ranier Vilela wrote: > The function StartLogStreamer in (src/bin/pg_basebackup/pg_basebackup.c) > Has a copy and paste error. Nice catch. Patch looks good to me.

Re: Streaming I/O, vectored I/O (WIP)

Le 11/12/2023 à 10:12, Thomas Munro a écrit : 3. smgrreadv/smgrwritev patch: * improved ENOSPC handling * improve description of EOF and ENOSPC handling * fixed the sizes reported in dtrace static probes * fixed some words in the docs about that * changed error messages to refer to

Fix copy and paste error (src/bin/pg_basebackup/pg_basebackup.c)

Hi, Per Coverity. The function StartLogStreamer in (src/bin/pg_basebackup/pg_basebackup.c) Has a copy and paste error. The commit affected is dc212340058b4e7ecfc5a7a81ec50e7a207bf288 Trivial patch attached. Best regards, Ranier Vilela

Re: backtrace_on_internal_error

On 19.12.23 17:29, Tom Lane wrote: IMO, we aren't really going to get a massive payoff from this with the current backtrace output; it's just not detailed enough. It's better than nothing certainly, but to really move the goalposts we'd need something approaching gdb's "bt full" output. I