Hi Gurjeet,
Thanks for looking into my patch.
> On Fri, Jan 3, 2025 at 8:54 PM Tatsuo Ishii wrote:
>>
>> Attached is the patch for this.
>
> Hi Tatsuo,
>
> I believe the newline endings in your patches are causing the patch
> application
> to fail. I experienced this with your initial patch,
diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h
index 9c2957eb546..624858db301 100644
--- a/src/include/nodes/primnodes.h
+++ b/src/include/nodes/primnodes.h
@@ -361,6 +361,9 @@ typedef struct Const
* of the `paramid' field contain the SubLink's subLinkId, and
* the l
On Fri, Jan 3, 2025 at 8:54 PM Tatsuo Ishii wrote:
>
> Attached is the patch for this.
Hi Tatsuo,
I believe the newline endings in your patches are causing the patch application
to fail. I experienced this with your initial patch, as well as with the latest
patch. Converting it to unix-style lin
> If you have trouble convincing people we need this for some new
> reason, then maybe you could review the existing callers to see if
> some of the existing call sites make it any more convincing.
>
> A very quick review, I found:
>
> send_message_to_frontend() initStringInfo(&buf) 1024 is proba
Hi.
Per Coverity.
All call sites of function *get_cheapest_path_for_pathkeys* checks
for NULL returns.
So, it is highly likely that the function will return NULL.
IMO, the Assert in this particular call, is not fully effective.
Fix removing the Assert and always check if the return is NULL.
b
Hi, thank you for your attention to this patch.
On 02.01.2025 23:12, Sami Imseih wrote:
Hi,
Thanks for the work you have done here. Exposing cumulative
metrics at this level of detail for vacuum is surely useful to find
vacuum bottlenecks and to determine the effectiveness of
vacuum tuning.
Yes
On Sat, Jan 4, 2025 at 11:35 AM Tom Lane wrote:
> Michel Pelletier writes:
> > I've circled back on this task to do some work improving the skeleton
> code,
> > but going back through our thread I landed on this point Tom made about
> > usefulness vs pure skeleton and my natural desire is to mak
I happened to notice that there's more that we can do to harden
contrib modules: the transform modules for hstore and ltree
currently have disclaimers about having to install them in the
same schema as the underlying modules. AFAICS that can be
fixed trivially now, by using the @extschema:name@ me
Michel Pelletier writes:
> I've circled back on this task to do some work improving the skeleton code,
> but going back through our thread I landed on this point Tom made about
> usefulness vs pure skeleton and my natural desire is to make a simple
> expanded object that is also useful, so I brain
> On 4 Jan 2025, at 10:24, John Naylor wrote:
>
> v6-0001:
>
> +static int
> +unique_cmp(const void *a, const void *b)
> +{
> + int32 aval = *((const int32 *) a);
> + int32 bval = *((const int32 *) b);
> +
> + return pg_cmp_s32(aval, bval);
> +}
>
> I'm not sure it makes sense to create a who
On Tue, Nov 19, 2024 at 11:45 AM Tom Lane wrote:
> Pavel Stehule writes:
> > út 19. 11. 2024 v 18:51 odesílatel Michel Pelletier <
> > pelletier.mic...@gmail.com> napsal:
> >> A couple years ago I tried to compress what I learned about expanded
> >> objects into a dummy extension that just provi
On Sat, Jan 4, 2025 at 5:48 AM David Steele wrote:
> We had one issue reported [1] involving Alpine Linux and CIFS and
Not directly relevant for pgbackrest probably, but I noticed that
Alpine comes up in a few reports of failing rm -r on CIFS. I think it
might be because BSD and GNU rm use fts t
I wrote:
> I wouldn't have any problem with saying that we don't support NFS
> implementations that don't have stable cookies. But so far I haven't
> found any supported platform except FreeBSD that fails the rmtree test
> against my Synology NAS.
To expand on that: I've now found that Linux, mac
13 matches
Mail list logo
