Re: Adding OLD/NEW support to RETURNING

hi. took me a while to understand how the returning clause Var nodes correctly reference the relations RT index. mainly in set_plan_references, set_plan_refs and set_returning_clause_references. do you think we need do something in set_returning_clause_references->build_tlist_index_other_vars to

Re: Remove support for old realpath() API

On Mon, Aug 12, 2024 at 6:18 PM Peter Eisentraut wrote: > On 05.08.24 09:41, Heikki Linnakangas wrote: > > On 05/08/2024 09:12, Peter Eisentraut wrote: > >> The now preferred way to call realpath() is by passing NULL as the > >> second argument and get a malloc'ed result. We still supported the >

Re: [PoC] Federated Authn/z with OAUTHBEARER

On 07.08.24 09:34, Peter Eisentraut wrote: On 05.08.24 19:53, Jacob Champion wrote: On Fri, Aug 2, 2024 at 11:48 AM Peter Eisentraut wrote: Yes, I think with an adjusted comment and commit message, the actual change makes sense. Done in v25. ...along with a bunch of other stuff: I have co

Re: Remove support for old realpath() API

On 05.08.24 09:41, Heikki Linnakangas wrote: On 05/08/2024 09:12, Peter Eisentraut wrote: The now preferred way to call realpath() is by passing NULL as the second argument and get a malloc'ed result.  We still supported the old way of providing our own buffer as a second argument, for some plat

Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state

Hi, On Sat, Aug 10, 2024 at 06:07:30PM +0800, cca5507 wrote: > Hi, > > > Thanks for the comments! > > > Here are the new version patches, I think it will be more clear. Thanks! 1 === When applying I get: Applying: Track transactions committed in BUILDING_SNAPSHOT. .git/rebase-apply/patch:7

Re: ECPG cleanup and fix for clang compile-time problem

On Fri, Apr 19, 2024 at 10:21 PM Tom Lane wrote: > > One other bit of randomness that I noticed: ecpg's parse.pl has > this undocumented bit of logic: > > if ($a eq 'IDENT' && $prior eq '%nonassoc') > { > > # add more tokens to the list >

Re: Restart pg_usleep when interrupted

Hi, On Sat, Aug 10, 2024 at 08:27:56AM -0500, Sami Imseih wrote: > > > v9 has some has some minor corrections to the comments. > Thanks! 1 === + * Unlike pg_usleep, This function continues s/This/this/? Apart from the above, LGTM. Regards, -- Bertrand Drouvot PostgreSQL Contributors Te

Re: Logical Replication of sequences

Hi Vignesh, I found that when 2 subscriptions are both subscribing to a publication publishing sequences, an ERROR occurs on refresh. == Publisher: -- test_pub=# create publication pub1 for all sequences; Subscriber: --- test_sub=# create subscription sub1 connection 'dbna

Re: Remaining dependency on setlocale()

On Mon, Aug 12, 2024 at 3:24 PM Thomas Munro wrote: > 1. The nl_langinfo() call in pg_get_encoding_from_locale(), can > probably be changed to nl_langinfo_l() (it is everywhere we currently > care about except Windows, which has a different already-thread-safe > alternative ... ... though if we

Re: Logical Replication of sequences

Hi Vignesh, I noticed it is not currently possible (there is no syntax way to do it) to ALTER an existing publication so that it will publish SEQUENCES. Isn't that a limitation? Why? For example,. Why should users be prevented from changing a FOR ALL TABLES publication into a FOR ALL TABLES, SEQ

Re: Doc limitation update proposal: include out-of-line OID usage per TOAST-ed columns

On Mon, May 20, 2024 at 5:43 PM Jakub Wartak wrote: > > On Tue, May 14, 2024 at 8:19 PM Robert Haas wrote: > > > > I looked at your version and wrote something that is shorter and > > doesn't touch any existing text. Here it is. > > Hi Robert, you are a real tactician here - thanks for whatever >

Re: Conflict detection and logging in logical replication

On Fri, Aug 9, 2024 at 12:29 PM Zhijie Hou (Fujitsu) wrote: > > Here is the V12 patch that improved the log format as discussed. > * diff --git a/src/test/subscription/out b/src/test/subscription/out new file mode 100644 index 00..2b68e9264a --- /dev/null +++ b/src/test/subscription/out @

Re: A problem about partitionwise join

On Mon, Mar 25, 2024 at 7:09 PM Ashutosh Bapat wrote: > I think we need some way to avoid two different ways of looking up partition > keys - if we can't teach the EC machinery to produce clauses with partition > keys (always), we need to teach EC to contain partition keys in case of outer > jo

Re: Do we still need parent column in pg_backend_memory_context?

On Tue, 6 Aug 2024 at 17:48, David Rowley wrote: > Does anyone object to making this happen? i.e. remove > pg_backend_memory_contexts.parent column and see if anyone complains? > > If nobody comes up with any reasons against it, then I propose making > this happen. I made a few adjustments and pu

RE: Conflict detection and logging in logical replication

On Friday, August 9, 2024 7:45 PM Michail Nikolaev wrote: > There are some comments on this patch related to issue [0]. In short: any > DirtySnapshot index scan may fail to find an existing tuple in the case of a > concurrent update. > > - FindConflictTuple may return false negative result in t

RE: [BUG?] check_exclusion_or_unique_constraint false negative

Hi, Thanks for reporting the issue ! I tried to reproduce this in logical replication but failed. If possible, could you please share some steps to reproduce it in logicalrep context ? In my test, if the tuple is updated and new tuple is in the same page, heapam_index_fetch_tuple should find the

Re: Remaining dependency on setlocale()

On Thu, Aug 8, 2024 at 5:16 AM Jeff Davis wrote: > On Wed, 2024-08-07 at 19:07 +1200, Thomas Munro wrote: > > How far can we get by using more _l() functions? > > There are a ton of calls to, for example, isspace(), used mostly for > parsing. > > I wouldn't expect a lot of differences in behavior

Re: Logical Replication of sequences

Hi Vignesh, v20240809-0001. No comments. v20240809-0002. See below. v20240809-0003. See below. v20240809-0004. No comments. // Here are my review comments for patch v20240809-0002. nit - Tweak wording in new docs example, because a publication only publishes the sequences; it doesn't "s

Re: A problem about partitionwise join

On Sat, Aug 10, 2024 at 6:22 AM Alexey Dvoichenkov wrote: > I haven't read the entire thread so I might be missing something, but > one interesting consequence of this patch is that it kind of breaks > the initial pruning of generic plans. Given a query such as SELECT > ... WHERE A.PK = B.PK AND A

Re: Recent 027_streaming_regress.pl hangs

Andrew Dunstan writes: > We'll see. I have switched crake from --run-parallel mode to --run-all > mode i.e. the runs are serialized. Maybe that will be enough to stop the > errors. I'm still annoyed that this test is susceptible to load, if that > is indeed what is the issue. crake is still ti

Re: Fix memory counter update in reorderbuffer

On Sat, Aug 10, 2024 at 5:48 AM Masahiko Sawada wrote: > > On Fri, Aug 9, 2024 at 3:30 PM Amit Kapila wrote: > > > > On Thu, Aug 8, 2024 at 9:43 PM Masahiko Sawada > > wrote: > > > > > > On Wed, Aug 7, 2024 at 3:17 PM Amit Kapila > > > wrote: > > > > > > > > On Wed, Aug 7, 2024 at 7:42 AM Mas

Re: Returning from a rule with extended query protocol

Greg Rychlewski writes: > I was testing creating a rule that uses RETURNING and noticed a difference > between the extended query protocol and the simple query protocol. In the > former, RETURNING is ignored (at least in my case) and the latter it is > respected: I think this might be the same is

Re: Returning from a rule with extended query protocol

On Sun, 11 Aug 2024 at 13:29, Greg Rychlewski wrote: > I was testing creating a rule that uses RETURNING and noticed a difference > between the extended query protocol and the simple query protocol. In the > former, RETURNING is ignored (at least in my case) and the latter it is > respected: T

Re: Optimize mul_var() for var1ndigits >= 8

On Tue, Aug 6, 2024, at 13:52, Dean Rasheed wrote: > On Mon, 5 Aug 2024 at 13:34, Joel Jacobson wrote: >> >> Noted from 5e1f3b9eb: >> "While it adds some space on 32-bit machines, we aren't optimizing for that >> case anymore." >> >> In this case, the extra 32-bit numeric_mul code seems to be 89

Re: Avoiding superfluous buffer locking during nbtree backwards scans

On Tue, Aug 6, 2024 at 6:31 PM Matthias van de Meent wrote: > +1, LGTM. > > This changes the backward scan code in _bt_readpage to have an > approximately equivalent handling as the forward scan case for > end-of-scan cases, which is an improvement IMO. Pushed just now. Thanks for the review! --

Re: pg_stat_statements and "IN" conditions

> On Sun, Aug 11, 2024 at 07:54:05PM +0300, Sergei Kornilov wrote: > > This feature will improve my monitoring. Even in patch 0001. I think there > are many other people in the thread who think this is useful. So maybe we > should move it forward? Any complaints about the overall design? I see in

Re: pg_stat_statements and "IN" conditions

Hello This feature will improve my monitoring. Even in patch 0001. I think there are many other people in the thread who think this is useful. So maybe we should move it forward? Any complaints about the overall design? I see in the discussion it was mentioned that it would be good to measure p

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

Jeff Davis writes: > We can address those as part of a separate thread. I'll count this as > committed. Coverity has a nit about this: *** CID 1616189: Null pointer dereferences (REVERSE_INULL) /srv/coverity/git/pgsql-git/postgresql/src/backend/utils/adt/like.c: 206 in Generic_Text_IC_like()

Re: Restricting Direct Access to a C Function in PostgreSQL

Heikki Linnakangas writes: > Sounds complicated. I would go with the GRANT approach. Make my_func() a > SECURITY DEFINER function, and revoke access to my_func_extended() for > all other roles. +1 > Another option to consider is to not expose my_func_extended() at the > SQL level in the first

Re: Restricting Direct Access to a C Function in PostgreSQL

Understood, Thanks for the help. Regards Ayush >

Re: Restricting Direct Access to a C Function in PostgreSQL

ne 11. 8. 2024 v 15:34 odesílatel Ayush Vatsa napsal: > Thanks for the responses. > > > I would go with the GRANT approach. Make my_func() a > SECURITY DEFINER function, and revoke access to my_func_extended() for > all other roles. > This sounds reasonable, and can be one of the options. > > > D

Re: Restricting Direct Access to a C Function in PostgreSQL

Thanks for the responses. > I would go with the GRANT approach. Make my_func() a SECURITY DEFINER function, and revoke access to my_func_extended() for all other roles. This sounds reasonable, and can be one of the options. > Dunno how complicated the logic in my_func() is, if that makes sense. A

Re: PG_TEST_EXTRA and meson

On 2024-08-09 Fr 5:26 AM, Ashutosh Bapat wrote: I this the patch lacks overriding PG_TEST_EXTRA at run time. AFAIU, following was expected behaviour from both meson and make. Please correct if I am wrong. 1. If PG_TEST_EXTRA is set at the setup/configuration time, it is not required to be set a

Re: Restricting Direct Access to a C Function in PostgreSQL

ne 11. 8. 2024 v 14:08 odesílatel Heikki Linnakangas napsal: > On 11/08/2024 12:41, Pavel Stehule wrote: > > ne 11. 8. 2024 v 9:23 odesílatel Ayush Vatsa > > napsal: > > > > Hi PostgreSQL Community, > > > > I have a scenario where I am working with two fu

Re: Restricting Direct Access to a C Function in PostgreSQL

On 11/08/2024 12:41, Pavel Stehule wrote: ne 11. 8. 2024 v 9:23 odesílatel Ayush Vatsa > napsal: Hi PostgreSQL Community, I have a scenario where I am working with two functions: one in SQL and another in C, where the SQL function is a wrapper around

Returning from a rule with extended query protocol

Hi, I was testing creating a rule that uses RETURNING and noticed a difference between the extended query protocol and the simple query protocol. In the former, RETURNING is ignored (at least in my case) and the latter it is respected: CREATE table test (id bigint, deleted boolean); CREATE RULE

Re: Restricting Direct Access to a C Function in PostgreSQL

Hi ne 11. 8. 2024 v 9:23 odesílatel Ayush Vatsa napsal: > Hi PostgreSQL Community, > > I have a scenario where I am working with two functions: one in SQL and > another in C, where the SQL function is a wrapper around C function. Here’s > an example: > > CREATE OR REPLACE FUNCTION my_func(IN inp

Restricting Direct Access to a C Function in PostgreSQL

Hi PostgreSQL Community, I have a scenario where I am working with two functions: one in SQL and another in C, where the SQL function is a wrapper around C function. Here’s an example: CREATE OR REPLACE FUNCTION my_func(IN input text)RETURNS BIGINT AS $$DECLARE result BIGINT;BEGIN SELECT

Re: Support tid range scan in parallel?

Hi Cary, On Wed, May 15, 2024 at 5:33 AM Cary Huang wrote: > > > You should add a test that creates a table with a very low fillfactor, > > low enough so only 1 tuple can fit on each page and insert a few dozen > > tuples. The test would do SELECT COUNT(*) to ensure you find the > > correct subse