Re: In-placre persistance change of a relation

At Mon, 2 Sep 2024 09:30:20 +0900, Michael Paquier wrote in > On Sun, Sep 01, 2024 at 10:15:00PM +0300, Heikki Linnakangas wrote: > > I wonder if the twophase state files and undo log files should be merged > > into one file. They're similar in many ways: there's one file per > > transaction, na

Re: Use streaming read API in ANALYZE

On Thu, Sep 5, 2024 at 1:34 AM Thomas Munro wrote: > On Thu, Sep 5, 2024 at 3:36 AM Robert Haas wrote: > > On Wed, Sep 4, 2024 at 6:38 AM Thomas Munro > wrote: > > > Thanks for the explanation. I think we should revert it. IMHO it was > > > a nice clean example of a streaming transformation,

Re: In-placre persistance change of a relation

Hello. Thank you for the response. At Sun, 1 Sep 2024 22:15:00 +0300, Heikki Linnakangas wrote in > On 31/08/2024 19:09, Kyotaro Horiguchi wrote: > > - UNDO log(0002): This handles file deletion during transaction aborts, > >which was previously managed, in part, by the commit XLOG record

Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes

Le jeu. 5 sept. 2024 à 07:36, Bertrand Drouvot a écrit : > Hi, > > On Wed, Sep 04, 2024 at 04:37:19PM +0200, Guillaume Lelarge wrote: > > Hi, > > > > Le mer. 4 sept. 2024 à 16:18, Bertrand Drouvot < > bertranddrouvot...@gmail.com> > > a écrit : > > > What about adding a comment instead of this ex

Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN

Hi, > hi. I can roughly understand it. > > I have one minor issue with the comment. > > typedef struct RecursiveUnionState > { > PlanStateps;/* its first field is NodeTag */ > boolrecursing; > boolintermediate_empty; > Tuplestorestate *working_

Re: Commit Timestamp and LSN Inversion issue

On Wed, Sep 4, 2024 at 6:35 PM Aleksander Alekseev wrote: > > > > I don't think you can rely on a system clock for conflict resolution. > > > In a corner case a DBA can move the clock forward or backward between > > > recordings of Ts1 and Ts2. On top of that there is no guarantee that > > > 2+ se

Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN

Hi, > On Wed, 10 Jul 2024 at 21:36, Tatsuo Ishii wrote: >> v2-0005-Add-memory-disk-usage-for-Window-Aggregate-nodes-.patch: This >> adds memory/disk usage for Window Aggregate nodes in EXPLAIN (ANALYZE) >> command. Note that if David's proposal >> https://www.postgresql.org/message-id/CAHoyFK9n-Q

Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes

Hi, On Wed, Sep 04, 2024 at 04:37:19PM +0200, Guillaume Lelarge wrote: > Hi, > > Le mer. 4 sept. 2024 à 16:18, Bertrand Drouvot > a écrit : > > What about adding a comment instead of this extra check? > > > > > Done too in v3. Thanks! 1 === + /* +* Don't check counts.parallelnum

Re: psql: fix variable existence tab completion

On 04.09.2024 23:26, Tom Lane wrote: Pushed. I shall now watch the buildfarm from a safe distance. Thanks! I'll be ready to fix possible falls. With the best regards, -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Track the amount of time waiting due to cost_delay

Hi, On Mon, Sep 02, 2024 at 05:11:36AM +, Bertrand Drouvot wrote: > Hi, > > On Tue, Aug 20, 2024 at 12:48:29PM +, Bertrand Drouvot wrote: > > As it looks like we have a consensus not to wait on [0] (as reducing the > > number > > of interrupts makes sense on its own), then please find at

Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails

Alvaro Herrera 于2024年8月8日周四 06:50写道： > On 2024-Jul-26, Tender Wang wrote: > > > Junwang Zhao 于2024年7月26日周五 14:57写道： > > > > > There is a bug report[0] Tender comments might be the same issue as > > > this one, but I tried Alvaro's and mine patch, neither could solve > > > that problem, I did not

Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN

On Wed, 10 Jul 2024 at 21:36, Tatsuo Ishii wrote: > v2-0005-Add-memory-disk-usage-for-Window-Aggregate-nodes-.patch: This > adds memory/disk usage for Window Aggregate nodes in EXPLAIN (ANALYZE) > command. Note that if David's proposal > https://www.postgresql.org/message-id/CAHoyFK9n-QCXKTUWT_xxt

Re: relfilenode statistics

Hi, On Mon, Aug 05, 2024 at 05:28:22AM +, Bertrand Drouvot wrote: > Hi, > > On Thu, Jul 11, 2024 at 06:10:23AM +, Bertrand Drouvot wrote: > > Hi, > > > > On Thu, Jul 11, 2024 at 01:58:19PM +0900, Michael Paquier wrote: > > > On Wed, Jul 10, 2024 at 01:38:06PM +, Bertrand Drouvot wrot

Re: Role Granting Issues in PostgreSQL: Need Help

"David G. Johnston" writes: > On Wednesday, September 4, 2024, Muhammad Imtiaz > wrote: >> replication_expert | Cannot login > Those are not permissions, they are attributes, and attributes are not > inherited. Specifically: the NOLOGIN attribute on a role is a hard block on logging in with tha

Re: Role Granting Issues in PostgreSQL: Need Help

On Wednesday, September 4, 2024, Muhammad Imtiaz wrote: > > 1. Create a role with specific permissions > > CREATE ROLE rep_admin WITH LOGIN CREATEDB CREATEROLE REPLICATION; > > List of roles > Role name | Attributes >

Role Granting Issues in PostgreSQL: Need Help

Hi, I need to assign role permissions from one role to another. However, after granting the role, I see that the permission list for the target role has not been updated. For this process, I followed the PostgreSQL documentation available at PostgreSQL Role Membership

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Wed, Sep 4, 2024 at 9:17 AM shveta malik wrote: > > On Tue, Sep 3, 2024 at 3:01 PM shveta malik wrote: > > > > > > 1) > > I see that ReplicationSlotAlter() will error out if the slot is > > invalidated due to timeout. I have not tested it myself, but do you > > know if slot-alter errors out f

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Wed, Sep 4, 2024 at 2:49 PM shveta malik wrote: > > On Wed, Sep 4, 2024 at 9:17 AM shveta malik wrote: > > > > On Tue, Sep 3, 2024 at 3:01 PM shveta malik wrote: > > > > > > > > > 1) > It is related to one of my previous comments (pt 3 in [1]) where I > stated that inactive_since should not k

Re: Add callback in pgstats for backend initialization

On Wed, Sep 04, 2024 at 06:42:33PM +0900, Kyotaro Horiguchi wrote: > More accurately, I believe this applies when the sentence follows a > verb-object structure. In this case, the function’s meaning is “pgstat > initialization on backend,” which seems somewhat different from the > policy you mentio

Re: meson and check-tests

On Wed, Jun 5, 2024 at 7:26 PM Ashutosh Bapat wrote: > > > > On Mon, Jun 3, 2024 at 10:04 PM Tristan Partin wrote: >> >> On Sun Jun 2, 2024 at 12:25 AM CDT, Tom Lane wrote: >> > "Tristan Partin" writes: >> > > On Fri May 31, 2024 at 12:02 PM CDT, Ashutosh Bapat wrote: >> > >> We talked this off-

Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points

On Wed, Sep 04, 2024 at 07:05:32PM +0300, Maxim Orlov wrote: > Works for me with configure build. Meson build, obviously, still need extra > "meson compile install-test-files" step > as expected. From your patch, I see that you used safe_psql call to check > for availability of the injection_points

Re: Eager aggregation, take 3

Richard Guo 于2024年8月21日周三 15:11写道： > On Fri, Aug 16, 2024 at 4:14 PM Richard Guo > wrote: > > I had a self-review of this patchset and made some refactoring, > > especially to the function that creates the RelAggInfo structure for a > > given relation. While there were no major changes, the cod

Re: Typos in the code and README

On Thu, Sep 05, 2024 at 03:34:31AM +1200, David Rowley wrote: > Anyway, I doubt hard > guidelines are warranted here, but maybe some hints about best > practices in https://wiki.postgresql.org/wiki/Committing_checklist ? Yep, that may be useful. I just tend to be cautious because it can be very e

Re: Avoid overflowed array index (src/backend/utils/activity/pgstat.c)

On Wed, Sep 04, 2024 at 03:14:34PM -0300, Ranier Vilela wrote: > The commit 7949d95 , left > out an oversight. > > The report is: > CID 1559468: (#1 of 1): Overflowed array index read (INTEGER_OVERFLOW) > > I think that Coverity is right. > In the

Re: Use streaming read API in ANALYZE

On Thu, Sep 5, 2024 at 3:36 AM Robert Haas wrote: > On Wed, Sep 4, 2024 at 6:38 AM Thomas Munro wrote: > > Thanks for the explanation. I think we should revert it. IMHO it was > > a nice clean example of a streaming transformation, but unfortunately > > it transformed an API that nobody liked i

Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails

On Mon, 2 Sep 2024 23:01:47 +0200 Jehan-Guillaume de Rorthais wrote: […] > My proposal was to clean everything related to the old FK and use some > existing code path to create a fresh and cleaner one. This requires some > refactoring in existing code, but we would win a common path of cod

Re: Invalid "trailing junk" error message when non-English letters are used

Karina Litskevich writes: > I see the two solutions here: either move the rule for decinteger_junk > below the rules for hexinteger_junk, octinteger_junk and bininteger_junk, > or just use a single rule decinteger_junk for all these cases, since the > error message is the same anyway. I implemente

Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

> On 4 Sep 2024, at 23:19, David Benjamin wrote: > > On Wed, Sep 4, 2024 at 9:22 AM Daniel Gustafsson > wrote: >> > On 3 Sep 2024, at 14:18, Daniel Gustafsson > > > wrote: >> >> > Attached is a v4 rebase over the recent OpenSSL 1.0.2 removal which

Re: tiny step toward threading: reduce dependence on setlocale()

Committed v2-0001. On Tue, 2024-09-03 at 22:04 -0700, Jeff Davis wrote: > * This patch may change the handling of collation oid 0, and I'm not > sure whether that was intentional or not. lc_collate_is_c(0) returned > false, whereas pg_newlocale_from_collation(0)->collate_is_c raised > Assert or t

Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

On Wed, Sep 4, 2024 at 9:22 AM Daniel Gustafsson wrote: > > On 3 Sep 2024, at 14:18, Daniel Gustafsson wrote: > > > Attached is a v4 rebase over the recent OpenSSL 1.0.2 removal which made > this > > patch no longer apply. I've just started to dig into it so have no > comments on > > it right n

PostgreSQL 17 release announcement draft

Hi, Attached is the draft of the PostgreSQL 17 release announcement. This is a draft of the text that will go into the press kit, with the key portions to review starting from the top of the document, up until the "About PostgreSQL" section. Please provide feedback on content accuracy, notab

Re: GetRelationPath() vs critical sections

On Thu, Sep 5, 2024 at 3:58 AM Andres Freund wrote: > Obviously we could add a version of GetRelationPath() that just prints into a > caller provided buffer - but that's somewhat awkward API wise. For the record, that's exactly what I did in the patch I proposed to fix our long standing RelationT

Re: psql: fix variable existence tab completion

"Anton A. Melnikov" writes: > On 19.07.2024 01:10, Tom Lane wrote: >> With respect to the other hacks Alexander mentions, maybe we >> could clean some of those out too? I don't recall what platform >> we had in mind there, but we've moved our goalposts on what >> we support pretty far in the last

Re: json_query conditional wrapper bug

On 2024-09-04 We 6:16 AM, Peter Eisentraut wrote: On 28.08.24 11:21, Peter Eisentraut wrote: These are ok: select json_query('{"a": 1, "b": 42}'::jsonb, 'lax $.b' without wrapper);   json_query   42 select json_query('{"a": 1, "b": 42}'::jsonb, 'lax $.b' with unconditional wr

Re: race condition in pg_class

On Wed, Sep 04, 2024 at 09:00:32PM +0530, Nitin Motiani wrote: > How about this alternative then? The tuple length check > and the elog(ERROR) gets its own function. Something like > heap_inplace_update_validate or > heap_inplace_update_validate_tuple_length. So in that case, it would > look like t

Re: Large expressions in indexes can't be stored (non-TOASTable)

On 9/4/24 3:08 PM, Tom Lane wrote: Nathan Bossart writes: Thanks to commit 96cdeae, only a few catalogs remain that are missing TOAST tables: pg_attribute, pg_class, pg_index, pg_largeobject, and pg_largeobject_metadata. I've attached a short patch to add one for pg_index, which resolves the i

Re: Large expressions in indexes can't be stored (non-TOASTable)

Nathan Bossart writes: > Thanks to commit 96cdeae, only a few catalogs remain that are missing TOAST > tables: pg_attribute, pg_class, pg_index, pg_largeobject, and > pg_largeobject_metadata. I've attached a short patch to add one for > pg_index, which resolves the issue cited here. This passes

Re: GetRelationPath() vs critical sections

On Wed, Sep 04, 2024 at 11:58:33AM -0400, Andres Freund wrote: > In general emitting a LOG inside a critical section isn't a huge issue - we > made sure that elog.c has a reserve of memory to be able to log without > crashing. > > However, the current message for buffer IO issues use relpath*() (e

Re: Use read streams in pg_visibility

On Tue, Sep 03, 2024 at 10:46:34PM +0300, Nazir Bilal Yavuz wrote: > On Tue, 3 Sept 2024 at 22:20, Noah Misch wrote: > > On Tue, Sep 03, 2024 at 10:50:11AM -0700, Noah Misch wrote: > > > Pushed with some other cosmetic changes. > > Thanks! > > > I see I pushed something unacceptable under ASAN.

Re: Large expressions in indexes can't be stored (non-TOASTable)

On Tue, Sep 03, 2024 at 12:35:42PM -0400, Jonathan S. Katz wrote: > However, I ran into the issue in[1], where pg_index was identified as > catalog that is missing a toast table, even though `indexprs` is marked for > extended storage. Providing a very simple reproducer in psql below: Thanks to co

Re: Avoid possible dereference null pointer (src/bin/pg_dump/pg_dump.c)

> On 4 Sep 2024, at 19:30, Nathan Bossart wrote: > > On Wed, Sep 04, 2024 at 02:10:28PM -0300, Ranier Vilela wrote: >> I think that commit 6ebeeae >> left out an oversight. >> >> The report is: >> CID 1559991: (#1 of 1): Dereference null return v

Re: gamma() and lgamma() functions

I wrote: > AFAICS this patch doesn't inspect signgam, so whether it gets > overwritten by a concurrent thread wouldn't matter. However, > it'd be a good idea to add a comment noting the hazard. Further to that ... I looked at POSIX issue 8 (I had been reading 7) and found this illuminating discus

Re: gamma() and lgamma() functions

Dean Rasheed writes: > On Fri, 23 Aug 2024 at 13:40, Peter Eisentraut wrote: >> What are examples of where this would be useful in a database context? > Of course, there's a somewhat fuzzy line between what is generally > useful enough, and what is too specialised for core Postgres, but I > woul

Avoid overflowed array index (src/backend/utils/activity/pgstat.c)

Hi. Per Coverity. The commit 7949d95 , left out an oversight. The report is: CID 1559468: (#1 of 1): Overflowed array index read (INTEGER_OVERFLOW) I think that Coverity is right. In the function *pgstat_read_statsfile* It is necessary to first c

Re: Fix possible resource leaks (src/backend/replication/logical/conflict.c)

Ranier Vilela writes: > Per Coverity. Coverity is never to be trusted about "leaks" in the backend, because it has no idea about short- versus long-lived memory contexts. > The function *errdetail_apply_conflict* reports potential conflicts. > But do not care about possible resource leaks. > How

Re: gamma() and lgamma() functions

On Fri, 23 Aug 2024 at 13:40, Peter Eisentraut wrote: > > What are examples of where this would be useful in a database context? gamma() and lgamma() are the kinds of functions that are generally useful for a variety of tasks like statistical analysis and combinatorial computations, and having th

Fix possible resource leaks (src/backend/replication/logical/conflict.c)

Hi. Per Coverity. The commit 9758174 , included the source src/backend/replication/logical/conflict.c. The function *errdetail_apply_conflict* reports potential conflicts. But do not care about possible resource leaks. However, the leaked size can

Re: AIO v2.0

I hope there can be a high-level design document that includes a description, high-level architecture, and low-level design. This way, others can also participate in reviewing the code. For example, which paths were modified in the AIO module? Is it the path for writing WAL logs, or the path for fl

Re: Avoid possible dereference null pointer (src/bin/pg_dump/pg_dump.c)

On Wed, Sep 04, 2024 at 02:10:28PM -0300, Ranier Vilela wrote: > I think that commit 6ebeeae > left out an oversight. > > The report is: > CID 1559991: (#1 of 1): Dereference null return value (NULL_RETURNS) > > The function *findTypeByOid* can re

Avoid possible dereference null pointer (src/bin/pg_dump/pg_dump.c)

Hi. Per Coverity. I think that commit 6ebeeae left out an oversight. The report is: CID 1559991: (#1 of 1): Dereference null return value (NULL_RETURNS) The function *findTypeByOid* can return NULL. It is necessary to check the function's return

Avoid dead code (contrib/pg_visibility/pg_visibility.c)

Hi. Per coverity. I think that commit c582b75 , left an oversight. The report is: CID 1559993: (#1 of 1): Logically dead code (DEADCODE) Trivial patch attached. best regards, Ranier Vilela 0001-avoid-dead-c

Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points

On Wed, 4 Sept 2024 at 03:40, Michael Paquier wrote: > Any thoughts about the attached? This makes installcheck work here > with and without the configure switch. > > Works for me with configure build. Meson build, obviously, still need extra "meson compile install-test-files" step as expected.

Re: GUC names in messages

Hello Peter, [ sorry for the kind of off-topic ] 17.05.2024 14:57, Peter Eisentraut wrote: I committed your 0001 and 0002 now, with some small fixes. There has also been quite a bit of new code, of course, since you posted your patches, so we'll probably find a few more things that could use

GetRelationPath() vs critical sections

Hi, In the AIO patchset there are cases where we have to LOG failures inside a critical section. This is necessary because e.g. a buffer read might complete while we are waiting for a WAL write inside a critical section. We can't just defer the log message, as the IO might end up being waited-on/

Re: POC, WIP: OR-clause support for indexes

On 04.09.2024 18:31, Alena Rybakina wrote: I rewrote the tests with integer types. Thanks for your suggestion. If you don't mind, I've updated the diff file you attached earlier to include the tests. Sorry, I've just noticed that one of your changes with the regression test wasn't included. I f

Re: scalability bottlenecks with (many) partitions (and more)

On 9/4/24 17:12, David Rowley wrote: > On Wed, 4 Sept 2024 at 03:06, Robert Haas wrote: >> >> On Mon, Sep 2, 2024 at 1:46 PM Tomas Vondra wrote: >>> But say we add a GUC and set it to -1 by default, in which case it just >>> inherits the max_locks_per_transaction value. And then also provide

Re: Use streaming read API in ANALYZE

On Wed, Sep 4, 2024 at 6:38 AM Thomas Munro wrote: > Thanks for the explanation. I think we should revert it. IMHO it was > a nice clean example of a streaming transformation, but unfortunately > it transformed an API that nobody liked in the first place, and broke > some weird and wonderful wor

Re: scalability bottlenecks with (many) partitions (and more)

On 9/4/24 16:25, Matthias van de Meent wrote: > On Tue, 3 Sept 2024 at 18:20, Tomas Vondra wrote: >> FWIW the actual cost is somewhat higher, because we seem to need ~400B >> for every lock (not just the 150B for the LOCK struct). > > We do indeed allocate two PROCLOCKs for every LOCK, and alloca

Re: Typos in the code and README

On Wed, 4 Sept 2024 at 20:24, Daniel Gustafsson wrote: > Not mandatory at all, but since you were prepping a typo backpatch anyways I > figured these could join to put a small dent in reducing risks for future > backports. I think this is pretty good logic. I think fixing comment typos in ancien

Re: POC, WIP: OR-clause support for indexes

Hi! On 03.09.2024 12:52, Andrei Lepikhov wrote: If OR constants have different types, then they belong to different groups, and I think that's unfair. I think that conversion to a single type should be used here - while I’m working on this, I’ll send the code in the next letter. IMO, that mean

Re: Logging parallel worker draught

I found out in [1] that I am not correctly tracking the workers for vacuum commands. I trap workers used by parallel_vacuum_cleanup_all_indexes but not parallel_vacuum_bulkdel_all_indexes. Back to the drawing board. [1] https://www.postgresql.org/message-id/flat/783bc7f7-659a-42fa-99dd-ee056

Re: race condition in pg_class

On Wed, Sep 4, 2024 at 2:53 AM Noah Misch wrote: > > > > So this also pulls the invalidation to the genam.c > > layer. Am I understanding this correctly? > > Compared to the v9 patch, the "call both" alternative would just move the > systable_endscan() call to a new systable_inplace_update_end().

Re: Parallel workers stats in pg_stat_database

On 9/4/24 08:46, Bertrand Drouvot wrote:> What about moving the tests to places where it's "guaranteed" to get parallel workers involved? For example, a "parallel_maint_workers" only test could be done in vacuum_parallel.sql. Thank you ! I was too focussed on the stat part and missed the obviou

Re: scalability bottlenecks with (many) partitions (and more)

On Wed, 4 Sept 2024 at 03:06, Robert Haas wrote: > > On Mon, Sep 2, 2024 at 1:46 PM Tomas Vondra wrote: > > But say we add a GUC and set it to -1 by default, in which case it just > > inherits the max_locks_per_transaction value. And then also provide some > > basic metric about this fast-path ca

Re: using extended statistics to improve join estimates

On 3/9/2024 14:58, Andrei Lepikhov wrote: On 17/6/2024 18:10, Tomas Vondra wrote: x = $1 AND y = $2 AND ... As I see, current patch doesn't resolve this issue currently. Let's explain my previous argument with an example (see in attachment). The query designed to be executed with parameterised

Re: Optimize WindowAgg's use of tuplestores

On Mon, 19 Aug 2024 at 22:01, David Rowley wrote: > To try and move this forward again, I adjusted the patch to use a > static function with pg_noinline rather than unlikely. I don't think > this will make much difference code generation wise, but I did think > it was an improvement in code clean

Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes

Hi, Le mer. 4 sept. 2024 à 16:18, Bertrand Drouvot a écrit : > Hi, > > On Wed, Sep 04, 2024 at 02:51:51PM +0200, Guillaume Lelarge wrote: > > Hi, > > > > Le mer. 4 sept. 2024 à 10:47, Bertrand Drouvot < > bertranddrouvot...@gmail.com> > > a écrit : > > > > > What about to get rid of the pgstat_c

Re: Refactoring postmaster's code to cleanup after child exit

Hi, On 2024-08-12 12:55:00 +0300, Heikki Linnakangas wrote: > While rebasing this today, I spotted another instance of that mistake > mentioned in the XXX comment above. I called "CountChildren(B_BACKEND)" > instead of "CountChildren(1 << B_BACKEND)". Some ideas on how to make that > less error-pr

Re: scalability bottlenecks with (many) partitions (and more)

On Tue, 3 Sept 2024 at 18:20, Tomas Vondra wrote: > FWIW the actual cost is somewhat higher, because we seem to need ~400B > for every lock (not just the 150B for the LOCK struct). We do indeed allocate two PROCLOCKs for every LOCK, and allocate those inside dynahash tables. That amounts to (152+

Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes

Hi, On Wed, Sep 04, 2024 at 02:51:51PM +0200, Guillaume Lelarge wrote: > Hi, > > Le mer. 4 sept. 2024 à 10:47, Bertrand Drouvot > a écrit : > > > What about to get rid of the pgstat_count_parallel_heap_scan and add an > > extra > > bolean parameter to pgstat_count_heap_scan to indicate if > > c

Re: Index AM API cleanup

On Thu, Aug 22, 2024 at 11:28 AM Mark Dilger wrote: > > On Aug 22, 2024, at 1:36 AM, Alexandra Wang > > wrote: > > "make installcheck" for treeb is causing issues on my end. I can > > investigate further if it’s not a problem for others. > > The test module index AMs are not intended for use in

Re: Improving the latch handling between logical replication launcher and worker processes.

On 04/09/2024 14:24, vignesh C wrote: On Wed, 4 Sept 2024 at 08:32, Kyotaro Horiguchi wrote: I think this approach could solve the issue without adding complexity. What do you think? I agree that this approach is more simple than the other approach. How about something like the attached patch

Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes

Le mer. 4 sept. 2024 à 14:58, Bertrand Drouvot a écrit : > Hi, > > On Wed, Sep 04, 2024 at 02:51:51PM +0200, Guillaume Lelarge wrote: > > Le mer. 4 sept. 2024 ą 10:47, Bertrand Drouvot < > bertranddrouvot...@gmail.com> > > a écrit : > > > > > I don't see a CF entry for this patch. Would you mind

Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions

> On 3 Sep 2024, at 14:18, Daniel Gustafsson wrote: > Attached is a v4 rebase over the recent OpenSSL 1.0.2 removal which made this > patch no longer apply. I've just started to dig into it so have no comments > on > it right now, but wanted to get a cleaned up version into the CFBot. CFBot bu

Re: DOCS - pg_replication_slot . Fix the 'inactive_since' description

On Wed, Sep 4, 2024 at 11:34 AM David G. Johnston wrote: > > > Agree on sticking with “The time…” > > Thus I suggest either: > > The time when the slot became inactive. +1. Definitely removes confusion caused by "since" and keeps The time as subject. -- Best Wishes, Ashutosh Bapat

Re: Commit Timestamp and LSN Inversion issue

Hi Amit, > > I don't think you can rely on a system clock for conflict resolution. > > In a corner case a DBA can move the clock forward or backward between > > recordings of Ts1 and Ts2. On top of that there is no guarantee that > > 2+ servers have synchronised clocks. It seems to me that what yo

Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes

Hi, On Wed, Sep 04, 2024 at 02:51:51PM +0200, Guillaume Lelarge wrote: > Le mer. 4 sept. 2024 à 10:47, Bertrand Drouvot > a écrit : > > > I don't see a CF entry for this patch. Would you mind creating one so that > > we don't lost track of it? > > > > > I don't mind adding it, though I don't kno

Re: thread-safety: strerror_r()

On 02.09.24 21:56, Tom Lane wrote: Peter Eisentraut writes: I think we can apply these patches now to check this off the list of not-thread-safe functions to check. +1 for the first patch. I'm less happy with - static char errbuf[36]; + static char errbuf[128]; As a minor point

Re: Optimize mul_var() for var1ndigits >= 8

On Wed, Sep 4, 2024, at 09:22, Dean Rasheed wrote: > On Tue, 3 Sept 2024 at 21:31, Tom Lane wrote: >> >> Dean Rasheed writes: >> > Ah, OK. I've pushed a fix. >> >> There is an open CF entry pointing at this thread [1]. >> Shouldn't it be marked committed now? >> > > Oops, yes I missed that CF ent

Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes

Hi, Le mer. 4 sept. 2024 à 10:47, Bertrand Drouvot a écrit : > Hi, > > On Thu, Aug 29, 2024 at 04:04:05PM +0200, Guillaume Lelarge wrote: > > Hello, > > > > This patch was a bit discussed on [1], and with more details on [2]. It > > introduces four new columns in pg_stat_all_tables: > > > > * pa

Re: Commit Timestamp and LSN Inversion issue

On Wed, Sep 4, 2024 at 2:05 PM Aleksander Alekseev wrote: > > > While discussing Logical Replication's Conflict Detection and > > Resolution (CDR) design in [1] , it came to our notice that the > > commit LSN and timestamp may not correlate perfectly i.e. commits may > > happen with LSN1 < LSN2 b

Re: Improving the latch handling between logical replication launcher and worker processes.

On Wed, 4 Sept 2024 at 08:32, Kyotaro Horiguchi wrote: > > At Tue, 3 Sep 2024 09:10:07 +0530, vignesh C wrote in > > The attached v2 version patch has the changes for the same. > > Sorry for jumping in at this point. I've just reviewed the latest > patch (v2), and the frequent Own/Disown-Latch op

Re: First draft of PG 17 release notes

hi. Allow partitions to be merged using ALTER TABLE ... MERGE PARTITIONS (Dmitry Koval) Allow partitions to be split using ALTER TABLE ... SPLIT PARTITION (Dmitry Koval) also these two items got reverted? see https://git.postgresql.org/cgit/postgresql.git/commit/?id=3890d90c1508125729ed20038d9051

Re: scalability bottlenecks with (many) partitions (and more)

On 9/4/24 11:29, Jakub Wartak wrote: > Hi Tomas! > > On Tue, Sep 3, 2024 at 6:20 PM Tomas Vondra wrote: >> >> On 9/3/24 17:06, Robert Haas wrote: >>> On Mon, Sep 2, 2024 at 1:46 PM Tomas Vondra wrote: The one argument to not tie this to max_locks_per_transaction is the vastly different

Re: Use streaming read API in ANALYZE

Thanks for the explanation. I think we should revert it. IMHO it was a nice clean example of a streaming transformation, but unfortunately it transformed an API that nobody liked in the first place, and broke some weird and wonderful workarounds. Let's try again in 18.

Re: Virtual generated columns

On Wed, 4 Sept 2024 at 09:40, Peter Eisentraut wrote: > > On 21.08.24 12:51, Dean Rasheed wrote: > >> > > Well what I was thinking was that (in fireRIRrules()'s final loop over > > relations in the rtable), if the relation had any virtual generated > > columns, you'd build a targetlist containing

Re: json_query conditional wrapper bug

On 28.08.24 11:21, Peter Eisentraut wrote: These are ok: select json_query('{"a": 1, "b": 42}'::jsonb, 'lax $.b' without wrapper);  json_query  42 select json_query('{"a": 1, "b": 42}'::jsonb, 'lax $.b' with unconditional wrapper);  json_query  [42] But this app

Re: Add callback in pgstats for backend initialization

At Wed, 4 Sep 2024 15:04:09 +0900, Michael Paquier wrote in > On Wed, Sep 04, 2024 at 02:15:43PM +0900, Kyotaro Horiguchi wrote: > > The name "init_backend" makes it sound like the function initializes > > the backend. backend_init might be a better choice, but I'm not sure. > > We (kind of) te

Re: Add callbacks for fixed-numbered stats flush in pgstats

At Wed, 4 Sep 2024 15:12:37 +0900, Michael Paquier wrote in > On Wed, Sep 04, 2024 at 05:28:56AM +, Bertrand Drouvot wrote: > > On Wed, Sep 04, 2024 at 02:05:46PM +0900, Kyotaro Horiguchi wrote: > >> The generalization sounds good to me, and hiding the private flags in > >> private places al

Re: scalability bottlenecks with (many) partitions (and more)

Hi Tomas! On Tue, Sep 3, 2024 at 6:20 PM Tomas Vondra wrote: > > On 9/3/24 17:06, Robert Haas wrote: > > On Mon, Sep 2, 2024 at 1:46 PM Tomas Vondra wrote: > >> The one argument to not tie this to max_locks_per_transaction is the > >> vastly different "per element" memory requirements. If you ad

Re: [PoC] Federated Authn/z with OAUTHBEARER

On 03.09.24 22:56, Jacob Champion wrote: The parse_strval field could use a better explanation. I actually don't understand the need for this field. AFAICT, this is just used to record whether strval is valid. No, it's meant to track the value of the need_escapes argument to the constructor. I

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Wed, Sep 4, 2024 at 9:17 AM shveta malik wrote: > > On Tue, Sep 3, 2024 at 3:01 PM shveta malik wrote: > > > > 1) It is related to one of my previous comments (pt 3 in [1]) where I stated that inactive_since should not keep on changing once a slot is invalidated. Below is one side effect if

Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN

On Wed, Jul 10, 2024 at 5:36 PM Tatsuo Ishii wrote: > > > Attached are the v2 patches. As suggested by David, I split them > into multiple patches so that each patch implements the feature for > each node. You need to apply the patches in the order of patch number > (if you want to apply all of th

Re: POC: make mxidoff 64 bits

On Tue, 3 Sept 2024 at 16:32, Alexander Korotkov wrote: > I don't think you need to maintain CATALOG_VERSION_NO change in your > patch for the exact reason you have mentioned: patch will get conflict > each time CATALOG_VERSION_NO is advanced. It's responsibility of > committer to advance CATALO

Re: list of acknowledgments for PG17

On 03.09.24 19:59, Matthias van de Meent wrote: I've done a small check of the list (search for first names in the document), and found the following curiosities: I see various cases where what seem to be names with Chinese origin are styled differently between this list and the feature list.

Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes

Hi, On Thu, Aug 29, 2024 at 04:04:05PM +0200, Guillaume Lelarge wrote: > Hello, > > This patch was a bit discussed on [1], and with more details on [2]. It > introduces four new columns in pg_stat_all_tables: > > * parallel_seq_scan > * last_parallel_seq_scan > * parallel_idx_scan > * last_paral

Re: Commit Timestamp and LSN Inversion issue

Hi Shveta, > While discussing Logical Replication's Conflict Detection and > Resolution (CDR) design in [1] , it came to our notice that the > commit LSN and timestamp may not correlate perfectly i.e. commits may > happen with LSN1 < LSN2 but with Ts1 > Ts2. This issue may arise > because, during

RecoveryTargetAction is left out in xlog_interna.h

Hello, While reviewing a patch, I noticed that enum RecoveryTargetAction is still in xlog_internal.h, even though it seems like it should be in xlogrecovery.h. Commit 70e81861fa separated out xlogrecovery.c/h and moved several enums related to recovery targets to xlogrecovery.h. However, it appear

Re: Typos in the code and README

> On 4 Sep 2024, at 03:25, Michael Paquier wrote: > > On Tue, Sep 03, 2024 at 12:00:13PM +0200, Daniel Gustafsson wrote: >> I see your v17 typo fixes, and raise you a few more. Commit 31a98934d169 >> from >> just now contains 2 (out of 3) sets of typos introduced in v17 so they should >> follow

Re: Use XLOG_CONTROL_FILE macro everywhere?

At Tue, 3 Sep 2024 12:02:26 +0300, "Anton A. Melnikov" wrote in > In v2 removed XLOG_CONTROL_FILE from args and used it directly in the > string. > IMHO this makes the code more readable and will output the correct > text if the macro changes. Yeah, I had this in my mind. Looks good to me. > 3

  1   2   >