Fix calloc check if oom (PQcancelCreate)

Hi. I think that commit 61461a3 , left some oversight. The function *PQcancelCreate* fails in check, return of *calloc* function. Trivial fix is attached. But, IMO, I think that has more problems. If any alloca

Re: POC: GROUP BY optimization

Hi! On Tue, Apr 23, 2024 at 1:19 AM Alexander Korotkov wrote: > On Thu, Apr 18, 2024 at 1:57 PM Alexander Korotkov > wrote: > > Thank you for the fixes you've proposed. I didn't look much into > > details yet, but I think the main concern Tom expressed in [1] is > > whether the feature is reas

Re: relfilenode statistics

Hi Bertrand, It would be helpful to me if the reasons why we're splitting out relfilenodestats could be more clearly spelled out. I see Andres's comment in the thread to which you linked, but it's pretty vague about why we should do this ("it's not nice") and whether we should do this ("I wonder i

Re: Fix calloc check if oom (PQcancelCreate)

> On 27 May 2024, at 14:25, Ranier Vilela wrote: > I think that commit 61461a3, left some oversight. > The function *PQcancelCreate* fails in check, > return of *calloc* function. > > Trivial fix is attached. Agreed, this looks like a copy/paste from the calloc calls a few lines up. > But, IMO

Re: Fix calloc check if oom (PQcancelCreate)

Hi Daniel, Em seg., 27 de mai. de 2024 às 10:23, Daniel Gustafsson escreveu: > > On 27 May 2024, at 14:25, Ranier Vilela wrote: > > > I think that commit 61461a3, left some oversight. > > The function *PQcancelCreate* fails in check, > > return of *calloc* function. > > > > Trivial fix is attac

Fix use of possible uninitialized variable retval (src/pl/plpgsql/src/pl_handler.c)

Hi. The function *plpgsql_inline_handler* can use uninitialized variable retval, if PG_TRY fails. Fix like function*plpgsql_call_handler* wich declare retval as volatile and initialize to (Datum 0). best regards, Ranier Vilela fix-use-uninitialized-retval-variable-pl_handler.patch Description:

Fix possible dereference null pointer (PQprint)

Hi. In the function *PQprint*, the variable po->fieldName can be NULL. See the checks a few lines up. for (numFieldName = 0; po->fieldName && po->fieldName[numFieldName]; numFieldName++) So, I think that must be checked, when used, in the loop below. best regards, Ranier Vilela fix-possible-d

Test 031_recovery_conflict fails when a conflict counted twice

Hello hackers, As a recent buildfarm test failure on olingo (which builds postgres with -O1 and address sanitizer) [1] shows: ... [23:12:02.127](0.166s) not ok 6 - snapshot conflict: stats show conflict on standby [23:12:02.130](0.003s) #   Failed test 'snapshot conflict: stats show conflict on

Re: Fix calloc check if oom (PQcancelCreate)

On Mon, 27 May 2024 at 16:06, Ranier Vilela wrote: > Em seg., 27 de mai. de 2024 às 10:23, Daniel Gustafsson > escreveu: >> > On 27 May 2024, at 14:25, Ranier Vilela wrote: >> > I think that commit 61461a3, left some oversight. >> > The function *PQcancelCreate* fails in check, >> > return of *

Re: Fix calloc check if oom (PQcancelCreate)

Em seg., 27 de mai. de 2024 às 12:40, Jelte Fennema-Nio escreveu: > On Mon, 27 May 2024 at 16:06, Ranier Vilela wrote: > > Em seg., 27 de mai. de 2024 às 10:23, Daniel Gustafsson > escreveu: > >> > On 27 May 2024, at 14:25, Ranier Vilela wrote: > >> > I think that commit 61461a3, left some ove

Re: Fix calloc check if oom (PQcancelCreate)

On Mon, 27 May 2024 at 18:16, Ranier Vilela wrote: > Is it mandatory to call PQcancelFinish in case PQcancelCreate fails? Yes, see the following line in the docs: Note that when PQcancelCreate returns a non-null pointer, you must call PQcancelFinish when you are finished with it, in order to di

Re: Fix calloc check if oom (PQcancelCreate)

Em seg., 27 de mai. de 2024 às 13:47, Jelte Fennema-Nio escreveu: > On Mon, 27 May 2024 at 18:16, Ranier Vilela wrote: > > Is it mandatory to call PQcancelFinish in case PQcancelCreate fails? > > > Yes, see the following line in the docs: > > Note that when PQcancelCreate returns a non-null poin

Re: Fix calloc check if oom (PQcancelCreate)

> On 27 May 2024, at 18:47, Jelte Fennema-Nio wrote: > So overall I agree pqReleaseConnHost and release_conn_addrinfo can be > improved for easier safe usage in the future, but I don't think those > improvements should be grouped into the same commit with an actual > bugfix. I have pushed the fi

Re: Fix calloc check if oom (PQcancelCreate)

Em seg., 27 de mai. de 2024 às 14:42, Daniel Gustafsson escreveu: > > On 27 May 2024, at 18:47, Jelte Fennema-Nio wrote: > > > So overall I agree pqReleaseConnHost and release_conn_addrinfo can be > > improved for easier safe usage in the future, but I don't think those > > improvements should b

Re: Comments on Custom RMGRs

On Fri, May 17, 2024 at 04:25:15PM -0400, Robert Haas wrote: > On Fri, May 17, 2024 at 4:20 PM Jeff Davis wrote: >> Regarding this particular change: the checkpointing hook seems more >> like a table AM feature, so I agree with you that we should have a good >> idea how a real table AM might use t

Re: Avoid possible dereference null pointer (src/backend/catalog/pg_depend.c)

Thanks a lot Michael. On Sun, May 26, 2024 at 4:40 PM Michael Paquier wrote: > On Fri, May 24, 2024 at 09:05:35AM -0300, Ranier Vilela wrote: > > The function *get_attname* palloc the result name (pstrdup). > > Isn't it necessary to free the memory here (pfree)? > > This is going to be freed wit

Re: apply_scanjoin_target_to_paths and partitionwise join

On Fri, May 24, 2024 at 11:02 AM wrote: > Hi Ashutosh, > > thanks for bringing this to my attention. I'll first share a few > thoughts about the change and respond regarding the test below. > > I clearly understand your intention with this patch. It's an issue I run > into from time to time. > >

Re: Comments on Custom RMGRs

On Fri May 17, 2024 at 3:20 PM CDT, Jeff Davis wrote: ... Obviously it would be better to have a nice example table AM in /contrib, different enough from heap, but nobody has done that yet. You could argue that we never should have exposed the API without something like this in the first place,

Re: CREATE INDEX CONCURRENTLY on partitioned index

On 24.05.2024 10:04, Alexander Pyhalov wrote: Ilya Gladyshev писал(а) 2024-05-24 00:14: Hi, Hi. I think it's well worth the effort to revive the patch, so I rebased it on master, updated it and will return it back to the commitfest. Alexander, Justin feel free to add yourselves as author

Re: remaining sql/json patches

On Mon, May 20, 2024 at 7:51 PM Amit Langote wrote: > > Hi Thom, >> > > and I think we need to either remove the leading "select" keyword, or > > uppercase it in the examples. > > > > For example (on > > https://www.postgresql.org/docs/devel/functions-json.html#SQLJSON-QUERY-FUNCTIONS): > > > >

Re: Show WAL write and fsync stats in pg_stat_io

On Mon, May 13, 2024 at 7:42 PM Bharath Rupireddy wrote: > > On Fri, Apr 19, 2024 at 1:32 PM Nazir Bilal Yavuz wrote: > > > > > I wanted to inform you that the 73f0a13266 commit changed all WALRead > > > calls to read variable bytes, only the WAL receiver was reading > > > variable bytes before.

Re: apply_scanjoin_target_to_paths and partitionwise join

Hi Ashutosh! On 2024-05-27 14:17, Ashutosh Bapat wrote: On Fri, May 24, 2024 at 11:02 AM wrote: Hi Ashutosh, thanks for bringing this to my attention. I'll first share a few thoughts about the change and respond regarding the test below. I clearly understand your intention with this patch.

Re: pgsql: Add more SQL/JSON constructor functions

On 2024-May-27, Alvaro Herrera wrote: > > JSON_SERIALIZE() I just noticed this behavior, which looks like a bug to me: select json_serialize('{"a":1, "a":2}' returning varchar(5)); json_serialize {"a": I think this function should throw an error if the destination type doesn

Re: First draft of PG 17 release notes

On Sun, 26 May 2024 at 15:57, Bruce Momjian wrote: > Agreed. I changed it to: > > Allow btree indexes to more efficiently find a set of values, such as > those supplied by IN subqueries > > Is that good? I think this needs further adjustment. An "IN subquery" is an IN clause whi

Re: First draft of PG 17 release notes

On Tue, May 28, 2024 at 02:44:28PM +1200, David Rowley wrote: > On Sun, 26 May 2024 at 15:57, Bruce Momjian wrote: > > Agreed. I changed it to: > > > > Allow btree indexes to more efficiently find a set of values, such > > as > > those supplied by IN subqueries > > > > Is that go

Need clarification on compilation errors in PG 16.2

Hi , While we try to install PG 16.2 from the source code in macbook we getting this following errors ``` *explicit_bzero.c:22:9: error: call to undeclared function 'memset_s'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration](void)

Re: Partial aggregates pushdown

fujii.y...@df.mitsubishielectric.co.jp писал(а) 2024-05-28 00:30: Hi Mr. Pyhalov. Hi. Found one more problem. You can fire partial aggregate over partitioned table, but convert_combining_aggrefs() will make non-partial copy, which leads to 'variable not found in subplan target list' error.

Re: Partial aggregates pushdown

fujii.y...@df.mitsubishielectric.co.jp писал(а) 2024-05-28 00:30: Hi Mr. Pyhalov. Sorry for the late reply. Thank you for your modification and detailed review. I attach a fixed patch, have been not yet rebased. Monday, 25 March 2024 16:01 Alexander Pyhalov :. Comment in nodeAgg.c seems to be

Re: CREATE INDEX CONCURRENTLY on partitioned index

Ilya Gladyshev писал(а) 2024-05-28 02:52: Also I'd like to note that in new patch version there's a strange wording in documentation: "This can be very convenient as not only will all existing partitions be  indexed, but any future partitions will be as well.  CREATE INDEX ... CONCURRENTLY c

Re: GUC names in messages

On Fri, May 17, 2024 at 9:57 PM Peter Eisentraut wrote: > > On 17.05.24 05:31, Peter Smith wrote: > >> I think we should accept your two patches > >> > >> v6-0001-GUC-names-docs.patch > >> v6-0002-GUC-names-add-quotes.patch > >> > >> which effectively everyone was in favor of and which seem to be

Re: Need clarification on compilation errors in PG 16.2

> On 28 May 2024, at 07:37, Pradeep Kumar wrote: This requires more information to be shared in order to figure out what could be happening. > ``` > explicit_bzero.c:22:9: error: call to undeclared function 'memset_s'; ISO C99 > and later do not support implicit function declarations > [-Wimp

Re: Need clarification on compilation errors in PG 16.2

Hi, >This codepath would only be reached if the buildsystem determined that memset_s >was available so something is fairly wrong here. Did you change any builfiles >after running configure? Re-install or upgrade XCode after running configure? I didn't touch any of the buildfiles , even didn't t