Re: Add has_large_object_privilege function

On Thu, 12 Sep 2024 19:51:33 +0900 Yugo NAGATA wrote: > On Thu, 12 Sep 2024 19:07:22 +0900 > Fujii Masao wrote: > > > > > > > On 2024/09/10 17:45, Yugo NAGATA wrote: > > > On Mon, 9 Sep 2024 22:59:34 +0900 > > > Fujii Masao wrote: > > > > > >> > > >> > > >> On 2024/07/02 16:34, Yugo NAGATA

Re: Disallow altering invalidated replication slots

On Thu, Sep 12, 2024 at 4:24 PM Amit Kapila wrote: > > On Wed, Sep 11, 2024 at 8:41 AM shveta malik wrote: > > > > On Tue, Sep 10, 2024 at 11:24 PM Bharath Rupireddy > > wrote: > > > > > > > > > Please find the attached v2 patch also having Shveta's review comments > > > addressed. > > > > The v

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

David, Thank you for your review. > Yes, I think it's a good idea to move that into a helper function. If > you do the other node types, without that helper the could would have > to be repeated quite a few times. Maybe show_storage_info() can be > moved up with the other helper functions, say be

Re: Conflict detection for update_deleted in logical replication

On Wed, Sep 11, 2024 at 11:07 AM Zhijie Hou (Fujitsu) wrote: > > On Wednesday, September 11, 2024 1:03 PM shveta malik > wrote: > > > > > > > > > > Another query is about 3 node setup. I couldn't figure out what > > > > would be feedback_slots setting when it is not bidirectional, as in > > > >

Re: query_id, pg_stat_activity, extended query protocol

On Thu, Sep 12, 2024 at 03:58:27PM -0500, Sami Imseih wrote: > Yes, adding the asserts in execMain.c is better, but there is complications > there due to the issue you mention. I think the issue you are bumping into > is when pg_stat_statements.track_utility = on ( default ), the assert in > Execu

Re: long-standing data loss bug in initial sync of logical replication

On Mon, 9 Sept 2024 at 10:41, Shlok Kyal wrote: > > On Mon, 2 Sept 2024 at 10:12, Amit Kapila wrote: > > > > On Fri, Aug 30, 2024 at 3:06 PM Shlok Kyal wrote: > > > > > > Next I am planning to test solely on the logical decoding side and > > > will share the results. > > > > > > > Thanks, the ne

Re: Using per-transaction memory contexts for storing decoded tuples

On 2024-09-12 07:32, Masahiko Sawada wrote: Thanks a lot for working on this! Hi all, We have several reports that logical decoding uses memory much more than logical_decoding_work_mem[1][2][3]. For instance in one of the reports[1], even though users set logical_decoding_work_mem to '256MB',

Re: Psql meta-command conninfo+

Hi, On Thu, Sep 12, 2024 at 4:08 PM Jim Jones wrote: > It may look like this, but it is a single record --- mind the header "-[ > RECORD 1 ]+-". > psql was called in expanded mode: > > > $ /home/pgsql-17devel/bin/psql -x -p 5432 > > "-x" or "--expanded" > > Example: > > $

Re: per backend I/O statistics

Hi, On Fri, Sep 06, 2024 at 03:03:17PM +, Bertrand Drouvot wrote: > The struct size is 1040 Bytes and that's much more reasonable than the size > needed for per backend I/O stats in v1 (about 16KB). One could think that's a high increase of shared memory usage with a high number of connection

Re: Why don't we consider explicit Incremental Sort?

On Mon, Sep 9, 2024 at 6:22 PM Tomas Vondra wrote: > I think we intentionally added incremental sort ... incrementally ;-) Haha, right. > I think one challenge with this case is that create_mergejoin_plan > creates these Sort plans explicitly - it's not "pathified" so it doesn't > go through the

Re: Switch PgStat_HashKey.objoid from Oid to uint64

Hi, On Fri, Sep 13, 2024 at 07:34:21AM +0900, Michael Paquier wrote: > On Thu, Sep 12, 2024 at 01:37:52PM +, Bertrand Drouvot wrote: > > There is also some manipulation around the 2 new uint32 fields (objid_hi and > > objid_lo) in the xactdesc.c and pgstat_xact.c files that look good to me. >

Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch

On Thu, Sep 12, 2024 at 10:40:11PM -0400, Tom Lane wrote: > Nathan Bossart writes: >> Here's a patch to make the sequence permanent and to make the output of >> tuple_data_split() not depend on endianness. > > +1 --- I checked this on mamba's host and it does produce > "\\x0101" regar

Re: Mutable foreign key constraints

On Thu, 2024-09-12 at 17:33 -0400, Tom Lane wrote: > I happened to notice that Postgres will let you do > > regression=# create table foo (id timestamp primary key); > CREATE TABLE > regression=# create table bar (ts timestamptz references foo); > CREATE TABLE > > This strikes me as a pretty bad

Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch

Nathan Bossart writes: > Here's a patch to make the sequence permanent and to make the output of > tuple_data_split() not depend on endianness. +1 --- I checked this on mamba's host and it does produce "\\x0101" regardless of endianness. regards, tom lane

Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch

On Thu, Sep 12, 2024 at 08:42:09PM -0500, Nathan Bossart wrote: > Oh, the answer seems to be commits aeaaf52 and 47a22dc. In short, we can't > use a temporary sequence in this test for versions older than v15. Here's a patch to make the sequence permanent and to make the output of tuple_data_spli

Re: ANALYZE ONLY

On 2024-09-11 16:47, Michael Harris wrote: Thanks for the feedback. On Tue, 10 Sept 2024 at 22:03, torikoshia wrote: Regarding the addition of partition descendant tables, should we also update the below comment on expand_vacuum_rel? Currently it refers only partitions: | * Given a Vacuum

Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch

On Thu, Sep 12, 2024 at 07:56:56PM -0500, Nathan Bossart wrote: > I see that skimmer is failing with this error: > > ERROR: cannot access temporary tables during a parallel operation > > This makes sense because that machine has > debug_parallel_query/force_parallel_mode set to "regress",

Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch

On Fri, Sep 13, 2024 at 09:47:36AM +0900, Michael Paquier wrote: > On Thu, Sep 12, 2024 at 07:41:30PM -0500, Nathan Bossart wrote: >> Ugh, the buildfarm is unhappy with the new tests [0] [1]. Will fix. > > I'd suggest to switch the test to return a count() and make sure that > one record exists.

Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch

On Thu, Sep 12, 2024 at 07:41:30PM -0500, Nathan Bossart wrote: > On Thu, Sep 12, 2024 at 04:39:14PM -0500, Nathan Bossart wrote: > > Committed. > > Ugh, the buildfarm is unhappy with the new tests [0] [1]. Will fix. I'd suggest to switch the test to return a count() and make sure that one recor

Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch

On Thu, Sep 12, 2024 at 04:39:14PM -0500, Nathan Bossart wrote: > Committed. Ugh, the buildfarm is unhappy with the new tests [0] [1]. Will fix. [0] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wrasse&dt=2024-09-12%2022%3A54%3A45 [1] https://buildfarm.postgresql.org/cgi-bin/show_log

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

On Thu, Sep 12, 2024 at 09:10:44AM +0300, Nazir Bilal Yavuz wrote: > This should be fixed in 65c310b310a6. Thanks for the confirmation. -- Michael signature.asc Description: PGP signature

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

Turns out there was a bug in EXEC_BACKEND mode, causing failures on the Windows machine in CI. AFAIK the reason is pretty simple - the backends don't see the number of fast-path groups postmaster calculated from max_locks_per_transaction. Fixed that by calculating it again in AttachSharedMemoryStr

Re: type cache cleanup improvements

On Sat, Aug 31, 2024 at 10:33 PM Andrei Lepikhov wrote: > On 29/8/2024 11:01, Alexander Korotkov wrote: > > On Mon, Aug 26, 2024 at 11:26 AM Alexander Korotkov > >> Secondly, I'm not terribly happy with current state of type cache. > >> The caller of lookup_type_cache() might get already invalidat

Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64

Hi, FYI, people interested in this thread might be interested in pgsql-bugs #18610. There are two related issues here: 1. Some people want to use LSE on modern ARM servers so they want to use -moutline-atomics, which IIUC adds auto-detection logic with fallback code so it can still run on the f

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

On Tue, Sep 10, 2024 at 3:05 PM Noah Misch wrote: > > On Tue, Sep 10, 2024 at 05:56:47PM -0400, Tom Lane wrote: > > Masahiko Sawada writes: > > > On Tue, Sep 10, 2024 at 11:57 AM Tom Lane wrote: > > >> Yeah, that seems like it could work. But are we sure that replicas > > >> get a copy of the p

Re: Switch PgStat_HashKey.objoid from Oid to uint64

On Thu, Sep 12, 2024 at 01:37:52PM +, Bertrand Drouvot wrote: > There is also some manipulation around the 2 new uint32 fields (objid_hi and > objid_lo) in the xactdesc.c and pgstat_xact.c files that look good to me. Thanks for the reviews. The high and low manipulations are still kind of OK

Re: Mutable foreign key constraints

"David G. Johnston" writes: > On Thursday, September 12, 2024, Tom Lane wrote: >> A possible objection is that if anybody has such a setup and >> hasn't noticed a problem because they never change their >> timezone setting, they might not appreciate us breaking it. >> So I certainly wouldn't prop

Re: Mutable foreign key constraints

On Thursday, September 12, 2024, Tom Lane wrote: > > A possible objection is that if anybody has such a setup and > hasn't noticed a problem because they never change their > timezone setting, they might not appreciate us breaking it. > So I certainly wouldn't propose back-patching this. But > m

Re: AIO v2.0

Hi Andres Thanks for the AIO patch update. I gave it a try and ran into a FATAL in bgwriter when executing a benchmark. 2024-09-12 01:38:00.851 PDT [2780939] PANIC: no more bbs 2024-09-12 01:38:00.854 PDT [2780473] LOG: background writer process (PID 2780939) was terminated by signal 6: Aborted

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

Hi, I've spent quite a bit of time trying to identify cases where having more fast-path lock slots could be harmful, without any luck. I started with the EPYC machine I used for the earlier tests, but found nothing, except for a couple cases unrelated to this patch, because it affects even cases w

Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch

On Thu, Sep 12, 2024 at 11:19:00AM +0900, Michael Paquier wrote: > On Wed, Sep 11, 2024 at 11:02:43PM +0100, Matthias van de Meent wrote: >> As for patch v3, that seems fine with me. > > +1 from here as well, after looking at what v3 is doing for these two > modules. Committed. -- nathan

Mutable foreign key constraints

I happened to notice that Postgres will let you do regression=# create table foo (id timestamp primary key); CREATE TABLE regression=# create table bar (ts timestamptz references foo); CREATE TABLE This strikes me as a pretty bad idea, because whether a particular timestamp is equal to a particul

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

On Fri, 13 Sept 2024 at 00:12, Tatsuo Ishii wrote: > In this patch I refactored show_material_info. I divided it into > show_material_info and show_storage_info so that the latter can be > used by other node types including window aggregate node. What do you > think? Yes, I think it's a good idea

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

On 9/4/24 11:45 PM, Jeff Davis wrote: Committed v2-0001. > [...] I fixed this by replacing the assert with an elog(ERROR, ...), so that it will consistently show a "cache lookup failed for collation 0" regardless of whether it's a debug build or not. It's not expected that the error will be e

Re: query_id, pg_stat_activity, extended query protocol

> Do you think that we'd better replace the calls reporting the query ID > in execMain.c by some assertions on HEAD? This won't work for > ExecutorStart() because PREPARE statements (or actually EXECUTE, > e.g. I bumped on that yesterday but I don't recall which one) would Yes, adding the asserts

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

On Mon, 2024-09-09 at 15:37 +0200, Peter Eisentraut wrote: > In the end, I figured the best thing to do here is to add an explicit > locale argument to MATCH_LOWER() and GETCHAR() so one can actually > understand this code by reading it.  New patch attached. Looks good to me, thank you. Regards,

Re: may be a mismatch between the construct_array and construct_md_array comments

Alena Rybakina writes: > I noticed that there is a comment that values ​​with NULL are not > processed there, but in fact this function calls the construct_md_array > function, which > contains a comment that it can handle NULL values. Right. construct_md_array has a "bool *nulls" argument, bu

Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges

Re: To Tom Lane > Let's keep it like it is now in PG17. Late followup news: This feature has actually found a bug in postgresql-debversion: CREATE OPERATOR > ( LEFTARG = debversion, RIGHTARG = debversion, COMMUTATOR = <, - NEGATOR = >=, + NEGATOR = <=, RESTRICT = scalargtsel, JO

may be a mismatch between the construct_array and construct_md_array comments

While working on the "POC, WIP: OR-clause support for indexes" project [0], it was suggested to use the construct_array function to form a one-dimensional array. I noticed that there is a comment that values ​​with NULL are not processed there, but in fact this function calls the construct_md_

Re: Incremental Sort Cost Estimation Instability

On 9/12/24 12:12, David Rowley wrote: > On Thu, 12 Sept 2024 at 21:51, Andrei Lepikhov wrote: >> Initial problem causes wrong cost_sort estimation. Right now I think >> about providing cost_sort() the sort clauses instead of (or in addition >> to) the pathkeys. > > I'm not quite sure why the sort

Re: Adding skip scan (including MDAM style range skip scan) to nbtree

On Mon, 9 Sept 2024 at 21:55, Peter Geoghegan wrote: > > On Sat, Sep 7, 2024 at 11:27 AM Tomas Vondra wrote: > > I started looking at this patch today. > > Thanks for taking a look! > > > The first thing I usually do for > > new patches is a stress test, so I did a simple script that generates >

Re: [PATCH] Support Int64 GUCs

On Thu, Sep 12, 2024 at 02:08:15PM +0300, Aleksander Alekseev wrote: > Secondly, the following core GUCs are made 64-bit: > > ``` > autovacuum_freeze_min_age > autovacuum_freeze_max_age > autovacuum_freeze_table_age > autovacuum_multixact_freeze_min_age > autovacuum_multixact_freeze_max_age > auto

Re: Switch PgStat_HashKey.objoid from Oid to uint64

Hi, On Thu, Aug 29, 2024 at 08:56:59AM +0900, Michael Paquier wrote: > On Mon, Aug 26, 2024 at 09:32:54AM +0300, Heikki Linnakangas wrote: > > Currently, we rely on the fact that all the xl_xact_* structs require > > sizeof(int) alignment. See comment above struct xl_xact_xinfo. > > Thanks, I hav

Re: POC: make mxidoff 64 bits

On 2024-Sep-12, Pavel Borisov wrote: > Hi, Maxim! > > Previously we accessed offsets in shared MultiXactState without locks as > 32-bit read is always atomic. But I'm not sure it's so when offset become > 64-bit. > E.g. GetNewMultiXactId(): > > nextOffset = MultiXactState->nextOffset; > is outsi

Re: POC: make mxidoff 64 bits

On Thu, 12 Sept 2024 at 16:09, Pavel Borisov wrote: > Hi, Maxim! > > Previously we accessed offsets in shared MultiXactState without locks as > 32-bit read is always atomic. But I'm not sure it's so when offset become > 64-bit. > E.g. GetNewMultiXactId(): > > nextOffset = MultiXactState->nextOffs

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

Here is the v3 patch. This time I only include patch for the Window Aggregate node. Patches for other node types will come after this patch getting committed or come close to commitable state. David, In this patch I refactored show_material_info. I divided it into show_material_info and show_stora

Re: POC: make mxidoff 64 bits

Hi, Maxim! Previously we accessed offsets in shared MultiXactState without locks as 32-bit read is always atomic. But I'm not sure it's so when offset become 64-bit. E.g. GetNewMultiXactId(): nextOffset = MultiXactState->nextOffset; is outside lock. There might be other places we do the same as

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

Em qui., 12 de set. de 2024 às 02:18, Michael Paquier escreveu: > On Wed, Sep 04, 2024 at 01:50:24PM -0300, Ranier Vilela wrote: > > I think that commit c582b75 > > < > https://github.com/postgres/postgres/commit/c582b75851c2d096ce050d753494505a957cee75 > >, > > left an oversight. > > > > The rep

Re: [PATCH] Support Int64 GUCs

Hi Pavel, > I think the direction is good and delivering 64-bit GUCs is very much worth > committing. > The patch itself looks good, but we could need to add locks against > concurrently modifying 64-bit values, which could be non-atomic on older > architectures. Thanks for the feedback. > I

Re: [PATCH] Support Int64 GUCs

Hi, Alexander! Thank you for working on this! On Thu, 12 Sept 2024 at 15:08, Aleksander Alekseev wrote: > Hi, > > Attached is a self-sufficient patch extracted from a larger patchset > [1]. The entire patchset probably will not proceed further in the > nearest future. Since there was interest in

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, > Agree. > > To me it seems like we didn't reach a consensus regarding switching to > 64-bit XIDs. Given that and the fact that the patchset is rather > difficult to rebase (and review) I suggest focusing on something we > reached a consensus for. I'm going to close a CF entry for this > parti

[PATCH] Support Int64 GUCs

Hi, Attached is a self-sufficient patch extracted from a larger patchset [1]. The entire patchset probably will not proceed further in the nearest future. Since there was interest in this particular patch it deserves being discussed in a separate thread. Currently we support 32-bit integer values

Re: Psql meta-command conninfo+

On 11.09.24 13:35, Hunaid Sohail wrote: > Hi Jim, > > On Wed, Sep 11, 2024 at 3:03 PM Jim Jones > wrote: > > Thanks for working on this. > > Any particular reason for the design change? In v28 it returned a > table > with a single row and multiple columns --- one column per >

Re: pg_verifybackup: TAR format backup verification

On Tue, Sep 10, 2024 at 1:31 AM Robert Haas wrote: > > I would rather that you didn't add simple_ptr_list_destroy_deep() > given that you don't need it for this patch series. > Done. > + > "\"%s\" unexpected file in the tar format backup", > > This doesn't seem grammatical to me. Perhaps change t

Re: PG_TEST_EXTRA and meson

Hi, On Thu, 12 Sept 2024 at 12:35, Ashutosh Bapat wrote: > > Here's what I understand, please correct me: The code in meson.build > is only called at the time of setup; not during meson test. Hence we > can not check the existence of a runtime environment variable in that > file. The things in te

Re: [PATCH] Add CANONICAL option to xmlserialize

On 10.09.24 19:43, Tom Lane wrote: > How about instead introducing a plain function along the lines of > "xml_canonicalize(xml, bool keep_comments) returns text" ? The SQL > committee will certainly never do that, but we won't regret having > created a plain function whenever they get around to d

Re: Disallow altering invalidated replication slots

On Wed, Sep 11, 2024 at 8:41 AM shveta malik wrote: > > On Tue, Sep 10, 2024 at 11:24 PM Bharath Rupireddy > wrote: > > > > > > Please find the attached v2 patch also having Shveta's review comments > > addressed. > > The v2 patch looks good to me. > LGTM as well. I'll push this tomorrow morning

Re: Add has_large_object_privilege function

On Thu, 12 Sep 2024 19:07:22 +0900 Fujii Masao wrote: > > > On 2024/09/10 17:45, Yugo NAGATA wrote: > > On Mon, 9 Sep 2024 22:59:34 +0900 > > Fujii Masao wrote: > > > >> > >> > >> On 2024/07/02 16:34, Yugo NAGATA wrote: > >>> So, I would like to propose to add > >>> has_large_object_function

Re: CI, macports, darwin version problems

On 9/12/24 02:05, Thomas Munro wrote: On Tue, Sep 10, 2024 at 3:04 PM Thomas Munro wrote: On Mon, Sep 9, 2024 at 1:37 PM Joe Conway wrote: Seems the mounted drive got unmounted somehow ¯\_(ツ)_/¯ Please check it out and let me know if it is working properly now. Looks good, thanks! ... bu

Re: not null constraints, again

On 2024-Sep-12, jian he wrote: > ---exampleA > drop table pp1,cc1, cc2; > create table pp1 (f1 int); > create table cc1 (f2 text, f3 int) inherits (pp1); > create table cc2(f4 float) inherits(pp1,cc1); > alter table pp1 alter column f1 set not null; > execute constr_meta('{pp1,cc1, cc2}'); > > --

Re: Docs: Order of json aggregate functions

On Thu, 20 Jun 2024 at 05:50, Wolfgang Walther wrote: > json_arrayagg and json_agg_strict are out of place. > > Attached patch puts them in the right spot. This is the same down to v16. Thank you. I've pushed this and ended up backpatching to 16 too. It's quite hard to unsee the broken order onc

Re: Make printtup a bit faster

>> ... I'd put parts of out(print) function >> refactor in the next 2 days. I think it deserves a double check before >> working on *all* the out function. > > Well, sure. You *cannot* write a patch that breaks existing output > functions. Not at the start, and not at the end either. You > sho

Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row

On Mon, Sep 9, 2024 at 10:34 PM Jim Jones wrote: > > > Hi there > > On 26.08.24 02:00, jian he wrote: > > hi all. > > patch updated. > > simplified the code a lot. > > > > idea is same: > > COPY t_on_error_null FROM STDIN WITH (on_error set_to_null); > > > > If the STDIN number of columns is the s

Re: Incremental Sort Cost Estimation Instability

On Thu, 12 Sept 2024 at 21:51, Andrei Lepikhov wrote: > Initial problem causes wrong cost_sort estimation. Right now I think > about providing cost_sort() the sort clauses instead of (or in addition > to) the pathkeys. I'm not quite sure why the sort clauses matter any more than the EquivalenceCl

Re: Add has_large_object_privilege function

On 2024/09/10 17:45, Yugo NAGATA wrote: On Mon, 9 Sep 2024 22:59:34 +0900 Fujii Masao wrote: On 2024/07/02 16:34, Yugo NAGATA wrote: So, I would like to propose to add has_large_object_function for checking if a user has the privilege on a large object. +1 Thank you for your looking

Re: Add 64-bit XIDs into PostgreSQL 15

Michael, Maxim, > Apparently, the original thread will inevitably disintegrate into many > separate ones. > For me, looks like some kind of road map. One for 64-bit GUCs, another one to > remove > short file names from SLRUs and, to make things more complicated, [1] for cf > entry [0], > to get

Re: Incremental Sort Cost Estimation Instability

On 12/9/2024 03:05, David Rowley wrote: On Thu, 27 Jun 2024 at 03:00, Andrei Lepikhov wrote: I tried to invent a simple solution to fight this minor case. But the most clear and straightforward way here is to save a reference to the expression that triggered the PathKey creation inside the Path

[PATCH] Add some documentation on how to call internal functions

Hi, The documentation on extending using C functions, leaves a blank on how to call other internal Postgres functions.This can leave first-timers hanging.I think it’d be helpful to spend some paragraphs on discussing the DirectFunctionCall API.Here’s an attempt (also a PR[0]).Here’s the relevant HT

Re: PG_TEST_EXTRA and meson

Thanks Nazir, > > -# Test suites that are not safe by default but can be run if selected > > -# by the user via the whitespace-separated list in variable PG_TEST_EXTRA. > > -# Export PG_TEST_EXTRA so it can be checked in individual tap tests. > > -test_env.set('PG_TEST_EXTRA', get_option('PG_TEST_

Re: Allow logical failover slots to wait on synchronous replication

On Wed, Sep 11, 2024 at 2:40 AM John H wrote: > > Hi Shveta, > > On Sun, Sep 8, 2024 at 11:16 PM shveta malik wrote: > > > > > I was trying to have a look at the patch again, it doesn't apply on > > the head, needs rebase. > > > > Rebased with the latest changes. > > > Regarding 'mode = SyncRepWa

Re: [PATCH] Refactor SLRU to always use long file names

Hi Michael, > On Wed, Sep 11, 2024 at 04:07:06PM +0300, Aleksander Alekseev wrote: > > Commit 4ed8f0913bfd introduced long SLRU file names. The proposed > > patch removes SlruCtl->long_segment_names flag and makes SLRU always > > use long file names. This simplifies both the code and the API. > >

Re: Accept invalidation messages before the query starts inside a transaction

On 12/9/2024 08:31, David G. Johnston wrote: On Wednesday, September 11, 2024, Andrei Lepikhov > wrote: I don't know whether to classify this as a bug. [1] https://www.postgresql.org/docs/16/mvcc-caveats.html

Re: Add 64-bit XIDs into PostgreSQL 15

Apparently, the original thread will inevitably disintegrate into many separate ones. For me, looks like some kind of road map. One for 64-bit GUCs, another one to remove short file names from SLRUs and, to make things more complicated, [1] for cf entry [0], to get rid of MultiXactOffset wraparound

Re: Opinion poll: Sending an automated email to a thread when it gets added to the commitfest

On Thu, 12 Sept 2024 at 04:07, David Rowley wrote: > Maybe instead of the URLs showing the CF > number that the patch was first added to, if it could have a reference > in the URL that looks up the maximum CF which contains the patch and > show that one. e.g. https://commitfest.postgresql.org/late

Re: Trim the heap free memory

On Thu, 12 Sept 2024 at 14:40, shawn wang wrote: > Could you please perform another round of testing to ensure that everything > is functioning as expected with this modification? One way to get a few machines with various build systems testing this is to register the patch on the commitfest app

Re: not null constraints, again

> > On Wed, Sep 11, 2024 at 2:18 AM Alvaro Herrera > > wrote: > > > > > > Hello, here's a v2 of this patch. I have fixed --I think-- all the > > > issues you and Tender Wang reported (unless I declined a fix in some > > > previous email). > > > PREPARE constr_meta (name[]) AS with cte as ( sele

Re: [PATCH] Add roman support for to_number function

Hi, I have started working on the next version of the patch and have addressed the smaller issues identified by Tom. Before proceeding further, I would like to have opinions on some comments/questions in my previous email. Regards, Hunaid Sohail On Mon, Sep 9, 2024 at 5:45 PM Hunaid Sohail wrot