Re: Fixing pgbench init overflow

On Sat, 23 Dec 2023 at 15:22, Tatsuo Ishii wrote: > > > >> >> On Sat, 23 Dec 2023 at 07:18, Chen Hao Hsu wrote: >>> Hello, >>> >>> pgbench mixes int and int64 to initialize the tables. >>> When a large enough scale factor is passed, initPopulateTable >>> overflows leading to it never

Re: Fixing pgbench init overflow

> > On Sat, 23 Dec 2023 at 07:18, Chen Hao Hsu wrote: >> Hello, >> >> pgbench mixes int and int64 to initialize the tables. >> When a large enough scale factor is passed, initPopulateTable >> overflows leading to it never completing, ie. >> >> 214740 of 22 tuples (97%) of >>

Re: Transaction timeout

> 在 2023年12月23日，11:35，Junwang Zhao 写道： > > On Sat, Dec 23, 2023 at 11:17 AM Japin Li wrote: >> >> a >>> On Sat, 23 Dec 2023 at 10:40, Japin Li wrote: >>> On Sat, 23 Dec 2023 at 08:32, Japin Li wrote: On Fri, 22 Dec 2023 at 23:30, Junwang Zhao wrote: > On Fri, Dec 22, 2023 at

Re: Fixing pgbench init overflow

On Sat, 23 Dec 2023 at 07:18, Chen Hao Hsu wrote: > Hello, > > pgbench mixes int and int64 to initialize the tables. > When a large enough scale factor is passed, initPopulateTable > overflows leading to it never completing, ie. > > 214740 of 22 tuples (97%) of > pgbench_accounts

Re: Transaction timeout

On Sat, Dec 23, 2023 at 11:17 AM Japin Li wrote: > > a > On Sat, 23 Dec 2023 at 10:40, Japin Li wrote: > > On Sat, 23 Dec 2023 at 08:32, Japin Li wrote: > >> On Fri, 22 Dec 2023 at 23:30, Junwang Zhao wrote: > >>> On Fri, Dec 22, 2023 at 10:44 PM Japin Li wrote: > > > On Fri,

Re: Fixing backslash dot for COPY FROM...CSV

On Fri, 22 Dec 2023 at 01:17, Daniel Verite wrote: > > vignesh C wrote: > > > Thanks for the updated patch, any reason why this is handled only in csv. > > postgres=# copy test1 from '/home/vignesh/postgres/inst/bin/copy1.out'; > > COPY 1 > > postgres=# select * from test1; > > c1 > >

Commitfest manager January 2024

Hi, I didn't see anyone volunteering for the January Commitfest, so I'll volunteer to be CF manager for January 2024 Commitfest. Regards, Vignesh

Re: Transaction timeout

a On Sat, 23 Dec 2023 at 10:40, Japin Li wrote: > On Sat, 23 Dec 2023 at 08:32, Japin Li wrote: >> On Fri, 22 Dec 2023 at 23:30, Junwang Zhao wrote: >>> On Fri, Dec 22, 2023 at 10:44 PM Japin Li wrote: On Fri, 22 Dec 2023 at 22:37, Junwang Zhao wrote: > On Fri, Dec 22,

Re: Transaction timeout

On Sat, Dec 23, 2023 at 10:40 AM Japin Li wrote: > > > On Sat, 23 Dec 2023 at 08:32, Japin Li wrote: > > On Fri, 22 Dec 2023 at 23:30, Junwang Zhao wrote: > >> On Fri, Dec 22, 2023 at 10:44 PM Japin Li wrote: > >>> > >>> > >>> On Fri, 22 Dec 2023 at 22:37, Junwang Zhao wrote: > >>> > On Fri,

Re: Transaction timeout

On Sat, 23 Dec 2023 at 08:32, Japin Li wrote: > On Fri, 22 Dec 2023 at 23:30, Junwang Zhao wrote: >> On Fri, Dec 22, 2023 at 10:44 PM Japin Li wrote: >>> >>> >>> On Fri, 22 Dec 2023 at 22:37, Junwang Zhao wrote: >>> > On Fri, Dec 22, 2023 at 10:25 PM Japin Li wrote: >>> >> I try to set

Re: A typo in a messsage?

On Fri, Dec 22, 2023 at 1:50 PM Kyotaro Horiguchi wrote: > > I found the following message introduced by a recent commit. > > > errdetail("The first unsummarized LSN is this range is %X/%X.", > > Shouldn't the "is" following "LSN" be "in"? I think you're right, will push.

Re: date_trunc function in interval version

On Sat, Dec 23, 2023 at 5:26 AM Przemysław Sztoch wrote: > > In my opinion date_trunc is very good name. > Truncated data is timestamp type, not interval. > First parameter has same meaning in original date_trunc and in my new version. > New version provides only more granularity. I haven't

Re: Transaction timeout

On Fri, 22 Dec 2023 at 23:30, Junwang Zhao wrote: > On Fri, Dec 22, 2023 at 10:44 PM Japin Li wrote: >> >> >> On Fri, 22 Dec 2023 at 22:37, Junwang Zhao wrote: >> > On Fri, Dec 22, 2023 at 10:25 PM Japin Li wrote: >> >> I try to set idle_in_transaction_session_timeout after begin

Fixing pgbench init overflow

Hello, pgbench mixes int and int64 to initialize the tables. When a large enough scale factor is passed, initPopulateTable overflows leading to it never completing, ie. 214740 of 22 tuples (97%) of pgbench_accounts done (elapsed 4038.83 s, remaining 98.93 s) -214740 of 22

Re: date_trunc function in interval version

In my opinion date_trunc is very good name. Truncated data is timestamp type, not interval. First parameter has same meaning in original date_trunc and in my new version. New version provides only more granularity. Pavel Stehule wrote on 12/22/2023 8:43 PM: Hi pá 22. 12. 2023 v 20:26

Re: authentication/t/001_password.pl trashes ~/.psql_history

I wrote: > I happened to notice this stuff getting added to my .psql_history: > \echo background_psql: ready > SET password_encryption='scram-sha-256'; > ; > \echo background_psql: QUERY_SEPARATOR > SET scram_iterations=42; > ; > \echo background_psql: QUERY_SEPARATOR > \password scram_role_iter >

Re: May be BUG. Periodic burst growth of the checkpoint_req counter on replica.

Hi, Anton! On Mon, Dec 4, 2023 at 3:50 AM Anton A. Melnikov wrote: > Thanks for remarks! > > On 28.11.2023 21:34, Alexander Korotkov wrote: > > After examining the second patch > > ("v2-0001-Add-restartpoint-stats.patch"), it appears that adding > > additional statistics as outlined in the

Re: [PATCHES] Post-special page storage TDE support

Hi again! Per some offline discussion with Stephen, I've continued to work on some modifications here; this particular patchset is intended to facilitate review by highlighting the mechanical nature of many of these changes. As such, I have taken the following approach to this rework: 0001 -

Re: Set all variable-length fields of pg_attribute to null on column drop

On 22.12.23 10:05, Alvaro Herrera wrote: On 2023-Nov-30, Peter Eisentraut wrote: I noticed that when a column is dropped, RemoveAttributeById() clears out certain fields in pg_attribute, but it leaves the variable-length fields at the end (attacl, attoptions, and attfdwoptions) unchanged. This

Re: pg_upgrade --copy-file-range

On Sat, Dec 23, 2023 at 9:40 AM Peter Eisentraut wrote: > On 13.11.23 08:15, Peter Eisentraut wrote: > > On 08.10.23 07:15, Thomas Munro wrote: > >>> About your patch: > >>> > >>> I think you should have a "check" function called from > >>> check_new_cluster(). That check function can then also

Re: pg_upgrade --copy-file-range

On 13.11.23 08:15, Peter Eisentraut wrote: On 08.10.23 07:15, Thomas Munro wrote: About your patch: I think you should have a "check" function called from check_new_cluster().  That check function can then also handle the "not supported" case, and you don't need to handle that in

Re: Teach predtest about IS [NOT] proofs

James Coleman writes: > I've not yet applied all of your feedback, but I wanted to get an > initial read on your thoughts on how using switch statements ends up > looking. Attached is a single (pure refactor) patch that converts the > various if/else levels that check things like node tag and >

Re: date_trunc function in interval version

Hi pá 22. 12. 2023 v 20:26 odesílatel Przemysław Sztoch napsal: > Hello. > There is date_trunc(interval, timestamptz, timezone) function. > First parameter can be '5 year', '2 month', '6 hour', '3 hour', '15 > minute', '10 second' etc. > should not be named interval_trunc instead? In this case

date_trunc function in interval version

Hello. There is date_trunc(interval, timestamptz, timezone) function. First parameter can be '5 year', '2 month', '6 hour', '3 hour', '15 minute', '10 second' etc. -- Przemysław Sztoch | Mobile +48 509 99 00 66 diff --git a/src/backend/utils/adt/timestamp.c b/src/backend/utils/adt/timestamp.c

Re: ci: Build standalone INSTALL file

Michael Paquier writes: > On Thu, Dec 21, 2023 at 02:22:02PM -0500, Tom Lane wrote: >> Here's a draft patch for this. Most of it is mechanical removal of >> infrastructure for building the INSTALL file. If anyone wants to >> bikeshed on the new wording of README, feel free. > Thanks for

Re: Avoid computing ORDER BY junk columns unnecessarily

Heikki Linnakangas writes: > On 22/12/2023 17:24, Tom Lane wrote: >> How much of your patchset still makes sense if we assume that we >> can always extract the ORDER BY column values from the index? > That would make it much less interesting. But I don't think that's a > good assumption.

Re: Optimization outcome depends on the index order

On 22/12/2023 11:48, Alexander Korotkov wrote: > Because we must trust all predictions made by the planner, we just > choose the most trustworthy path. According to the planner logic, it is > a path with a smaller selectivity. We can make mistakes anyway just > because of the nature of

Re: [DOC] Introducing Quick Start Guide to PL/pgSQL and PL/Python Documentation

pá 22. 12. 2023 v 15:50 odesílatel Japin Li napsal: > > On Thu, 21 Dec 2023 at 21:03, Pavel Stehule > wrote: > > Hi > > > > čt 21. 12. 2023 v 13:37 odesílatel Ishaan Adarsh > > napsal: > > > >> The recent documentation patches are part of my GSoC 2023 project > >> < >

Re: Avoid computing ORDER BY junk columns unnecessarily

On 22/12/2023 17:24, Tom Lane wrote: Heikki Linnakangas writes: It won't help in all cases though, the index might not store the original value in the first place. I'm a little skeptical that an index could produce an accurate ORDER BY result if it doesn't store the values-to-be-sorted

Re: Transaction timeout

On Fri, Dec 22, 2023 at 10:44 PM Japin Li wrote: > > > On Fri, 22 Dec 2023 at 22:37, Junwang Zhao wrote: > > On Fri, Dec 22, 2023 at 10:25 PM Japin Li wrote: > >> I try to set idle_in_transaction_session_timeout after begin transaction, > >> it changes immediately, so I think

Re: Avoid computing ORDER BY junk columns unnecessarily

Heikki Linnakangas writes: > Hmm, so return the computed column from the index instead of recomputing > it? Yeah, that makes sense too and would help in this example. Yeah, that's been on the to-do list for ages. The main problems are (1) we need the planner to not spend too much effort on

Re: Teach predtest about IS [NOT] proofs

On Thu, Dec 14, 2023 at 4:38 PM Tom Lane wrote: > > James Coleman writes: > > On Wed, Dec 13, 2023 at 1:36 PM Tom Lane wrote: > >> I don't have an objection in principle to adding more smarts to > >> predtest.c. However, we should be wary of slowing down cases where > >> no BooleanTests are

Re: [DOC] Introducing Quick Start Guide to PL/pgSQL and PL/Python Documentation

On Thu, 21 Dec 2023 at 21:03, Pavel Stehule wrote: > Hi > > čt 21. 12. 2023 v 13:37 odesílatel Ishaan Adarsh > napsal: > >> The recent documentation patches are part of my GSoC 2023 project >> >> to

Re: Transaction timeout

On Fri, 22 Dec 2023 at 22:37, Junwang Zhao wrote: > On Fri, Dec 22, 2023 at 10:25 PM Japin Li wrote: >> I try to set idle_in_transaction_session_timeout after begin transaction, >> it changes immediately, so I think transaction_timeout should also be take >> immediately. > > Ah, right,

Re: Transaction timeout

On Fri, Dec 22, 2023 at 10:25 PM Japin Li wrote: > > > On Fri, 22 Dec 2023 at 20:29, Junwang Zhao wrote: > > On Fri, Dec 22, 2023 at 1:39 PM Japin Li wrote: > >> > >> > >> On Tue, 19 Dec 2023 at 22:06, Japin Li wrote: > >> > On Tue, 19 Dec 2023 at 18:27, Andrey M. Borodin > >> > wrote: > >>

Re: Synchronizing slots from primary to standby

Hi, On Fri, Dec 22, 2023 at 04:02:21PM +0530, shveta malik wrote: > PFA v53. Changes are: Thanks! > patch002: > 2) Addressed comments in [2] for v52-002. > 3) Fixed CFBot failure. The failure was caused by an assert in > wait_for_primary_slot_catchup() for null confirmed_lsn received. In >

Re: Transaction timeout

On Fri, 22 Dec 2023 at 20:29, Junwang Zhao wrote: > On Fri, Dec 22, 2023 at 1:39 PM Japin Li wrote: >> >> >> On Tue, 19 Dec 2023 at 22:06, Japin Li wrote: >> > On Tue, 19 Dec 2023 at 18:27, Andrey M. Borodin >> > wrote: >> >>> On 19 Dec 2023, at 13:26, Andrey M. Borodin wrote: >> >>> >>

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

On Thu, Dec 21, 2023 at 6:27 PM Andres Freund wrote: > > Could either of you summarize what the design changes you've made in the last > months are and why you've done them? Unfortunately this thread is very long, > and the comments in the file just say "FIXME" in places that apparently are >

Re: Remove MSVC scripts from the tree

On 2023-12-21 Th 18:20, Michael Paquier wrote: On Thu, Dec 21, 2023 at 03:43:32PM -0500, Andrew Dunstan wrote: On 2023-12-21 Th 03:01, Michael Paquier wrote: Andrew, was the original target of pgperlsyncheck committers and hackers who played with the MSVC scripts but could not run sanity

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> On 19 Dec 2023, at 10:34, Dilip Kumar wrote: Just a side node. It seems like commit log is kind of antipattern of data contention. Even when we build a super-optimized SLRU. Nearby **bits** are written by different CPUs. I think that banks and locks are good thing. But also we could

Re: remaining sql/json patches

Hi v33-0007-SQL-JSON-query-functions.patch, commit message: This introduces the SQL/JSON functions for querying JSON data using jsonpath expressions. The functions are: should it be "These functions are" + +Returns true if the SQL/JSON path_expression +applied to the

Re: Transaction timeout

On Fri, Dec 22, 2023 at 1:39 PM Japin Li wrote: > > > On Tue, 19 Dec 2023 at 22:06, Japin Li wrote: > > On Tue, 19 Dec 2023 at 18:27, Andrey M. Borodin > > wrote: > >>> On 19 Dec 2023, at 13:26, Andrey M. Borodin wrote: > >>> > >>> I don’t have Windows machine, so I hope CF bot will pick

Re: Trigger violates foreign key constraint

On Fri, 2023-12-22 at 10:59 +0300, Pavel Luzanov wrote: > Please, consider small suggestion to replace last sentence. > > - This is not considered a bug, and it is the responsibility of the user > to write triggers so that such problems are avoided. > + It is the trigger programmer's

Re: Built-in CTYPE provider

Robert Haas wrote: > For someone who is currently defaulting to es_ES.utf8 or fr_FR.utf8, > a change to C.utf8 would be a much bigger problem, I would > think. Their alphabet isn't in code point order, and so things would > be alphabetized wrongly. > That might be OK if they don't care

Re: Set log_lock_waits=on by default

On Thu, 2023-12-21 at 09:14 -0500, Robert Haas wrote: > > I think it depends somewhat on the lock type, and also on your > threshold for what constitutes a problem. For example, you can wait > for 1 second for a relation extension lock pretty easily, I think, > just because the I/O system is

Re: Avoid computing ORDER BY junk columns unnecessarily

On 22/12/2023 11:05, Xiaoran Wang wrote: I haven't dug into your patch yet, but for this problem, I have another idea. --- explain verbose   select foo from mytable order by sha256(bar::bytea);                                             QUERY PLAN

Re: Synchronizing slots from primary to standby

On Thu, Dec 21, 2023 at 6:37 PM Hayato Kuroda (Fujitsu) wrote: > > Dear Shveta, > > Thanks for updating the patch! Here is my comments for v52-0002. Thanks for the feedback Kuroda-san. I have addressed these in v53. > ~ > system-views.sgml > > 01. > > ``` > + > + > + > +

Re: Set log_lock_waits=on by default

Re: Robert Haas > On Thu, Dec 21, 2023 at 8:29 AM Laurenz Albe wrote: > > Here is a patch to implement this. > > Being stuck behind a lock for more than a second is almost > > always a problem, so it is reasonable to turn this on by default. > > I think it depends somewhat on the lock type, and

Re: Optimization outcome depends on the index order

On Fri, Dec 22, 2023 at 8:53 AM Andrei Lepikhov wrote: > On 21/12/2023 12:10, Alexander Korotkov wrote: > > I took a closer look at the patch in [9]. I should drop my argument > > about breaking the model, because add_path() already considers other > > aspects than just costs. But I have two

Re: [meson] expose buildtype debug/optimization info to pg_config

Hi, On Fri, Dec 15, 2023 at 10:20 PM Andres Freund wrote: > > Hi, > > On 2023-12-14 17:24:58 +0800, Junwang Zhao wrote: > > On Thu, Dec 14, 2023 at 4:50 PM Peter Eisentraut > > wrote: > > > > > > On 12.12.23 11:40, Junwang Zhao wrote: > > > > build system using configure set VAL_CFLAGS with

RE: Synchronizing slots from primary to standby

On Thursday, December 21, 2023 5:39 PM Bertrand Drouvot wrote: > > On Thu, Dec 21, 2023 at 02:23:12AM +, Zhijie Hou (Fujitsu) wrote: > > On Wednesday, December 20, 2023 8:42 PM Zhijie Hou (Fujitsu) > wrote: > > > > > > Attach the V51 patch set which addressed Kuroda-san's comments. > > > I

Re: brininsert optimization opportunity

Hi All, not sure how to "Specify thread msgid" - choose one which i think is close to my new feature request. query: SELECT count(1) FROM table1 t1 JOIN table2 t2 ON t1.id = t2.id WHERE t1.a_indexed_col='some_value' OR t2.a_indexed_col='some_vable'; can the server automatically replace the

Re: Stack overflow issue

On 24/11/2023 21:14, Heikki Linnakangas wrote: What do you think? Hello! Thank you for researching the problem! I'm more of a tester than a developer, so I was able to check the patches from that side. I've configured the server with CFLAGS=" -O0" and cassert enabled and checked the following

Re: planner chooses incremental but not the best one

On 15/12/2023 09:58, Richard Guo wrote: On Thu, Dec 14, 2023 at 6:02 PM Richard Guo wrote: It seems that we need to improve estimate of distinct values in estimate_num_groups() when taking the selectivity of restrictions into account. In 84f9a35e3 we changed to a new

Re: Set all variable-length fields of pg_attribute to null on column drop

On 2023-Nov-30, Peter Eisentraut wrote: > I noticed that when a column is dropped, RemoveAttributeById() clears out > certain fields in pg_attribute, but it leaves the variable-length fields at > the end (attacl, attoptions, and attfdwoptions) unchanged. This is probably > harmless, but it seems

Re: Avoid computing ORDER BY junk columns unnecessarily

Hi Heikii, I haven't dug into your patch yet, but for this problem, I have another idea. --- explain verbose select foo from mytable order by sha256(bar::bytea); QUERY PLAN

Re: Trigger violates foreign key constraint

One more not documented issue with system triggers. It might be worth considering together. CREATE ROLE app_owner; CREATE TABLE t (     id    int PRIMARY KEY,     parent_id int REFERENCES t(id) ); ALTER TABLE t OWNER TO app_owner; -- No actions by application owner REVOKE ALL ON t FROM

Re: planner chooses incremental but not the best one

The possible solution of one scenario I can come up with so far is the query's predicate columns and group columns belonging to one table . For a query that contains where clause, perhaps num_groups could be estimated according to the following formula. num_groups = ndistinct(pred_col_1,