c77d1810ac6f13e9b58da5cd3ded5e47d44d03af Mon Sep 17 00:00:00 2001
From: Xing Guo
Date: Sat, 25 May 2024 23:36:29 +0800
Subject: [PATCH v1] Fix an incorrect assertion in mdwritev().
In commit 4908c58[^1], we added smgrwritev() which is a vectored variant
of smgrwrite(). Since mdwritev() is to be used
noticed that there's an unnecessary call to
"BackgroundWorkerInitializeConnection" in worker_spi.c (The worker_spi
launcher has set the dboid correctly).
Best Regards,
Xing.
From 4dbe54ef746203740202e181f731b7e08bb6e4ea Mon Sep 17 00:00:00 2001
From: Xing Guo
Date: Fri, 10 May 2024 10:3
Sorry, forget to add an assertion to guard our codes in my previous patch.
From 4f2d70fb27e3ff23b8572c5e679c791daa1f6665 Mon Sep 17 00:00:00 2001
From: Xing Guo
Date: Thu, 9 May 2024 20:57:48 +0800
Subject: [PATCH v3] Remove redundant SetProcessingMode(InitProcessing) calls.
After several
On Thu, May 9, 2024 at 10:13 PM Heikki Linnakangas wrote:
>
> On 09/05/2024 16:12, Xing Guo wrote:
> > Hi hackers,
> >
> > After several refactoring iterations, auxiliary processes are no
> > longer initialized from the bootstrapper. I think using the
> >
:00 2001
From: Xing Guo
Date: Thu, 9 May 2024 20:57:48 +0800
Subject: [PATCH v1] Set appropriate processing mode for auxiliary processes.
After several refactoring iterations, auxiliary processes are no longer
initialized from the bootstrapper. Using the InitProcessing mode for
initializing
On Sat, Apr 20, 2024 at 5:03 PM Michael Paquier wrote:
>
> On Sat, Apr 20, 2024 at 11:54:29AM +0900, Michael Paquier wrote:
> > Will clean up.
>
> While looking at the whole, I've noticed that this has been mentioned
> here by Andres, but the committed patch did not get the call:
>
ab13ca575e92f26a4b936c0d4fa92df23865c2d4 Mon Sep 17 00:00:00 2001
From: Xing Guo
Date: Sat, 20 Apr 2024 10:00:23 +0800
Subject: [PATCH v1] Remove deprecated header file.
The resowner_private.h is deprecated after b8bff07.
---
src/include/utils/resowner_private.h | 117 ---
1 file changed, 117 deletions
Hi hackers,
I'm playing a toy static analysis checker with PostgreSQL and found a
variable is missing volatile qualifier.
Best Regards,
Xing
From 7084055da64d0433b09e50faff630e551c363f27 Mon Sep 17 00:00:00 2001
From: Xing Guo
Date: Mon, 1 Apr 2024 21:39:04 +0800
Subject: [PATCH v1] Add missing
> On Wed, Mar 13, 2024 at 2:45 PM Peter Eisentraut wrote:
>
> On 12.03.24 14:38, Xing Guo wrote:
> > When the PostgreSQL server is configured with --with-llvm, the pgxs.mk
> > framework will generate LLVM bitcode for extensions automatically.
> > Sometimes, I don
> On Tue, Mar 12, 2024 at 10:40 PM Daniel Gustafsson wrote:
>
> > On 12 Mar 2024, at 14:38, Xing Guo wrote:
>
> > Would it be possible to add a new switch in the pgxs.mk framework to
> > allow users to disable this feature?
>
> Something like that doesn't seem
Hi hackers,
When the PostgreSQL server is configured with --with-llvm, the pgxs.mk
framework will generate LLVM bitcode for extensions automatically.
Sometimes, I don't want to generate bitcode for some extensions. I can
turn off this feature by specifying with_llvm=0 in the make command.
```
On Tue, Feb 27, 2024 at 6:38 AM Stephen Frost wrote:
>
> Greetings,
>
> * Xing Guo (higuox...@gmail.com) wrote:
> > Looks that many hackers are happy with the original patch except that
> > the original patch needs a simple rebase, though it has been 3 years.
>
&
On Mon, Feb 26, 2024 at 7:27 PM Daniel Gustafsson wrote:
>
> > On 1 Jul 2020, at 10:36, Daniel Gustafsson wrote:
> >
> >> On 27 Mar 2020, at 11:22, Haozhou Wang wrote:
> >
> >> We rebased this patch with the newest master.
> >
> > This patch now fails to build according to Travis:
> >
> >
l2/commit/45470611b047db78106dcb2fdbd4164163c15ab7
Best Regards,
Xing
From bded3361f7f2ac7b4734d59de8ddb07875d9489d Mon Sep 17 00:00:00 2001
From: Xing Guo
Date: Sun, 3 Dec 2023 23:09:51 +0800
Subject: [PATCH v1] Make PostgreSQL work with newer version of libxml2.
There's a breaking change of API since v2.12.0 of libxml2. T
of hacks for another.
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
>
--
Best Regards,
Xing
From d620d3a2b44cef63024baca4ccdf55bf7724737f Mon Sep 17 00:00:00 2001
From: Xing Guo
Date: Thu, 2 Nov 2023 16:42:00 +0800
Subject: [PATCH v3] Consider tre
Thank you Tom!
Your comment
"NULL doesn't have semantics that are visibly different from an empty
string" is exactly what I want to confirm :-)
On 11/2/23, Tom Lane wrote:
> I wrote:
>> Hmm ... if we're doing it ourselves, I suppose we've got to consider
>> it supported :-(. But I'm still
is a valid boot_val for string variables, I just
came across some extensions that use NULL as their boot_val. If the
boot_val can't be NULL in extensions, we should probably add some
assertions or comments about it?
Best Regards,
Xing
On Wed, Nov 1, 2023 at 11:30 PM Tom Lane wrote:
> Xing
e place with a similar code in guc.c around line 1472.
> Although I don't have exact steps to trigger a crash I suggest adding
> a similar check there.
>
> --
> Best regards,
> Aleksander Alekseev
>
From bf0a9f848e69097a034692ed7b0be0ad81a5d991 Mon Sep 17 00:00:00 2001
From: Xing Gu
From dcd7a49190f0e19ba0a1e697cac45724450f6365 Mon Sep 17 00:00:00 2001
From: Xing Guo
Date: Wed, 1 Nov 2023 16:41:49 +0800
Subject: [PATCH] Don't use strcmp() with nullable pointers.
Passing a NULL pointer to strcmp() is an undefined behavior. It can make
the PostgreSQL server crash. This patch
in
slot_compile_deform. Patch is attached.
[1]
https://github.com/postgres/postgres/blob/0c60e8ba80e03491b028204a19a9dca6d216df91/src/backend/jit/llvm/llvmjit_expr.c#L322
Best Regards,
Xing
From 6db602bd7d0964b60134c4b20b4107a1e8717b78 Mon Sep 17 00:00:00 2001
From: Xing Guo
Date: Mon, 30 Oct 2023 22:34:10
Hi,
Can we also check if the clang's version is compatible with llvm's version
in llvm.m4? I have multiple llvm toolchains installed on my system and I
have to specify the $CLANG and $LLVM_CONFIG variables each time I build the
server against a toolchain that is not present in $PATH. If one of
Hi,
On 8/10/23, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On Wed, Aug 09, 2023 at 03:23:32PM +0200, Peter Eisentraut wrote:
>> On 03.08.23 18:56, Dmitry Dolgov wrote:
>> > I would like to get your opinion, folks. Does it sound interesting
>> > enough for the community, is it worth it to
Sorry for not responding to this thread for a long time and a huge thank
you for pushing it forward!
Best Regards,
Xing
On Fri, May 5, 2023 at 7:42 AM Nathan Bossart
wrote:
> On Thu, May 04, 2023 at 08:39:03AM -0400, Tom Lane wrote:
> > Hmm, I'm not sure why PLy_trigger_build_args's
On Mon, Jan 16, 2023 at 11:29 PM Tom Lane wrote:
> Xing Guo writes:
> > Are there any unsafe codes in pltcl.c? The return statement is in the
> > PG_CATCH() block, I think the exception stack has been recovered in
> > PG_CATCH block so the return statement in PG_CAT
Hi,
I revised my patch, added the missing one that Nathan mentioned.
Are there any unsafe codes in pltcl.c? The return statement is in the
PG_CATCH() block, I think the exception stack has been recovered in
PG_CATCH block so the return statement in PG_CATCH block should be ok?
```
PG_TRY();
{
Hi Nathan.
On 1/13/23, Nathan Bossart wrote:
> On Thu, Jan 12, 2023 at 11:19:29PM +0800, Xing Guo wrote:
>> I was running static analyser against PostgreSQL and found there're 2
>> return statements in PL/Python module which is not safe. Patch is
>> attache
Hi hackers,
I was running static analyser against PostgreSQL and found there're 2
return statements in PL/Python module which is not safe. Patch is
attached.
--
Best Regards,
Xing
diff --git a/src/pl/plpython/plpy_exec.c b/src/pl/plpython/plpy_exec.c
index 923703535a..c0e4a81283 100644
---
On 1/9/23, John Naylor wrote:
> On Thu, Jan 5, 2023 at 8:18 AM John Naylor
> wrote:
>>
>> The label TSS_BUILDRUNS has a similar style and also the following
> comment, so I will push this patch with a similar comment added unless
> someone wants to make a case for doing otherwise.
>>
>> * Note
Hi hackers,
While playing with pg_regress and pg_isolation_regress, I noticed that
there's a potential nullptr deference in both of them.
How to reproduce:
Specify the `--dbname=` option without providing any database name.
//pg_regress --dbname= foo
//pg_isolation_regress --dbname= foo
Hi Richard,
Sorry for not responding for a long time, I missed the previous email
by accident :-)
I attached a newer patch based on your suggestions and created an
entry in cf manager.
https://commitfest.postgresql.org/40/3924/
Best Regards,
Xing Guo
On 9/16/22, Richard Guo wrote:
> On
Hi hackers,
The bounded heap sorting status flag is set twice in sort_bounded_heap()
and tuplesort_performsort(). This patch helps remove one of them.
Best Regards,
Xing
diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c
index d90a1aebdf..84dc0d07f9 100644
---
On Mon, Oct 18, 2021 at 2:45 PM Michael Paquier wrote:
> On Mon, Oct 18, 2021 at 01:56:07PM +0800, Xing GUO wrote:
> > My question is, is it a deliberate design that makes try_relation_open
> and
> > relation_open different? Shall we mention it in the comment of
> > try
Hi hackers,
I'm writing an extension that employs `object_access_hook`. I want to
monitor the table creation event and record the mapping between `reloid`
and `relfilenode` during a transaction. Here's my code snippet,
```
static void
my_object_access_hook(ObjectAccessType access,
On 4/21/21, Tom Lane wrote:
> Xing GUO writes:
>> Thank you very much. I'm facing the same problem yesterday. May I
>> suggest that document it in the installation guide on MacOS platform?
>
> It is documented --- see last para under
>
> https://www.postgresql.or
Hi hackers,
Thank you very much. I'm facing the same problem yesterday. May I
suggest that document it in the installation guide on MacOS platform?
On 4/21/21, Andrew Dunstan wrote:
>
> On 4/20/21 11:02 AM, Tom Lane wrote:
>> Aleksander Alekseev writes:
>>> While trying to build PostgreSQL
35 matches
Mail list logo
