Re: Re: proposal: schema variables

On 2025-Jan-17, Bruce Momjian wrote: > Is this really something we are considering applying, since it has been > around for years? I am unclear on that and we had better know if we are > going to continue reviewing this. The fact that the patch has been around for years doesn't automatically mea

Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

> On 20 Jan 2025, at 01:26, Koshi Shibagaki (Fujitsu) > wrote: > > Thank you for moving this discussion forward. > >> Maybe we could document that the test should fail if fips is enabled? >> >> FWIW I have not tested at all on a fips enabled machine. I will see about >> doing >> that... > I t

Re: Coccinelle for PostgreSQL development [1/N]: coccicheck.py

On Sun, Jan 19, 2025 at 2:10 AM Michael Paquier wrote: > On Sat, Jan 18, 2025 at 08:44:00PM +0100, Mats Kindahl wrote: > > For PostgreSQL 16, Peter extended the palloc()/pg_malloc() interface in > > commit 2016055a92f to provide more type-safety, but these functions are > not > > widely used. Thi

Re: [PATCH] Add roman support for to_number function

Hi Tom, On Sat, Jan 18, 2025 at 5:27 AM Tom Lane wrote: > Hunaid Sohail writes: > > I’ve attached a new patch that addresses comments 2, 3, and 4 from Tomas. > > I'm still quite unhappy that this doesn't tolerate trailing > whitespace. That's not how other format patterns work, and it makes >

Re: improve DEBUG1 logging of parallel workers for CREATE INDEX?

Le lun. 20 janv. 2025 à 04:28, Sami Imseih a écrit : > > > > Hmm. I am reading Tom's opinion that goes toward not going in this > > > > direction for more commands, with the point to extend EXPLAIN to show > > > > this kind of information: > > > > > https://www.postgresql.org/message-id/1692530.

Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

On Mon, Jan 20, 2025 at 12:00 PM Peter Smith wrote: > > Hi Shubham, > > Patch v12-0001 LGTM. > > BTW, there is a precedent for passing the 'opt' arg but then only > using one member from it. See function wait_for_end_recovery in this > same file. So whether you decide to change the code per Shlok'

RE: Conflict detection for update_deleted in logical replication

Dear hackers, I've created a new script which simulates that user reduce the workload on the publisher side. Attached zip file contains a script, execution log and pgbench outputs. Experiments were done with v24 patch set. Abstract == In this test the conflict slot could be invalidated as e

Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

On Mon, Jan 20, 2025 at 1:34 AM Shlok Kyal wrote: > > On Fri, 17 Jan 2025 at 09:52, Shubham Khanna > wrote: > > > > On Fri, Jan 17, 2025 at 5:43 AM Peter Smith wrote: > > > > > > Hi Shubham, > > > > > > Some review comments for patch v11-0001. > > > > > > == > > > src/sgml/ref/pg_createsubsc

Re: Bug in detaching a partition with a foreign key.

On Sat, Jan 18, 2025 at 2:14 AM Sami Imseih wrote: > > This is a bug indeed. I tried your patch, but it ends up in a seg fault. > > [...] > If the relation on the parent and child constraint match, that > tells us we don't have inheritance. > So, I am thinking we should add another condition for c

Re: per backend I/O statistics

On Sat, Jan 18, 2025 at 05:53:31PM +0900, Michael Paquier wrote: > Hmm. Such special complexities in pgstat.c are annoying. There is > a stupid thing I am wondering here. For the WAL stats, why couldn't > we place some calls of pgstat_prep_backend_pending() in strategic > places like XLogBeginIn

Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

Hi Shubham, Patch v12-0001 LGTM. BTW, there is a precedent for passing the 'opt' arg but then only using one member from it. See function wait_for_end_recovery in this same file. So whether you decide to change the code per Shlok's review [1], or decide not to change it -- either way is OK for me

Re: [PoC] Federated Authn/z with OAUTHBEARER

On Tue, Jan 14, 2025 at 6:00 AM Jacob Champion < jacob.champ...@enterprisedb.com> wrote: > On Mon, Jan 13, 2025 at 3:21 PM Jacob Champion > wrote: > > Next email will discuss the architectural bug that Kashif found. > > Okay, here goes. A standard OAuth connection attempt looks like this > (oh, I

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

On Sun, Dec 8, 2024 at 4:31 AM Tomas Vondra wrote: > > Yes, it's true that if the connection breaks, the client may not notice > that until the next command. But why would we want to kill psql in that > case? How does that improve the user experience? > > Hi Tomas,sorry for the (very!) late reply

Re: connection establishment versus parallel workers

On Tue, Jan 14, 2025 at 9:42 AM Thomas Munro wrote: > On Tue, Jan 14, 2025 at 8:50 AM Nathan Bossart > wrote: > > I gave these a closer look, and I still feel that they are both > > straightforward and reasonable. IIUC the main open question is whether > > this might cause problems for other PM

Re: Pgoutput not capturing the generated columns

Hi Vignesh, Thanks for including my patch in your patch set, ensuring that it does not get left behind. 1. These docs are mostly still OK, but have become slightly stale because: a) they should mention "stored" in some places b) the examples now need to be using the new enum form of the publica

Re: int64 support in List API

20.01.2025 07:36, Tom Lane пишет: Gurjeet Singh writes: I wanted to use the list api from pg_list.h. It has special implementations for int, oid, pointer, and xid types, which help with lower code overhead (no need to create structures whose sole member is of one of these types) and better per

Re: int64 support in List API

Gurjeet Singh writes: > I wanted to use the list api from pg_list.h. It has special implementations > for > int, oid, pointer, and xid types, which help with lower code overhead (no need > to create structures whose sole member is of one of these types) and better > performance. So I was wonderi

Re: Pgoutput not capturing the generated columns

Hi Vignesh. Here are my review comments for patch v53-0003. On Sun, Jan 19, 2025 at 11:17 PM vignesh C wrote: > > On Fri, 17 Jan 2025 at 11:23, Peter Smith wrote: > > > > Hi Vignesh. > > > > Some review comments for patch v52-0003 > > > > == > > > > 1. GENERAL - change to use enum. > > > >

int64 support in List API

I was working on an extension [1] that needed to manage a list of query IDs. Query ID is internally of type uint64 (struct Query's member named queryId), but it is exposed to the SQL layer as signed int64 (e.g pg_stat_activity.query_id is of type bigint). I wanted to use the list api from pg_list.

Re: Skip collecting decoded changes of already-aborted transactions

On Fri, Jan 17, 2025 at 11:19 PM Masahiko Sawada wrote: > > On Wed, Jan 15, 2025 at 4:43 PM Peter Smith wrote: > > > > My thoughts are that any consistency improvement is a step in the > > right direction so even "don't increase the consistency much" is still > > better than nothing. > > I agree

Re: Pgoutput not capturing the generated columns

IIUC, patch v53-0004 is primarily a bug fix for a docs omission of the master implementation. So, 1. IMO think this patch in its current form must come *before* the 0003 patch where you changed the PUBLICATION option from bool to enum. 2. Then the patch (currently called) 0003 needs to update th

Re: improve DEBUG1 logging of parallel workers for CREATE INDEX?

> > > Hmm. I am reading Tom's opinion that goes toward not going in this > > > direction for more commands, with the point to extend EXPLAIN to show > > > this kind of information: > > > https://www.postgresql.org/message-id/1692530.1736369...@sss.pgh.pa.us > > > > That sounds like the ability to

Re: POC: track vacuum/analyze cumulative time per relation

On Fri, Jan 17, 2025 at 09:42:13AM -0600, Sami Imseih wrote: > Indeed. Corrected in v5 I can get behind the idea of the patch. + PgStat_Counter total_vacuum_time; + PgStat_Counter total_autovacuum_time; + PgStat_Counter total_analyze_time; + PgStat_Counter total_autoanalyz

Re: Infinite loop in XLogPageRead() on standby

On Thu, Jan 16, 2025 at 09:42:49AM +0900, Michael Paquier wrote: > I've applied the first refactoring bits down to v13 (see for example a > s/emit_message/emit_wal/ tweaked for consistency, with more comment > tweaks). Attached are patches for each branch for the bug fix, that > I'm still testing

Re: attndims, typndims still not enforced, but make the value within a sane threshold

On Sun, Jan 19, 2025 at 07:07:03PM -0500, Tom Lane wrote: > Michael Paquier writes: > > Small question on this one: would it be worth adding a check in > > sanity_check.sql for bumpy values? > > Yeah, I didn't bother with a regression test in this draft, but > we should likely have one. Or was y

Re: Pgoutput not capturing the generated columns

Hi Vignesh, Review comments for patch v53-0001: I don't doubt that the latest 0001 patch is working OK, but IMO it didn't need to be this complicated. I still think just using an alias for all the columns not present as I suggested yesterday [1] would be far simpler than the current patch. On S

Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

>> So you want to allow to use IGNORE NULLS to other built-in window >> functions? > > No, there needs to be a way for the individual window function to > throw error if that's specified for a function that can't handle it. > I'm just saying I don't want that to be hard-wired in some centralized >

Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

Tatsuo Ishii writes: >> I would think that >> IGNORE NULLS is potentially useful for user-defined window functions, >> and we should not be building anything that restricts the feature to >> specific functions. > So you want to allow to use IGNORE NULLS to other built-in window > functions? No,

RE: Replace current implementations in crypt() and gen_salt() to OpenSSL

Thank you for moving this discussion forward. > Maybe we could document that the test should fail if fips is enabled? > > FWIW I have not tested at all on a fips enabled machine. I will see about > doing > that... I tested all on a fips enabled machine and test failed. Since all tests have been

Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

> Tatsuo Ishii writes: >>> The latest version restricts it to lag, lead, first_value, last_value, >>> and nth_value. We can extend it in a subsequent patch if there's >>> demand? > >> The restriction is required by the SQL standard. So I don't think we >> need to extend to other window functions.

Re: 回复：Re: 回复：Re: speed up pg_upgrade with large number of tables

The restore side speedups suggested by Yang seem reasonable and can potentially speed up the process. We can even go a bit further by starting the new postgres in a --binary-upgrade mode and skip some of these locks completely. On Sun, Jan 19, 2025 at 3:43 PM Nathan Bossart wrote: > On Mon, Jul

Re: attndims, typndims still not enforced, but make the value within a sane threshold

Michael Paquier writes: > Small question on this one: would it be worth adding a check in > sanity_check.sql for bumpy values? Yeah, I didn't bother with a regression test in this draft, but we should likely have one. Or was your point something different? regards, tom l

Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

Tatsuo Ishii writes: >> The latest version restricts it to lag, lead, first_value, last_value, >> and nth_value. We can extend it in a subsequent patch if there's >> demand? > The restriction is required by the SQL standard. So I don't think we > need to extend to other window functions. The SQL

Re: attndims, typndims still not enforced, but make the value within a sane threshold

On Sun, Jan 19, 2025 at 06:47:14PM -0500, Tom Lane wrote: > I looked at getting a better result here and decided that it didn't > look very promising. pg_dump uses format_type() to build the type > name to put in CREATE TABLE, and that doesn't have access to attndims. Small question on this one:

Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

Thanks for updating the patch. >> It seems you allow to use IGNORE NULLS for all window functions. If >> the case, you should explicitely stat that in the docs. Otherwise >> users will be confused because; > > The latest version restricts it to lag, lead, first_value, last_value, > and nth_value.

Re: attndims, typndims still not enforced, but make the value within a sane threshold

Bruce Momjian writes: > Using the queries in that URL, I see: > CREATE TABLE test (data integer, data_array integer[5][5]); > CREATE TABLE test2 (LIKE test); > CREATE TABLE test3 AS SELECT * FROM test; > SELECT relname, attndims > FROM pg_class JOIN pg_attribute ON (

Re: stored short varlena in array

Quan Zongliang writes: > Now, the varlena type is stored directly in the array. Did not consider > short varlena. If it's like fill_val(), using short varlena saves memory > footprint and disk space. TBH, I think this is a bad idea and we should reject it. As you have already discovered, the c

Re: Issue with markers in isolation tester? Or not?

Hello, Noah! > Stepping back, any variation in the total ordering of step-start and > step-complete events necessarily changes the expected output. Hence, we want > to freeze that ordering. We could do that directly, by having isolationtester > read a format that lists start and complete even

Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

On Fri, 17 Jan 2025 at 09:52, Shubham Khanna wrote: > > On Fri, Jan 17, 2025 at 5:43 AM Peter Smith wrote: > > > > Hi Shubham, > > > > Some review comments for patch v11-0001. > > > > == > > src/sgml/ref/pg_createsubscriber.sgml > > > > 1. > > -must accept local connections. > > +must

Re: Issue with markers in isolation tester? Or not?

On Sun, Jan 19, 2025 at 07:26:58PM +0100, Michail Nikolaev wrote: > Mostly idea is next: > > Let's imagine we have two steps - step_before and step_after which may end > in either order. > Then instead of such step/markers structure: > > step_before(step_after) > stepN > s

Re: Old BufferDesc refcount in PrintBufferDescs and PrintPinnedBufs

Andres Freund writes: > On 2025-01-19 09:37:54 +0900, Michael Paquier wrote: >> Removal sounds good to me. Any objections from anybody? >> Andres, perhaps you have some experience using that and would prefer >> keep them and make them work? > I think they're pretty useless, tbh. There's too many

Re: Issue with markers in isolation tester? Or not?

Hello, Michael! > Could you summarize here what you have done to achieve test > stabilization in your new patch set posted at [1] without using the > proposal of this thread? Mostly idea is next: Let's imagine we have two steps - step_before and step_after which may end in either order. Then i

Re: Old BufferDesc refcount in PrintBufferDescs and PrintPinnedBufs

Hi, On 2025-01-19 09:37:54 +0900, Michael Paquier wrote: > On Fri, Jan 17, 2025 at 11:14:02PM -0800, Jacob Brazeal wrote: > > Sounds good! v3 attached. > > Removal sounds good to me. Any objections from anybody? > > Andres, perhaps you have some experience using that and would prefer > keep the

Re: New feature request for adding session information to PostgreSQL transaction log

Sumanth Vishwaraj writes: > We would like PostgreSQL to store the details of who made the change > (user/session) information in the transaction log. You can build that yourself, typically by adding a trigger that stores the value of "current_user" into inserted/updated rows. (If you want to al

Re: [RFC] Lock-free XLog Reservation from WAL

17.01.2025 17:00, Zhou, Zhiguo пишет: On 1/16/2025 10:00 PM, Yura Sokolov wrote: Good day, Zhiguo. Excuse me, I feel sneaky a bit, but I've started another thread just about increase of NUM_XLOGINSERT_LOCK, because I can measure its effect even on my working notebook (it is another one: Ry

Re: Additional comments around need_escapes in pg_parse_json()

On 2024-12-23 Mo 2:15 AM, Corey Huinker wrote: Comments are not quite accurate, but I'll look at cleaning them up and adding them. Much appreciated. Also, I don't think we need all of the comments, but I figured it was easier for me to comment at every possible good place, and

Re: SQL Property Graph Queries (SQL/PGQ)

Hi Ashutosh, On Wed, Jan 1, 2025 at 5:02 PM Ashutosh Bapat wrote: > > On Wed, Jan 1, 2025 at 2:22 PM Ashutosh Bapat > wrote: > > > > On Sat, Dec 21, 2024 at 6:21 PM Junwang Zhao wrote: > > Thanks Junwang for your review. > > > > > Here are some review opinions for 0001, I haven't seen the other

Re: Eager aggregation, take 3

On Sat, Jan 18, 2025 at 6:16 AM Robert Haas wrote: > On Thu, Jan 16, 2025 at 3:18 AM Richard Guo wrote: > > If this t1/t2 join is part of a larger SELECT query, I think the cost > > estimates for the upper join nodes would likely be quite inaccurate. > > That's definitely true. However, the quest

Re: New feature request for adding session information to PostgreSQL transaction log

Hi Scott, As per the PostgreSQL bug reporting page (https://www.postgresql.org/docs/current/bug-reporting.html) , we have to send email to pgsql-hackers@lists.postgresql.org for creating enhancement request. Hence I have sent email to pgsql-hackers@l

New feature request for adding session information to PostgreSQL transaction log

Hi PostgreSQL team, Oracle Audit Vault and Database Firewall (AVDF) audits/monitors database activities. This product helps enterprises to manage the security posture of Oracle , PostgreSQL and other databases. Oracle AVDF helps customers in India comply with the Ministry of Corporate Affairs

Re: Pgoutput not capturing the generated columns

On Sun, 19 Jan 2025 at 06:39, Peter Smith wrote: > > Hi Vignesh, > > I was having some second thoughts about this patch and my previous suggestion. > > Currently the code is current written something like: > > printfPQExpBuffer(&buf, > "SELECT oid, pubname,\n" > " pg_catalog.pg_get_userbyid(pub

Re: improve DEBUG1 logging of parallel workers for CREATE INDEX?

Hi, Le dim. 19 janv. 2025 à 06:40, Sami Imseih a écrit : > > Hmm. I am reading Tom's opinion that goes toward not going in this > > direction for more commands, with the point to extend EXPLAIN to show > > this kind of information: > > https://www.postgresql.org/message-id/1692530.1736369...@ss

Re: Add XMLNamespaces to XMLElement

On 16.01.25 08:36, Pavel Stehule wrote: > Now, I have not any objections against the code > > The patch has doc and enough regress tests > The patching and compilation without problems > make check-world passed > > I'll mark this patch as ready for committer rebase due to gram.y changes introduc

Re：Limit length of queryies in pg_stat_statement extension

Hi, Thanks for your answer. > I don't think that it would move the needle much. Deallocating entries is > very > expensive, even when the query text file isn't being cleaned up, as it needs > to > sort all entries by usage to remove the least recently used all with an > exclusive pgss->lock.