Re: Add \syncpipeline command to pgbench

On Fri, Jan 19, 2024 at 5:08 AM Michael Paquier wrote: > The logic looks sound, but I have a > comment about the docs: could it be better to group \syncpipeline with > \startpipeline and \endpipeline? \syncpipeline requires a pipeline to > work. I've updated the doc to group the commands. It

Re: pgbnech: allow to cancel queries during benchmark

On Mon, 15 Jan 2024 16:49:44 +0900 (JST) Tatsuo Ishii wrote: > > On Wed, 6 Sep 2023 20:13:34 +0900 > > Yugo NAGATA wrote: > > > >> I attached the updated patch v3. The changes since the previous > >> patch includes the following; > >> > >> I removed the unnecessary condition (&& false) that

logical decoding build wrong snapshot with subtransactions

This issue has been reported in the https://www.postgresql.org/message-id/18280-4c8060178cb41750%40postgresql.org Hoping for some feedback from kernel hackers, thanks! Hi, hackers, I've encountered a problem with logical decoding history snapshots. The specific error message is: "ERROR: could

Re: Change GUC hashtable to use simplehash?

On Wed, Jan 17, 2024 at 9:54 PM Heikki Linnakangas wrote: > Maybe something like: > > " > Building blocks for creating fast inlineable hash functions. The > functions in this file are not guaranteed to be stable between versions, > and may differ by hardware platform. Hence they must not be used

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Thu, Jan 18, 2024 at 1:30 PM John Naylor wrote: > > On Thu, Jan 18, 2024 at 8:31 AM Masahiko Sawada wrote: > > It seems we cannot make this work nicely. IIUC VacDeadItems is > > allocated in DSM and TidStore is embedded there. However, > > dead_items->items.area is a local pointer to

Re: the s_lock_stuck on perform_spin_delay

Hi, v6 attached which addressed all the items Robert suggested except the following 2 open items. They are handled differently. > > Here is the summary of the open-items, it would be great that Andres and > Matthias have a look at this when they have time. > >>> The LockBufHdr also used

Re: System username in pg_stat_activity

Hi, On Thu, Jan 18, 2024 at 04:01:33PM +0100, Magnus Hagander wrote: > On Mon, Jan 15, 2024 at 11:17 AM Bertrand Drouvot > > Did you forget to share the new revision (aka v4)? I can only see the > > "reorder_parallel_worker_bestart.patch" attached. > > I did. Here it is, and also including that

Re: Synchronizing slots from primary to standby

Here are some review comments for patch v63-0003. == Commit Message 1. This patch attempts to start slot-sync worker as a special process which is neither a bgworker nor an Auxiliary process. The benefit we get here is we can control the start-conditions of the worker which further allows us

Re: Synchronizing slots from primary to standby

On Fri, Jan 19, 2024 at 11:23 AM Amit Kapila wrote: > > > > 5 === (coming from v62-0002) > > > + Assert(tuplestore_tuple_count(res->tuplestore) == 1); > > > > > > Is it even possible for the related query to not return only one row? (I > > > think the > > > "count" ensures it). > > > > I

Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed

Hello, 15.01.2024 12:00, Alexander Lakhin wrote: If this approach looks promising to you, maybe we could add a submodule to perl/PostgreSQL/Test/ and use this functionality in other tests (e.g., in 019_replslot_limit) as well. Personally I think that having such a functionality for using in

Re: Add 64-bit XIDs into PostgreSQL 15

On Wed, Dec 13, 2023 at 5:56 PM Maxim Orlov wrote: > > Hi! > > Just to keep this thread up to date, here's a new version after recent > changes in SLRU. > I'm also change order of the patches in the set, to make adding initdb MOX > options after the > "core 64 xid" patch, since MOX patch is

Re: Improve the connection failure error messages

On Fri, Jan 12, 2024 at 7:06 PM Aleksander Alekseev wrote: > > Hi, > > Thanks for the patch. > > > Due to this behavior, it is not possible to add a test to show the > > error message as it is done for CREATE SUBSCRIPTION. > > Let me know if you think there is another way to add this test. > > I

Re: Synchronizing slots from primary to standby

On Wed, Jan 17, 2024 at 4:06 PM shveta malik wrote: > > > > > 5 === (coming from v62-0002) > > + Assert(tuplestore_tuple_count(res->tuplestore) == 1); > > > > Is it even possible for the related query to not return only one row? (I > > think the > > "count" ensures it). > > I think you are

Re: generate syscache info automatically

On Wed, Jan 17, 2024 at 7:46 PM Peter Eisentraut wrote: > > I updated the patch to use this style (but I swapped the first two > arguments from my example, so that the thing being created is named first). > > I also changed the names of the output files a bit to make them less > confusing. (I

Re: "ERROR: could not open relation with OID 16391" error was encountered when reindexing

On Wed, Jan 17, 2024 at 04:03:46PM +0800, feichanghong wrote: > It has been verified that the patch in the attachment can solve the > above problems. I sincerely look forward to your suggestions! Thanks for the patch. I have completely forgotten to update this thread. Except for a few comments

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx

On Thu, Jan 18, 2024 at 09:25:16AM +0100, Anthonin Bonnefoy wrote: > From what I can tell, there's no change in the behaviour. All paths > would eventually go through HandleSlashCmds's cleaning logic. This is > also mentioned in ignore_slash_options's comment. Yeah, I can confirm that. I would

Re: Synchronizing slots from primary to standby

On Wed, Jan 17, 2024 at 7:30 PM shveta malik wrote: > > On Wed, Jan 17, 2024 at 3:08 PM Bertrand Drouvot > wrote: > > > > Hi, > > > > On Tue, Jan 16, 2024 at 05:27:05PM +0530, shveta malik wrote: > > > PFA v62. Details: > > > > Thanks! > > > > > v62-003: > > > It is a new patch which attempts to

Re: btree: implement dynamic prefix truncation (was: Improving btree performance through specializing by key shape, take 2)

On Wed, Nov 1, 2023 at 2:42 AM Matthias van de Meent wrote: > > Hi, > > Currently, nbtree code compares each and every column of an index > tuple during the binary search on the index page. With large indexes > that have many duplicate prefix column values (e.g. an index on (bool, > bool, uuid) )

Re: Commitfest manager January 2024

On Fri, 19 Jan 2024 at 09:19, Peter Smith wrote: > > Hi Vignesh, > > If you would like any assistance processing the 100s of CF entries I > am happy to help in some way. Thanks Peter, that will be great. Regards, Vignesh

Re: Fix incorrect format placeholders in walreceiver.c

On Thu, Jan 18, 2024 at 09:32:55PM +0800, Yongtao Huang wrote: > I think the correct placeholder for var *startoff* should be *%d*. > Thanks for your time. Thanks, fixed. -- Michael signature.asc Description: PGP signature

Re: Add \syncpipeline command to pgbench

On Thu, Jan 18, 2024 at 09:48:28AM +0100, Anthonin Bonnefoy wrote: > PQsendSyncMessage() was added in > https://commitfest.postgresql.org/46/4262/. It allows users to add a > Sync message without flushing the buffer. > > As a follow-up, this change adds an additional meta-command to > pgbench,

Re: Commitfest manager January 2024

Hi Vignesh, If you would like any assistance processing the 100s of CF entries I am happy to help in some way. == Kind Regards,, Peter Smith. Fujitsu Australia

Re: ALTER ROLE documentation improvement

On Thu, Jan 18, 2024 at 02:44:35PM -0700, David G. Johnston wrote: > LGTM too. I didn't go looking for anything else related to this, but the > proposed changes all look needed. Committed. Thanks! -- Nathan Bossart Amazon Web Services: https://aws.amazon.com

Re: Synchronizing slots from primary to standby

On Thu, Jan 18, 2024 at 10:31 AM Peter Smith wrote: > > I have one question about the new code in v63-0002. > > == > src/backend/replication/logical/slotsync.c > > 1. ReplSlotSyncWorkerMain > > + Assert(SlotSyncWorker->pid == InvalidPid); > + > + /* > + * Startup process signaled the slot

Re: Network failure may prevent promotion

On Thu, Jan 18, 2024 at 03:42:28PM +0200, Heikki Linnakangas wrote: > Given that commit 728f86fec6 that introduced this issue was not strictly > required, perhaps we should just revert it for v16. Is there a point in keeping 728f86fec6 as well on HEAD? That does not strike me as wise to keep

Re: UUID v7

On Thu, Jan 18, 2024 at 11:31 AM Andrey Borodin wrote: > > Now I'm completely lost in time... I've set local time to NY (UTC-5). > > postgres=# select TIMESTAMP WITH TIME ZONE '2022-02-22 14:22:22-05' - > TIMESTAMP WITH TIME ZONE 'Tuesday, February 22, 2022 2:22:22.00 PM > GMT-05:00'; >

Re: remaining sql/json patches

On Fri, Jan 19, 2024 at 2:11 AM Alvaro Herrera wrote: > On 2024-Jan-18, Alvaro Herrera wrote: > > > commands/explain.c (Hmm, I think this is a preexisting bug actually) > > > > 3893 18 : case T_TableFuncScan: > > 3894 18 : Assert(rte->rtekind ==

Re: Strange Bitmapset manipulation in DiscreteKnapsack()

David Rowley writes: > On Fri, 19 Jan 2024 at 01:07, Andy Fan wrote: >> I find the following code in DiscreteKnapsack is weird. >> >> >> for (i = 0; i <= max_weight; ++i) >> { >> values[i] = 0; >> >> ** memory allocation here, and the num_items bit is removed

Re: the s_lock_stuck on perform_spin_delay

Hi, Here is the summary of the open-items, it would be great that Andres and Matthias have a look at this when they have time. 1. Shall we treat the LockBufHdr as a SpinLock usage. >> The LockBufHdr also used init_local_spin_delay / perform_spin_delay >> infrastruce and then it has the same

Re: UUID v7

On Thu, Jan 18, 2024 at 5:18 AM Andrey Borodin wrote: > Current patch version attached. I've addressed all other requests: > function renames, aliases, multiple functions instead of optional params, > cleaner catalog definitions, not throwing error when [var,ver,time] value > is unknown. > What

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 3:20 PM Robert Haas wrote: > > On Thu, Jan 18, 2024 at 10:09 AM Robert Haas wrote: > > Oh, I see. Good catch. > > > > I've now committed 0001. > > I have now also committed 0002 and 0003. I made some modifications to > 0003. Specifically: > > - I moved has_lpdead_items

Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo

On Thu, Jan 18, 2024 at 8:54 PM Amit Kapila wrote: > > On Thu, Jan 18, 2024 at 11:15 AM Peter Smith wrote: > > > > On Thu, Jan 18, 2024 at 12:55 PM Masahiko Sawada > > wrote: > > > > > ... > > > > > > Although we can improve it to handle this case too, I'm not sure it's > > > a bug. The doc

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [Fixed Already]

On Tue, Jan 16, 2024 at 3:43 AM Daniel Gustafsson wrote: > > On 16 Jan 2024, at 02:53, Kirk Wolak wrote: > > > > On Mon, Jan 15, 2024 at 9:03 AM Daniel Gustafsson > wrote: > > > On 15 Jan 2024, at 07:24, Kirk Wolak wol...@gmail.com>> wrote: > >... > > Okay, I took the

Re: Sequence Access Methods, round two

On Thu, Jan 18, 2024 at 04:54:06PM +0100, Matthias van de Meent wrote: > On Thu, 18 Jan 2024, 16:06 Peter Eisentraut, wrote: >> On 01.12.23 06:00, Michael Paquier wrote: >>> Please find attached a patch set that aims at implementing sequence >>> access methods, with callbacks following a model

Re: Synchronizing slots from primary to standby

On Tue, Jan 9, 2024 at 11:15 PM Zhijie Hou (Fujitsu) wrote: > > On Tuesday, January 9, 2024 9:17 AM Peter Smith wrote: > > ... > > > > 2. ALTER_REPLICATION_SLOT ... FAILOVER > > > > + > > + > > +FAILOVER [ > class="parameter">boolean ] > > + > > + > > +

Re: Add PQsendSyncMessage() to libpq

Hello, On 17/01/2024 07:30, Michael Paquier wrote: Thanks for double-checking. Done. Thank you very much for taking care of my patch! One thing that I noticed is that the TODO list on the PostgreSQL Wiki still contained an entry ( https://wiki.postgresql.org/wiki/Todo#libpq ) about adding

Re: minor replication slot docs edits

On Thu, Jan 18, 2024 at 9:49 PM Alvaro Herrera wrote: ... > > Another thing I noticed is that we could change all (or most of) the > tags to , but it's also a much larger > change. Having (some of?) these variable names be links would be useful > IMO. > +1 to do this. IMO these should all be

Re: 039_end_of_wal: error in "xl_tot_len zero" test

On Fri, Jan 19, 2024 at 1:47 AM Anton Voloshin wrote: > I believe there is a small problem in the 039_end_of_wal.pl's > "xl_tot_len zero" test. It supposes that after immediate shutdown the > server, upon startup recovery, should always produce a message matching > "invalid record length at .*:

Re: Built-in CTYPE provider

On Thu, 2024-01-18 at 13:53 +0100, Peter Eisentraut wrote: > I think that would be a terrible direction to take, because it would > regress the default sort order from "correct" to "useless". I don't agree that the current default is "correct". There are a lot of ways it can be wrong: * the

Re: Strange Bitmapset manipulation in DiscreteKnapsack()

On Thu, 18 Jan 2024 at 16:24, David Rowley wrote: > On Thu, 18 Jan 2024 at 15:22, Richard Guo wrote: > > Do you think we can use 'memcpy(a, b, BITMAPSET_SIZE(b->nwords))' > > directly in the new bms_replace_members() instead of copying the > > bitmapwords one by one, like: > > > > - i = 0; > >

Re: ALTER ROLE documentation improvement

On Sun, Jan 14, 2024 at 6:59 PM Nathan Bossart wrote: > On Sun, Jan 14, 2024 at 04:17:41PM +0530, vignesh C wrote: > > The attached v3 version patch has the changes for the same. > > LGTM. I'll wait a little while longer for additional feedback, but if none > materializes, I'll commit this

Re: Strange Bitmapset manipulation in DiscreteKnapsack()

On Fri, 19 Jan 2024 at 01:07, Andy Fan wrote: > I find the following code in DiscreteKnapsack is weird. > > > for (i = 0; i <= max_weight; ++i) > { > values[i] = 0; > > ** memory allocation here, and the num_items bit is removed later ** > > sets[i]

Re: UUID v7

We are not allowed to consider any time other than UTC. You need to write to the authors of the standard. I suppose this is a mistake. I know from experience that errors in such standards most often appear in examples. Nobody detects them at first. Everyone reads and checks ideas, not

Re: UUID v7

Aleksander Alekseev wrote on 1/18/2024 3:20 PM: Hi, Another question: how did you choose between using TimestampTz and Timestamp types? I realize that internally it's all the same. Maybe Timestamp will be slightly better since the way it is displayed doesn't depend on the session settings.

Re: UUID v7

Using localtime would be absurd. Especially since time goes back during summer time change. I believe our implementation should use UTC. No one forbids us from assuming that our local time for generating uuid is UTC. Andrey Borodin wrote on 1/18/2024 2:17 PM: On 17 Jan 2024, at 02:19, Jelte

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 10:09 AM Robert Haas wrote: > Oh, I see. Good catch. > > I've now committed 0001. I have now also committed 0002 and 0003. I made some modifications to 0003. Specifically: - I moved has_lpdead_items inside the loop over blocks instead of putting it at the function

Re: Built-in CTYPE provider

Peter Eisentraut wrote: > > If the Postgres default was bytewise sorting+locale-agnostic > > ctype functions directly derived from Unicode data files, > > as opposed to libc/$LANG at initdb time, the main > > annoyance would be that "ORDER BY textcol" would no > > longer be the

Re: the s_lock_stuck on perform_spin_delay

On Thu, Jan 18, 2024 at 1:30 PM Andy Fan wrote: > > You added an #include to dynahash.c despite making no other changes to > > the file. > > That's mainly because I put the code into miscadmin.h and spin.h depends > on miscadmin.h with MACROs. That's not a good reason. Headers need to include

Re: UUID v7

Hi Andrey, You'd better generate a test UUIDv7 for midnight 1 Jan 1970 UTC. In this case, the timestamp in UUIDv7 according to the new RFC must be filled with zeros. By extracting the timestamp from this test UUIDv7, you should get exactly midnight 1 Jan 1970 UTC. I also recommend this

Re: UUID v7

> On 18 Jan 2024, at 20:39, Andrey Borodin wrote: > > But 16455577420ns after 1582-10-15 00:00:00 UTC was 2022-02-22 19:22:22 > UTC. And that was 2022-02-23 00:22:22 in UTC-05. '2022-02-22 19:22:22 UTC' is exactly that moment which was encoded into example UUIDs. It's not

Re: the s_lock_stuck on perform_spin_delay

Hi Robert, Thanks for your attention! > On Thu, Jan 18, 2024 at 7:56 AM Andy Fan wrote: >> Do you still have interest with making some progress on this topic? > > Some, but it's definitely not my top priority. I wish I could give as > much attention as everyone would like to everyone's

Re: UUID v7

Hi Andrey, Aleksander Alekseev wrote: "If this is the case, I think the example is indeed wrong".  This is one of the reasons why I was categorically against any examples of implementation in the new RFC. The examples have been very poorly studied and discussed, and therefore it is better not

BUG: Former primary node might stuck when started as a standby

Hello hackers, [ reporting this bug here due to limitations of the bug reporting form ] When a node, that acted as a primary, becomes a standby as in the following script: [ ... some WAL-logged activity ... ] $primary->teardown_node; $standby->promote; $primary->enable_streaming($standby);

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 12:15 PM Peter Geoghegan wrote: > It's not okay if you fail to update the FSM a second time in the > second heap pass -- at least in some cases. It's reasonably frequent > for a page that has 0 usable free space when lazy_scan_prune returns > to go on to have almost BLCKSZ

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 11:46 AM Robert Haas wrote: > On Thu, Jan 18, 2024 at 11:17 AM Peter Geoghegan wrote: > > True. But the way that PageGetHeapFreeSpace() returns 0 for a page > > with 291 LP_DEAD stubs is a much older behavior. When that happens it > > is literally true that the page has

Re: remaining sql/json patches

On 2024-Jan-18, Alvaro Herrera wrote: > commands/explain.c (Hmm, I think this is a preexisting bug actually) > > 3893 18 : case T_TableFuncScan: > 3894 18 : Assert(rte->rtekind == RTE_TABLEFUNC); > 3895 18 : if

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 11:17 AM Peter Geoghegan wrote: > True. But the way that PageGetHeapFreeSpace() returns 0 for a page > with 291 LP_DEAD stubs is a much older behavior. When that happens it > is literally true that the page has lots of free space. And yet it's > not free space we can

Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan

On Tue, 16 Jan 2024 at 03:03, Peter Geoghegan wrote: > > On Mon, Jan 15, 2024 at 2:32 PM Matthias van de Meent > wrote: > > Can you pull these planner changes into their own commit(s)? > > As mentioned upthread, it's a significant change in behavior that > > should have separate consideration

Re: Increasing IndexTupleData.t_info from uint16 to uint32

On Thu, 18 Jan 2024 at 13:41, Montana Low wrote: > > The overall trend in machine learning embedding sizes has been growing > rapidly over the last few years from 128 up to 4K dimensions yielding > additional value and quality improvements. It's not clear when this trend in > growth will ease.

Re: UUID v7

Hi Andrey, > > Timestamp and TimestampTz are absolutely the same thing. > My question is not about Postgres data types. I'm asking about examples in > the standard. > > There's an example 017F22E2-79B0-7CC3-98C4-DC0C0C07398F. It is expected to be > generated on "Tuesday, February 22, 2022

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 10:43 AM Robert Haas wrote: > I think we're agreeing but I want to be sure. If we only set LP_DEAD > items to LP_UNUSED, that frees no space. But if doing so allows us to > truncate the line pointer array, that that frees a little bit of > space. Right? That's part of it,

Re: Increasing IndexTupleData.t_info from uint16 to uint32

I wrote: > On a micro level, this makes sizeof(IndexTupleData) be not maxaligned, > which is likely to cause problems on alignment-picky hardware, or else > result in space wastage if we were careful to MAXALIGN() everywhere. > (Which we should have been, but I don't care to bet on it.) A lot of

Re: index prefetching

On 1/17/24 09:45, Konstantin Knizhnik wrote: > I have integrated your prefetch patch in Neon and it actually works! > Moreover, I combined it with prefetch of leaf pages for IOS and it also > seems to work. > Cool! And do you think this is the right design/way to do this? > Just small notice:

Re: index prefetching

On 1/16/24 21:10, Konstantin Knizhnik wrote: > > ... > >> 4. I think that performing prefetch at executor level is really great >>> idea and so prefetch can be used by all indexes, including custom >>> indexes. But prefetch will be efficient only if index can provide fast >>> access to next TID

Re: Sequence Access Methods, round two

On Thu, 18 Jan 2024, 16:06 Peter Eisentraut, wrote: > > On 01.12.23 06:00, Michael Paquier wrote: > > Please find attached a patch set that aims at implementing sequence > > access methods, with callbacks following a model close to table and > > index AMs, with a few cases in mind: > > - Global

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 10:42 AM Robert Haas wrote: > Now, that said, I suspect that we actually could reduce FSM_CATEGORIES > somewhat without causing any real problems, because many tables are > going to have tuples that are all about the same size, and even in a > table where the sizes vary

Re: More new SQL/JSON item methods

On 18.01.24 15:25, Jeevan Chalke wrote: Peter, I didn't understand why the changes you did in your 0002 patch were required here. I did run the pgindent, and it didn't complain to me. So, just curious to know more about the changes. I have not merged those changes in this single patch.

Re: Increasing IndexTupleData.t_info from uint16 to uint32

Montana Low writes: > I've attached a patch that increases IndexTupleData.t_info from 16bits to > 32bits allowing for significantly larger index tuple sizes. I fear this idea is a non-starter because it'd break on-disk compatibility. Certainly, if we were to try to pursue it, there'd need to

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 10:09 AM Peter Geoghegan wrote: > The problem with your justification for moving things in that > direction (if any) is that it is occasionally not quite true: there > are at least some cases where line pointer truncation after making a > page's LP_DEAD items -> LP_UNUSED

Re: UUID v7

> On 18 Jan 2024, at 19:20, Aleksander Alekseev > wrote: > > Timestamp and TimestampTz are absolutely the same thing. My question is not about Postgres data types. I'm asking about examples in the standard. There's an example 017F22E2-79B0-7CC3-98C4-DC0C0C07398F. It is expected to be

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 9:53 AM Melanie Plageman wrote: > I believe I've done this in attached v10. Oh, I see. Good catch. I've now committed 0001. -- Robert Haas EDB: http://www.enterprisedb.com

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 8:52 AM Robert Haas wrote: > But I also said one more thing that I'd still like to hear your > thoughts about, which is: why is it right to update the FSM after the > second heap pass rather than the first one? I can't help but suspect > this is an algorithmic holdover

Re: Sequence Access Methods, round two

On 01.12.23 06:00, Michael Paquier wrote: Please find attached a patch set that aims at implementing sequence access methods, with callbacks following a model close to table and index AMs, with a few cases in mind: - Global sequences (including range-allocation, local caching). - Local custom

Re: System username in pg_stat_activity

On Mon, Jan 15, 2024 at 11:17 AM Bertrand Drouvot wrote: > > Hi, > > On Fri, Jan 12, 2024 at 05:16:53PM +0100, Magnus Hagander wrote: > > On Thu, Jan 11, 2024 at 5:55 PM Bertrand Drouvot > > wrote: > > > > > > I'm wondering if it would make sense to populate it for parallel workers > > > too. >

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

Hi. patch refactored based on "on_error {stop|ignore}" doc changes: --- a/doc/src/sgml/ref/copy.sgml +++ b/doc/src/sgml/ref/copy.sgml @@ -43,7 +43,7 @@ COPY { table_name [ ( column_name [, ...] ) | * } FORCE_NOT_NULL { ( column_name [, ...] ) | * } FORCE_NULL { ( column_name [, ...] ) |

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Wed, Jan 17, 2024 at 5:33 PM Melanie Plageman wrote: > > This does mean that something is not quite right with 0001 as well as > 0004. We'd end up checking if we are at 8GB much more often. I should > probably find a way to replicate the cadence on master. I believe I've done this in attached

Re: cleanup patches for incremental backup

On Thu, Jan 18, 2024 at 4:50 AM Matthias van de Meent wrote: > Sure, that's fine with me. OK, committed that way. -- Robert Haas EDB: http://www.enterprisedb.com

Re: UUID v7

Hi, > Another question: how did you choose between using TimestampTz and > Timestamp types? I realize that internally it's all the same. Maybe > Timestamp will be slightly better since the way it is displayed > doesn't depend on the session settings. Many people I talked to find > this part of

Re: Fix race condition in InvalidatePossiblyObsoleteSlot()

Hi, On Thu, Jan 18, 2024 at 04:59:39PM +0530, Bharath Rupireddy wrote: > IIUC, the issue is that we terminate the process holding the > replication slot, and the conflict cause that we recorded before > terminating the process changes in the next iteration due to the > advancement in

Re: POC: GROUP BY optimization

Just forgotten second attachment. -- regards, Andrei Lepikhov Postgres Professional diff --git a/src/backend/optimizer/path/pathkeys.c b/src/backend/optimizer/path/pathkeys.c index 1095b73dac..b612420547 100644 --- a/src/backend/optimizer/path/pathkeys.c +++

Re: the s_lock_stuck on perform_spin_delay

On Thu, Jan 18, 2024 at 7:56 AM Andy Fan wrote: > Do you still have interest with making some progress on this topic? Some, but it's definitely not my top priority. I wish I could give as much attention as everyone would like to everyone's patches, but I can't even come close. I think that the

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Wed, Jan 17, 2024 at 4:31 PM Peter Geoghegan wrote: > Actually, I suppose that we couldn't apply it independently of > nindexes==0. Then we'd call FreeSpaceMapVacuumRange() before our > second pass over the heap takes place for those LP_DEAD-containing > heap pages scanned since the last round

Re: Network failure may prevent promotion

On 18/01/2024 10:26, Kyotaro Horiguchi wrote: At Sun, 31 Dec 2023 20:07:41 +0900 (JST), Kyotaro Horiguchi wrote in We've noticed that when walreceiver is waiting for a connection to complete, standby does not immediately respond to promotion requests. In PG14, upon receiving a promotion

Fix incorrect format placeholders in walreceiver.c

Hi all, I think the correct placeholder for var *startoff* should be *%d*. Thanks for your time. Best Yongtao Huang 0001-Fix-incorrect-format-placeholders-in-walreceiver.c.patch Description: Binary data

Re: UUID v7

> On 17 Jan 2024, at 02:19, Jelte Fennema-Nio wrote: I want to ask Kyzer or Brad, I hope they will see this message. I'm working on the patch for time extraction for v1, v6 and v7. Do I understand correctly, that UUIDs contain local time, not UTC time? For examples in [0] I see that "A.6.

Re: the s_lock_stuck on perform_spin_delay

Hi Matthias / Robert: Do you still have interest with making some progress on this topic? > Robert Haas writes: > >> On Wed, Jan 10, 2024 at 10:17 PM Andy Fan wrote: >>> fixed in v2. >> >> Timing the spinlock wait seems like a separate patch from the new sanity >> checks. > > Yes, a separate

RE: Synchronizing slots from primary to standby

On Wednesday, January 17, 2024 6:30 PM shveta malik wrote: > PFA v63. I analyzed the security of the slotsync worker and replication connection a bit, and didn't find issue. Here is detail: 1) data security First, we are using the role used in primary_conninfo, the role used here is

Re: Built-in CTYPE provider

On 12.01.24 03:02, Jeff Davis wrote: New version attached. Changes: * Named collation object PG_C_UTF8, which seems like a good idea to prevent name conflicts with existing collations. The locale name is still C.UTF-8, which still makes sense to me because it matches the behavior of the libc

039_end_of_wal: error in "xl_tot_len zero" test

Hello, hackers, I believe there is a small problem in the 039_end_of_wal.pl's "xl_tot_len zero" test. It supposes that after immediate shutdown the server, upon startup recovery, should always produce a message matching "invalid record length at .*: wanted 24, got 0". However, if the

Increasing IndexTupleData.t_info from uint16 to uint32

The overall trend in machine learning embedding sizes has been growing rapidly over the last few years from 128 up to 4K dimensions yielding additional value and quality improvements. It's not clear when this trend in growth will ease. The leading text embedding models

Make a Bitset which is resetable

Hi, In [1], David and I talked about a requirement that a user just want to unset the all bits in a Bitmapset but keep the allocated memory un-deallocated for later use. It is impossible for the current Bitmapset. So David suggested a Bitset struct for this purpose. I start this new thread so

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

On 2024-01-18 16:59, Alexander Korotkov wrote: On Thu, Jan 18, 2024 at 4:16 AM torikoshia wrote: On 2024-01-18 10:10, jian he wrote: > On Thu, Jan 18, 2024 at 8:57 AM Masahiko Sawada > wrote: >> On Thu, Jan 18, 2024 at 6:38 AM Tom Lane wrote: >> > Kyotaro-san's suggestion isn't bad, though I

Re: Strange Bitmapset manipulation in DiscreteKnapsack()

Hi, David Rowley writes: > Given that the code original code was written in a very deliberate way > to avoid reallocations, I now think that we should maintain that. > > I've attached a patch which adds bms_replace_members(). It's basically > like bms_copy() but attempts to reuse the member

Re: Report planning memory in EXPLAIN ANALYZE

On 2024-Jan-18, Ashutosh Bapat wrote: > The EXPLAIN output produces something like below >explain_filter > - >Seq Scan on int8_tbl i8 (cost=N.N..N.N rows=N width=N) > Planning: > Memory: used=N bytes,

Re: remaining sql/json patches

I've been eyeballing the coverage report generated after applying all patches (but I only checked the code added by the 0008 patch). AFAICS the coverage is pretty good. Some uncovered paths: commands/explain.c (Hmm, I think this is a preexisting bug actually) 3893 18 :

Re: Fix race condition in InvalidatePossiblyObsoleteSlot()

On Mon, Jan 15, 2024 at 1:18 PM Bertrand Drouvot wrote: > > Hi hackers, > > While working on [1], we discovered (thanks Alexander for the testing) that an > conflicting active logical slot on a standby could be "terminated" without > leading to an "obsolete" message (see [2]). > > Indeed, in case

Re: Report planning memory in EXPLAIN ANALYZE

On Thu, Jan 18, 2024 at 4:42 PM Alvaro Herrera wrote: > > On 2024-Jan-18, Ashutosh Bapat wrote: > > Hmm ... TBH I don't like the "showed_planning" thing very much, but if > we need to conditionalize the printing of "Planning:" on whether we > print either of buffers or memory, maybe there's no

Re: Synchronizing slots from primary to standby

On Wed, Jan 17, 2024 at 4:00 PM shveta malik wrote: > > PFA v63. > 1. + /* User created slot with the same name exists, raise ERROR. */ + if (!synced) + ereport(ERROR, + errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), + errmsg("exiting from slot synchronization on receiving" +" the

Re: Reduce useless changes before reassembly during logical replication

On Thu, Jan 18, 2024 at 2:47 PM Amit Kapila wrote: > > On Thu, Jan 18, 2024 at 12:12 PM Bharath Rupireddy > wrote: > > > > On Wed, Jan 17, 2024 at 11:45 AM li jie wrote: > > > > > > Hi hackers, > > > > > > During logical replication, if there is a large write transaction, some > > > spill files

Re: Report planning memory in EXPLAIN ANALYZE

On 2024-Jan-18, Ashutosh Bapat wrote: Hmm ... TBH I don't like the "showed_planning" thing very much, but if we need to conditionalize the printing of "Planning:" on whether we print either of buffers or memory, maybe there's no way around something like what you propose. However, I don't

  1   2   >