Re: Using Expanded Objects other than Arrays from plpgsql

On Fri, Dec 6, 2024 at 4:51 PM Michel Pelletier wrote: > > My question is about nvals = nvals(graph) in that function above, the > object is flattened and then rexpanded, even after the object was expanded > and returned by wait() [1] into a r/w pointer. > ... > > mxm calls expand_matrix three

Re: Trim the heap free memory

On 9/18/24 04:56, shawn wang wrote: > Thank you very much for your response and suggestions. > > As you mentioned, the patch here is actually designed for glibc's > ptmalloc2 andis not applicable to other platforms. I will consider > supporting it only on the Linux platform in the future. In the m

Re: Add missing tab completion for ALTER TABLE ADD COLUMN IF NOT EXISTS

On Sun, 8 Dec 2024 at 03:35, Tomas Vondra wrote: > > Hi, > I took a quick look at this patch series, and it looks generally fine to > me. Barring objections, I'll get it committed. Yes, there's a couple > cosmetic details, and it needs a pgindent run, but I think I can take > care of that ... > Th

Fix early elog(FATAL)

main() says: /* * Fire up essential subsystems: error and memory management * * Code after this point is allowed to use elog/ereport, though * localization of messages may not work right away, and messages won't go * anywhere but stderr until G

Re: postgres_fdw: Provide better emulation of READ COMMITTED behavior

Etsuro Fujita writes: > On Fri, Dec 6, 2024 at 7:50 PM Andy Fan wrote: >> Apart from the above issue, what do you think about that we are using a >> 'SELECT pg_catalog.pg_refresh_snapshot()' to let the remote do the >> refresh_snapshot VS 'a new message type for this'? There are lots of >> thin

Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

Andres Freund writes: > On 2024-12-08 09:23:42 +0700, Andrei Lepikhov wrote: >> I think avoiding touching a hash table and an index under MergeJoin can also >> be beneficial. > How would you get significant wins for mergejoins? You need to go through both > inner and outer anyway? Yeah, sounds l

Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

Hi, On 2024-12-08 09:23:42 +0700, Andrei Lepikhov wrote: > To determine how difficult it could be, I wrote a prototype (very raw), > which shows how it works in action and how many subsystems we have to touch. Cool! > Also, I wonder why you think it could work with NestLoop only. It doesn't se

Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

On 12/8/24 06:13, Tom Lane wrote: Andres Freund writes: On 2024-12-07 17:06:52 -0500, Tom Lane wrote: One could imagine that we split up the join filter conditions into "depends on RHS" and "doesn't depend on RHS" subsets, and make the nestloop plan node evaluate the latter set only once per L

Re: [PATCH] Add roman support for to_number function

Hi, On 10/30/24 08:07, Hunaid Sohail wrote: > Hi, > > I have attached a rebased patch if someone wants to review in the next > CF. No changes as compared to v4. > > Regards, > Hunaid Sohail > Thanks for a nice patch. I did a quick review today, seems almost there, I only have a couple minor co

Re: CREATE SUBSCRIPTION - add missing test case

On 8/22/24 05:21, Peter Smith wrote: > ... >>> >>> I also don't see a test for this error condition. However, it is not >>> clear to me how important is it to cover this error code path. This >>> code has existed for a long time and I didn't notice any bugs related >>> to this. There is a possibili

Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

Hi, On 2024-12-07 17:06:52 -0500, Tom Lane wrote: > Andres Freund writes: > > ISTM that it shouldn't be expensive to recognize this type of join clause > > and > > pushes them down. While it could be done by the query's author, it seems > > worth > > handling this on our side. But maybe I'm mi

Re: Improved psql tab completion for joins

Hi, On 11/16/24 17:59, Andreas Karlsson wrote: > Hi, > > Here is a set of small patches which improve the tab completion of joins > in psql. The completion of select queries and DML is very primitive in > psql but since we already have completion of relation names after FROM > and JOIN I think th

Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

Andres Freund writes: > On 2024-12-07 17:06:52 -0500, Tom Lane wrote: >> One could imagine that we split up the join filter conditions into >> "depends on RHS" and "doesn't depend on RHS" subsets, and make the >> nestloop plan node evaluate the latter set only once per LHS row, >> and then skip th

Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

I've just realized that I replied not to the whole mailing list. This is a duplicate of mail sent to Andres. Thank you for the quick response. Some background using code and concepts of particular languages and frameworks: Exactly such queries are automatically built by Hibernate if using polymo

Re: [PATCH] immediately kill psql process if server is not running.

On 11/8/24 19:42, Srinath Reddy Sadipiralla wrote: > Hi , > > When a user tries to enter a large query, thinking the server is still > running, and to their surprise, they discover that the server has > crashed or stopped, I have observed that the psql process will still be > running if it is idle

Re: Add missing tab completion for ALTER TABLE ADD COLUMN IF NOT EXISTS

Hi, On 11/11/24 12:48, Karina Litskevich wrote: > ... > > I wrote: >> I hope to look more thoroughly into tab-complete.in.c tomorrow or on >> Monday to see if there are any other problems I can't see at first >> glance. I'll send another mail when I get to do this. > > As promised, I looked into

Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

Andres Freund writes: > ISTM that it shouldn't be expensive to recognize this type of join clause and > pushes them down. While it could be done by the query's author, it seems worth > handling this on our side. But maybe I'm missing something here? No, that condition *can't* be pushed down to t

Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

On 2024-12-07 16:37:32 -0500, Andres Freund wrote: > On 2024-12-07 21:30:46 +0300, Илья Жарков wrote: > > Note that the only record in *parent *table has dtype == 'A', but the join > > condition has p.dtype = 'B'. > > The query plan still shows Index Only Scan on *child *table with loops=1. > > The

Re: [PATCH] Fixed creation of empty .log files during log rotation

On 10/29/24 09:08, Арсений Косицын wrote: > > Hi everyone! > > A situation has been discovered in which empty .log files are being created. > > --Reproduce: > > 1) You need to set the following parameters in the "postgresql.conf" file: > > log_destination = 'csvlog' > logging_collector = on

Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

Hi, On 2024-12-07 21:30:46 +0300, Илья Жарков wrote: > Hi, could you help to understand why Postgres scans index in right table in > the following case: > > CREATE TABLE parent ( > > id integer PRIMARY KEY, > > dtype text > > ); > > > CREATE TABLE child ( > > id integer PRIMARY KEY > > ); >

Re: Statistics Import and Export

On Sat, 2024-12-07 at 14:56 -0500, Corey Huinker wrote: > This makes sense, though perhaps instead of --schema-only perhaps we > should pass both --no-statistics and --no-data. I don't envision a > fourth option to the new data/schema/stats triumvirate, but --no- > statistics shouldn't have a beari

Re: meson missing test dependencies

Hi, On 2024-12-06 18:54:25 +0100, Peter Eisentraut wrote: > On 05.12.24 21:10, Andres Freund wrote: > > On 2024-12-05 20:08:24 +0100, Peter Eisentraut wrote: > > > On 03.12.24 17:01, Andres Freund wrote: > > > > On 2024-12-02 11:10:56 +0100, Peter Eisentraut wrote: > > > > That's unfortunately a v

Re: Statistics Import and Export

On Sat, Dec 7, 2024 at 2:27 PM Jeff Davis wrote: > On Tue, 2024-11-26 at 17:11 -0500, Corey Huinker wrote: > > > > > * Why does binary upgrade cause statistics to be dumped? Can you > > > just > > > make pg_upgrade specify the appropriate set of flags? > > > > > > > > > That decision goes back a

Re: SQL:2011 application time

On 12/4/24 03:15, Peter Eisentraut wrote: >> I have attached three patches that show how that could be done. (This would work in conjunction >> with your new tests. (Although now we could also test GiST with replica identity full?)) >> >> The comment block for IsIndexUsableForReplicaIdentityFu

Re: Statistics Import and Export

On Tue, 2024-11-26 at 17:11 -0500, Corey Huinker wrote: > > > * Why does binary upgrade cause statistics to be dumped? Can you > > just > > make pg_upgrade specify the appropriate set of flags? > > > > > That decision goes back a ways, I tried to dig in the archives last > night but I was getti

Do not scan index in right table if condition for left join evaluates to false using columns in left table

Hi, could you help to understand why Postgres scans index in right table in the following case: CREATE TABLE parent ( > id integer PRIMARY KEY, > dtype text > ); CREATE TABLE child ( > id integer PRIMARY KEY > ); INSERT INTO parent (id, dtype) values (1, 'A'); > INSERT INTO child (id) va

Re: Support for unsigned integer types

Jack Bay writes: > Would it be possible to add support for unsigned 64-bit and unsigned > 32-bit integers to postgresql? This has been discussed before, and we've concluded that the impact on the numeric promotion hierarchy (that is, implicit-cast rules among the integer types) would probably be

RE: Proposal for Updating CRC32C with AVX-512 Algorithm.

> Sorry for going back so far, but this thread was pointed out to me, and this > aspect > of the design could use some more discussion: > > + * pg_crc32c_avx512(): compute the crc32c of the buffer, where the > + * buffer length must be at least 256, and a multiple of 64. Based > > There is anoth

Add a warning message when using unencrypted passwords

Hello, We've got a long tradition of telling people not to use unencrypted passwords in CREATE ROLE and ALTER ROLE because the queries may be logged. We try to encourage them to use \password in psql, and related techniques on other tools. Users usually want us to stop logging passwords, but this

Re: Windows pg_basebackup unable to create >2GB pg_wal.tar tarballs ("could not close file: Invalid argument" when creating pg_wal.tar of size ~ 2^31 bytes)

On Fri, Dec 6, 2024 at 11:31 AM Thomas Munro wrote: > Some better new: > > 1. _chsize_s does in fact seem to work in an msvcrt.dll build. > Thanks to Andres for testing that for me on Windows with a standalone > 2 line program on ucrt and msvcrt runtimes. > > 2. MinGW always has _chsize_s, but

Support for unsigned integer types

Unsigned integers are a widely used type and can be important for compact and well-aligned data structures, but are not currently available in PostgreSQL. In particular unsigned 64-bit integers and unsigned 32-bit integers are desirable as identifiers. They unambiguously correspond to specific hex

Re: doc: Remove LC_COLLATE and LC_CTYPE from SHOW command

On 04.12.24 09:53, Pierre Giraud wrote: Since version 16, the read-only server settings lc_collate and lc_ctype have been removed [1]. Unfortunately, the documentation has been updated only partially. Attached is a patch to also update the page for the "SHOW" SQL command and remove the corres

Error with DEFAULT VALUE in temp table

Hi everyone, I found one bug, when you delete temporary table with DEFAULT VALUE. The row about this VALUE in the pg_event_trigger_dropped_objects() contains “False” in the column “is_temporary”. But if you look at column “name_obj”, you see “for pg_temp.table_name”. So PostgreSQL know, that it is

Re: clean up create|alter domain stmt incompatiable constraint error case and add regression test

On Mon, 11 Nov 2024 at 13:59, jian he wrote: > > hi. Hi! Looks like this patch is now part of v6 from here [0]. Should we close [1] CF entry? [0] https://www.postgresql.org/message-id/flat/CALdSSPhqfvKbDwqJaY=yeepi_aq61gmmpw88i6zh7cmg_2z...@mail.gmail.com [1] https://commitfest.postgresql.org/51

Re: shared-memory based stats collector - v70

Hi! On 04.12.2024 18:24, Bertrand Drouvot wrote: Thanks! I've the feeling that something has to be fixed, see my comments in [1]. It might be that the failed assertion does not handle a "valid" scenario. [1]: https://www.postgresql.org/message-id/Z1BzI/eMTCOKA%2Bj6%40ip-10-97-1-34.eu-west-3.co

Re: postgres_fdw: Provide better emulation of READ COMMITTED behavior

On Fri, Dec 6, 2024 at 7:50 PM Andy Fan wrote: > Apart from the above issue, what do you think about that we are using a > 'SELECT pg_catalog.pg_refresh_snapshot()' to let the remote do the > refresh_snapshot VS 'a new message type for this'? There are lots of > things happen in the 'SELECT' way

Re: postgres_fdw: Provide better emulation of READ COMMITTED behavior

On Fri, Dec 6, 2024 at 2:37 AM Robert Haas wrote: > I have a hard time seeing how this would work if cursors are in use on > the main server. Say I do this: > > DECLARE foo CURSOR FOR SELECT * FROM ft1 UNION ALL SELECT * FROM ft2; > ...fetch some rows from cursor foo but few enough that we only sc

RE: Proposal for Updating CRC32C with AVX-512 Algorithm.

> [0] https://cirrus-ci.com/task/6023394207989760 > [1] https://cirrus-ci.com/task/5460444254568448 > [2] https://cirrus-ci.com/task/6586344161411072 I was able to fix [0] and [1], but I can't think of why [2] fails. When I tried to reproduce this locally, I get a different unrelated error. Any i

Re: Why we need to check for local buffers in BufferIsExclusiveLocked and BufferIsDirty?

> On Fri, 06 Dec 2024 16:40:51 +0530 Nazir Bilal Yavuz > wrote ---   > LGTM. > Regards, > Nazir Bilal Yavuz > Microsoft hi nazir, sorry i didn't get,what you meant to say is the assert failure which i said is correct and does my patch to this looks good?