le_oids = list_concat(table_oids, tmp_oids);
+ }
+ }
/*
* Perform operations on collected tables.
*/
[1] How Autovacuum Goes Wrong: And Can We Please Make It Stop Doing
That? https://www.youtube.com/watch?v=RfTD-Twpvac
--
Regards
Junwang Zhao
37000108 tbnzw8, #0x0, 0x1575c <_PQsetClientEncoding+0x70>
15740: 1401 b 0x15744 <_PQsetClientEncoding+0x58>
15744: f9401be8 ldr x8, [sp, #0x30]
15748: b941f908 ldr w8, [x8, #0x1f8]
>
>
> --
> Regrads,
> Japin Li
>
>
--
Regards
Junwang Zhao
On Wed, Apr 9, 2025 at 12:25 PM Japin Li wrote:
>
> On Wed, 09 Apr 2025 at 10:34, Junwang Zhao wrote:
> > On Wed, Apr 9, 2025 at 5:22 AM David Rowley wrote:
> >>
> >> On Wed, 9 Apr 2025 at 03:46, Peter Eisentraut wrote:
> >> > To avoid creating an ar
len = snprintf(qbuf, sizeof(qbuf), "set client_encoding to
'%s'", encoding);
+ if (len >= sizeof(qbuf))
return -1;
/* ok, now send a query */
- sprintf(qbuf, query, encoding);
res = PQexec(conn, qbuf);
if (res == NULL)
> David
--
Regards
Junwang Zhao
Hi Ashutosh,
On Mon, Apr 7, 2025 at 1:19 PM Ashutosh Bapat
wrote:
>
> On Sat, Apr 5, 2025 at 6:20 PM Junwang Zhao wrote:
> >
> > Hi Ashutosh and Peter,
> >
> > Since this PGQ feature won't be in PG 18, I'd like to raise a discussion of
> > the poss
Hi Ashutosh and Peter,
On Wed, Mar 12, 2025 at 12:31 PM Ashutosh Bapat
wrote:
>
> Thanks
>
> On Tue, Mar 11, 2025 at 7:51 PM Junwang Zhao wrote:
>
> >
> > Here is a new version with Amit's fix and my trivial refactors.
> >
> > 0001-0010 is the same
On Tue, Apr 1, 2025 at 1:11 AM Tom Lane wrote:
>
> Junwang Zhao writes:
> > On Mon, Mar 31, 2025 at 5:58 AM Tom Lane wrote:
> >> In v18, it's somewhat annoying that the typcache doesn't cache
> >> the typarray field; we would not need a separate get_arra
On Wed, Apr 2, 2025 at 6:05 AM Tom Lane wrote:
>
> Junwang Zhao writes:
> > On Tue, Apr 1, 2025 at 1:11 AM Tom Lane wrote:
> >> Attached 0001 is the same as v18, and then 0002 is the proposed
> >> addition to typcache.
>
> > I've applied the patches
be helped immediately. I left it alone
> for the moment; wonder if anyone else has an opinion?
The need for `elmtyp` and `array_type` here because a column can
have arrays with varying dimensions. Maybe other callers don't share
this behavior?
>
> regards, tom lane
>
--
Regards
Junwang Zhao
d result...
> I didn't dig deeper why commit 4618045bee made this patch result correct,
> but I guess it would be best to include such a test case,
> so I've attached a patch.
>
No objection for the test case, thanks.
>
> [0]
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=4618045bee4a6d3efcb489c319649d8dd9aaa738
--
Regards
Junwang Zhao
Hi Amit,
On Tue, Mar 11, 2025 at 5:06 PM Amit Langote wrote:
>
> Hi Ashutosh, Junwang,
>
> On Tue, Mar 11, 2025 at 4:22 PM Ashutosh Bapat
> wrote:
> > On Wed, Feb 26, 2025 at 8:04 PM Junwang Zhao wrote:
> > > I added a trivial fix(v12-0014) that ca
t; Please let me know if you have more comments.
>
> Best Regards,
> Steven
--
Regards
Junwang Zhao
gt; > >> Kirill,
> > >>
> > >> Good catch!
> > >> I will split the patch into two to cover both cases.
> > >>
> > >> Thanks,
> > >> Steven
> > >>
> > >>
> > >> Junwang Zhao 于2024年8月9日周五 18:1
nkall, so I guess it's ok not setting the InvalidBlockNumber?
>
> I did a quick seach of smgrdounlinkall usage, SMgrRelation seems
> not needed after the calling of smgrdounlinkall.
>
After a second look, I realize I'm wrong, it's that the pointers to SMgrRelation
are freed, not the SMgrRelation itself.
So I agree with you that we would end up missing some operations with
this patch.
> >
> > Regards,
> >
> > --
> > Masahiko Sawada
> > Amazon Web Services: https://aws.amazon.com
>
>
>
> --
> Regards
> Junwang Zhao
--
Regards
Junwang Zhao
ed patch set and
> >> found Sutou has already fixed this issue.
> >
> > +1, except I'd suggest declaring the parameters as
> > "const CopyFormatOptions *opts".
>
> Thanks for pointing out this (and sorry for missing this in
> our reviews...)!
>
> How about the attached patch?
Looking good, thanks
>
> I'll rebase the v35 patch set after this is fixed.
>
>
> Thanks,
> --
> kou
--
Regards
Junwang Zhao
another thread (Emitting JSON to file using COPY TO),
I found the recently committed patches on this thread pass the
CopyFormatOptions struct directly rather a pointer of the struct
as a function parameter of CopyToGetRoutine and CopyFromGetRoutine.
Then I took a quick look at the newly rebased patch set and
found Sutou has already fixed this issue.
I'm wondering if we should fix it as a separate commit as
it seems like an oversight of previous patches?
--
Regards
Junwang Zhao
tions.
> but consolidated 3 bool fields into one enum to make code more lean.
> I think the refactoring (v14-0001) is worth it.
I've refactored the patch to adapt the newly introduced CopyToRoutine struct,
see 2e4127b6d2.
v15-0001 is the merged one of v14-0001 and v14-0002
There are
; ModifyTable.
>
> I've attached a fix with a test added based on your example. I plan to
> push this on Monday.
>
I applied the patch and the problem solved, I have a small question that
should the following line
```
if (node->mergeActionLists == NIL)
```
be changed to
```
if (mtstate->mt_mergeActionLists == NIL)
```
ISTM that if we have pruned all the merge actions, there is no harm we
omit setting mtstate->mt_merge_subcommands to 0.
> --
> Thanks, Amit Langote
--
Regards
Junwang Zhao
Hi Ashutosh,
On Tue, Jan 28, 2025 at 6:17 PM Ashutosh Bapat
wrote:
>
> On Fri, Jan 24, 2025 at 9:16 PM Junwang Zhao wrote:
> >
> > I figured out it's because I have `-DWRITE_READ_PARSE_PLAN_TREES` this
> > option,
> > removing this option clears the war
On Tue, Jan 28, 2025 at 7:03 PM Ashutosh Bapat
wrote:
>
> On Tue, Jan 28, 2025 at 4:31 PM Junwang Zhao wrote:
> >
> > On Tue, Jan 28, 2025 at 6:17 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Fri, Jan 24, 2025 at 9:16 PM Junwang Zhao wrote:
> &g
On Tue, Jan 28, 2025 at 6:17 PM Ashutosh Bapat
wrote:
>
> On Fri, Jan 24, 2025 at 9:16 PM Junwang Zhao wrote:
> >
> > I figured out it's because I have `-DWRITE_READ_PARSE_PLAN_TREES` this
> > option,
> > removing this option clears the warning, but I'
On Fri, Jan 24, 2025 at 11:46 PM Junwang Zhao wrote:
>
> On Fri, Jan 24, 2025 at 9:31 PM Ashutosh Bapat
> wrote:
> >
> > On Sun, Jan 19, 2025 at 6:45 PM Junwang Zhao wrote:
> > >
> > > Hi Ashutosh,
> > >
> > > On Wed, Jan 1, 2025 at 5:
On Fri, Jan 24, 2025 at 9:31 PM Ashutosh Bapat
wrote:
>
> On Sun, Jan 19, 2025 at 6:45 PM Junwang Zhao wrote:
> >
> > Hi Ashutosh,
> >
> > On Wed, Jan 1, 2025 at 5:02 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Wed, Jan 1, 2025 at 2:22 PM As
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 re
On Sat, Jan 18, 2025 at 9:43 AM Tom Lane wrote:
>
> Junwang Zhao writes:
> > ISTM Andres tend to use *es_epq_active* in a boolean way,
> > like `if (es_epq_active) then`, but in the code base, all its usages
> > follow pattern `if (es_epq_active == NULL) then`, so
-id/CA%2BHiwqF%2BoydVreYN3Xp7U6x_LKi9ZL%2BNo2X6WUv8X_kN%2ByHSLA%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/20190828030201.v5u76ty47mtw2efp%40alap3.anarazel.de
--
Regards
Junwang Zhao
v1-0001-rename-es_epq_active-to-es_epqstate.patch
Description: Binary data
hich I
guess you will fix before committing.
- EPQState *epqstate;
+ EPQState *epqstate;
>
> Vladlen, does what David wrote and the new commit message answer your
> question(s)?
>
> --
> Thanks, Amit Langote
--
Regards
Junwang Zhao
On Sat, Jan 11, 2025 at 4:57 PM Junwang Zhao wrote:
>
> On Fri, Jan 10, 2025 at 10:49 PM Vladlen Popolitov
> wrote:
> >
> > Amit Langote писал(а) 2025-01-10 18:22:
> > > On Fri, Jan 10, 2025 at 7:36 PM David Rowley
> > > wrote:
> > >&
y code.
: start 2b8590, end 2b868c => 252
: start 2b8034, end 2b8140 => 268
: start 2b8144, end 2b831c => 472
: start 2b8320, end 2b858c => 620
Before Amit's optimization, it was basically called the
ExecSeqScanWithQualProject, you
can see the other 3 variants all have some reduction in function size.
> --
> Best regards,
>
> Vladlen Popolitov.
[0]
https://docs.google.com/spreadsheets/d/1AsJOUgIfSsYIJUJwbXk4aO9FVOFOrBCvrfmdQYkHIw4/edit?usp=sharing
--
Regards
Junwang Zhao
elieve some redundant wording has been committed.
K may be chosen may be chosen at ANALYZE time.
Attached patch fixes it and with some line adjustments.
>
> --
> Bruce Momjian https://momjian.us
> EDB https://enterprisedb.com
>
>
ge link quals, I found that we
> > > need to find and store the operator to be used for key matching in
> > > those quals. I think we have to do something similar to what primary
> > > key handling code does - find the equality operator when creating edge
> > > de
lationship is many to many.
Ok, then it makes sense to me. Thanks for the explanation.
>
> >
> > From the name _pg_propgraph_label_property_, I tend to think it is
> > referencing _pg_propgraph_label_, but actually it is referencing
> > _pg_propgraph_element_label_.
> >
>
> Right.
>
> --
> Best Wishes,
> Ashutosh Bapat
--
Regards
Junwang Zhao
-edge link quals, I found that we
> > > need to find and store the operator to be used for key matching in
> > > those quals. I think we have to do something similar to what primary
> > > key handling code does - find the equality operator when creating edge
> > > descriptor and store it in pg_propgraph_element. I am not sure whether
> > > we should add a dependency on the operator. I will look into this
> > > next.
> >
> > 0006 in the attached patch series completes this work. Now we find the
> > equality operators to be used for vertex-edge quals and save it in
> > pg_propgraph_element catalog and also add a dependency between the
> > edge element and the equality operators.
> >
> > 0008 - has WIP fix for \d and \d+
> >
> > --
> > Best Wishes,
> > Ashutosh Bapat
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
I'm looking at the catalog definition, I have some questions which
might be silly.
Each pg element can have multiple labels(whose properties belong
to the same pg element), can we have multiple elements share the
same label?
If we have a 1..* relation between element and label, I think maybe
we don't need _pg_propgraph_label_.
>From the name _pg_propgraph_label_property_, I tend to think it is
referencing _pg_propgraph_label_, but actually it is referencing
_pg_propgraph_element_label_.
--
Regards
Junwang Zhao
correspond to a base relation, such as a join RTE or an
* unreferenced view RTE; or if the RelOptInfo hasn't been made yet.
*/
>
> --
> Best regards,
> Dmitry mailto:pgsql-hack...@dima.nikitin.name
>
>
>
--
Regards
Junwang Zhao
On Fri, Nov 29, 2024 at 9:07 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Thu, 28 Nov 2024 19:02:57 +0800,
> Junwang Zhao wrote:
>
> >> > I tested 3 branches:
> &
On Thu, Nov 28, 2024 at 2:16 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 27 Nov 2024 19:49:17 +0800,
> Junwang Zhao wrote:
>
> > I just gave this another round of bench
e is that 3
is always better than 1 & 2.
I reviewed the patch set of 3 and I don't see any magic.
You can see the detailed results here[2], I can not upload files so I
just shared the google doc link, ping me if you can not open the link.
[0]: https://github.com/pghacking/scripts/tree/main/extensible_copy
[1]:
https://www.postgresql.org/message-id/CACJufxH8J0uD-inukxAmd3TVwt-b-y7d7hLGSBdEdLXFGJLyDA%40mail.gmail.com
[2]:
https://docs.google.com/spreadsheets/d/1wJPXZF4LHe34X9IU1pLG7rI9sCkSy2dEkdj7w7avTqM/edit?usp=sharing
--
Regards
Junwang Zhao
On Tue, Nov 12, 2024 at 9:13 AM Tom Lane wrote:
>
> Junwang Zhao writes:
> > While working on general array sort[1], I played with intarray
> > extension, found a bug (or at least inconsistency) when sorting
> > multidimensional int array:
>
> > create ex
message-id/CAEG8a3KD7ZmQpxNhfPxyc0BjTTTUXiqb56VuMgB7Muu0%2ByV%3DqQ%40mail.gmail.com
--
Regards
Junwang Zhao
v1-0001-int-array-support-multi-dim.patch
Description: Binary data
rested.
[0] https://github.com/pghacking/awesome-postgres-hacking
--
Regards
Junwang Zhao
Hi Michael,
On Fri, Nov 8, 2024 at 8:52 AM Michael Paquier wrote:
>
> On Thu, Nov 07, 2024 at 10:06:04PM +0800, Junwang Zhao wrote:
> > I'm afraid this can not be achieved in my current implementation, a simple
> > case is:
> >
> > SELECT array_sort
CC,bar,bbc,foo,NULL}
SELECT array_sort(a COLLATE "C") FROM (VALUES
('{foo,bar,null,CCC,Abc,bbc}'::text[] COLLATE "C"),
('{foo,bar,null,CCC,Abc,bbc}'::text[])) v(a);
{Abc,CCC,bar,bbc,foo,NULL}
{Abc,CCC,bar,bbc,foo,NULL}
Maybe add some documents to specify this?
> --
> Michael
--
Regards
Junwang Zhao
On Thu, Nov 7, 2024 at 10:29 PM Robert Haas wrote:
>
> On Thu, Nov 7, 2024 at 8:56 AM Junwang Zhao wrote:
> > Yeah, this is reasonable but one case I can't be sure:
> >
> > SELECT array_sort('{{2,3,4}}'::xid[]);
> >
> > This will return the
.a) [-13:-11][0:1][21:22]) from t where array_ndims(a) =
> 3;
> SELECT array_sort((t.a) [-13:-11][0:0][20:21]) from t where array_ndims(a) =
> 3;
>
> The test output is ok to me.
Merged into V13 with some change and added you as a co-author.
There is one issue left as Micheal
Hi Michael,
On Mon, Nov 4, 2024 at 1:46 PM Michael Paquier wrote:
>
> On Sun, Nov 03, 2024 at 11:33:05AM +0800, Junwang Zhao wrote:
> > Rebase needed due to array_reverse committed, PFA v11.
>
> There has been another conflict since you have posted this version
> (noticed t
.a) [-13:-11][0:1][21:22]) from t where array_ndims(a) =
> 3;
> SELECT array_sort((t.a) [-13:-11][0:0][20:21]) from t where array_ndims(a) =
> 3;
>
> The test output is ok to me.
Thanks for the bounds preserve solution, I just looked at 0002,
+ if (astate->arraystate != NULL)
+ {
+ memcpy(astate->arraystate->dims, dims, ndim * sizeof(int));
+ memcpy(astate->arraystate->lbs, lbs, ndim * sizeof(int));
+ Assert(ndim == astate->arraystate->ndims);
+ }
It seems to me we only need to set astate->arraystate->lbs[0] = lbs[0] ?
--
Regards
Junwang Zhao
On Wed, Oct 30, 2024 at 10:41 PM Junwang Zhao wrote:
>
> On Wed, Oct 30, 2024 at 10:17 PM Junwang Zhao wrote:
> >
> > Hi,
> >
> > On Wed, Oct 30, 2024 at 9:29 PM Aleksander Alekseev
> > wrote:
> > >
> > > Hi,
> > >
&
column collation,
because it's the partkey collation that decides which partition a row to
be dispatched.
What Jian proposed is also reasonable but seems another aspect of $subject?
Just some random thought, might be wrong ;(
--
Regards
Junwang Zhao
On Wed, Oct 30, 2024 at 10:17 PM Junwang Zhao wrote:
>
> Hi,
>
> On Wed, Oct 30, 2024 at 9:29 PM Aleksander Alekseev
> wrote:
> >
> > Hi,
> >
> > Thanks for the updated patch set.
> >
> > > > > +Datum
> > > > > +array
roname, p2.oid, p2.proname
FROM pg_proc AS p1, pg_proc AS p2
WHERE p1.oid < p2.oid AND
p1.prosrc = p2.prosrc AND
p1.prolang = 12 AND p2.prolang = 12 AND
(p1.prokind != 'a' OR p2.prokind != 'a') AND
(p1.prolang != p2.prolang OR
p1.prokind != p2.prokind OR
p1.prosecdef != p2.prosecdef OR
p1.proleakproof != p2.proleakproof OR
p1.proisstrict != p2.proisstrict OR
p1.proretset != p2.proretset OR
p1.provolatile != p2.provolatile OR
p1.pronargs != p2.pronargs);
>
> --
> Best regards,
> Aleksander Alekseev
--
Regards
Junwang Zhao
n not to specify array_sort in pg_proc.dat?
It is specified in 0001 (see oid => '8810').
>
> The tests cover is_ascending => true | false, which is OK, but only
> (is_ascending = true, nulls_first => true) and (is_ascending => false,
> nulls_fist => false). For the case when both optional arguments are
> specified you have to test at least 4 combinations.
The omitted two is the same as the two with two parameters specified,
anyway, add all 4 cases in v9.
>
> --
> Best regards,
> Aleksander Alekseev
--
Regards
Junwang Zhao
v9-0002-support-sort-order-and-nullsfirst-flag.patch
Description: Binary data
v9-0001-general-purpose-array_sort.patch
Description: Binary data
On Fri, Oct 25, 2024 at 8:02 PM Junwang Zhao wrote:
>
> On Fri, Oct 25, 2024 at 1:19 AM Aleksander Alekseev
> wrote:
> >
> > Hi,
> >
> > > I can accept this outcome though an optional three-valued boolean sort
> > > order (ascending and desce
t
by using two boolean parameters Jian suggested earlier.
Will send out another version by tomorrow.
>
> --
> Best regards,
> Aleksander Alekseev
--
Regards
Junwang Zhao
On Thu, Oct 24, 2024 at 8:40 PM jian he wrote:
>
> On Wed, Oct 23, 2024 at 10:28 PM Junwang Zhao wrote:
> > PFA v7 with multi-array support.
> >
>
> if (ARR_NDIM(array) == 1)
> {
> }
> else
> {
> }
> can be simplified.
> i think beginning part of arr
is specifying.
>
> I've discussed the issue with Thomas on PGConf.eu and he proposed to use
> stream reset.
> PFA v3.
Yeah, read_stream_reset fits better.
The patch LGTM, thanks.
>
>
> Best regards, Andrey Borodin.
--
Regards
Junwang Zhao
Sorry for the late reply.
On Mon, Oct 14, 2024 at 4:10 AM Tom Lane wrote:
>
> Junwang Zhao writes:
> > It seems there is not much meaning to sort composite type,
> > so are you proposing we should error on that?
>
> It's hardly "general purpose" if it r
On Sun, Oct 20, 2024 at 3:19 PM Andrey M. Borodin wrote:
>
>
>
> > On 19 Oct 2024, at 20:41, Junwang Zhao wrote:
> >
> > I'm wondering why is the case, ISTM that we can do *p.current_blocknum
> > = scanblkno*
> > and *p.last_exclusive = num_pages* i
While reading the stream read interfaces, I found a typo.
/*
* How many neighboring-on-disk blocks can we can scatter-read into
* other buffers at the same time? In this case we don't wait if we
Seems the second *can* is not necessary.
--
Regards
Junwang Zhao
ficant, bigger than performance
> change. Perhaps, a less noisy benchmark can be devised.
>
> What do you think? If this approach seems worthwhile, I can adapt same
> technology to other AMs.
>
I think this is a use case where the read stream api fits very well, thanks.
>
> Best regards, Andrey Borodin.
>
> [0]
> https://rhaas.blogspot.com/2024/08/postgresql-hacking-workshop-september.html
>
--
Regards
Junwang Zhao
an refactor loop by 'smgrclose()'? I see it is not
> quite the same.
smgrclose does more by setting smgr_cached_nblocks[] and smgr_targblock
to InvalidBlockNumber, I see no harm with the replacement, not 100% sure
though.
>
> Regards,
> Ilia Evdokimov,
> Tantor Labs LLC.
>
--
Regards
Junwang Zhao
e multidimensional.
It seems there is not much meaning to sort composite type,
so are you proposing we should error on that?
--
Regards
Junwang Zhao
On Wed, Oct 9, 2024 at 11:46 PM Junwang Zhao wrote:
>
> On Wed, Oct 9, 2024 at 10:10 PM Junwang Zhao wrote:
> >
> > Hi Amit,
> >
> > On Thu, Oct 3, 2024 at 2:22 PM Amit Langote wrote:
> > >
> > > Hi Junwang,
> > >
> > > On Wed,
On Wed, Oct 9, 2024 at 10:10 PM Junwang Zhao wrote:
>
> Hi Amit,
>
> On Thu, Oct 3, 2024 at 2:22 PM Amit Langote wrote:
> >
> > Hi Junwang,
> >
> > On Wed, Oct 2, 2024 at 11:46 PM Junwang Zhao wrote:
> > > On Wed,
Hi Amit,
On Thu, Oct 3, 2024 at 2:22 PM Amit Langote wrote:
>
> Hi Junwang,
>
> On Wed, Oct 2, 2024 at 11:46 PM Junwang Zhao wrote:
> > On Wed, Oct 2, 2024 at 9:51 AM jian he wrote:
> > >
> > > > >
> > > > > + typentry = (TypeCacheEn
Hi Michael,
On Tue, Oct 8, 2024 at 11:21 AM Michael Paquier wrote:
>
> On Thu, Aug 08, 2024 at 09:47:20AM +0800, Junwang Zhao wrote:
> > Thanks for your review.
>
> The SPLIT/MERGE grammar has been reverted in 3890d90c1508, so this
> patch concept does not apply anymore.
&g
e TYPECACHE_LT_OPR or TYPECACHE_GT_OPR
> then we cannot do the sort, we should just error out.
>
> I just tried this colour type [1] with (CREATE TYPE colour (INPUT =
> colour_in, OUTPUT = colour_out, LIKE = pg_catalog.int4);
>
> select array_sort('{#FF, #FF}'::colour[]);
> of course it will segfault with your new Assert.
>
>
> [1] https://github.com/hlinnaka/colour-datatype/blob/master/colour.c
Make sense, PFA v5 with Jian's suggestion.
--
Regards
Junwang Zhao
v5-0001-general-purpose-array_sort.patch
Description: Binary data
Hi Jian,
On Mon, Sep 30, 2024 at 11:13 PM jian he wrote:
>
> On Mon, Sep 30, 2024 at 1:01 PM Junwang Zhao wrote:
> >
> > > I would suggest accepting:
> > > asc
> > > desc
> > > asc nulls first
> > > asc nulls last *
> > > desc n
On Sun, Sep 29, 2024 at 10:51 AM David G. Johnston
wrote:
>
> On Sat, Sep 28, 2024 at 7:05 PM Junwang Zhao wrote:
>>
>> On Sat, Sep 28, 2024 at 10:41 PM jian he wrote:
>> >
>> > dir can have only two potential values, make it
>> > as a boolean
On Sat, Sep 28, 2024 at 10:41 PM jian he wrote:
>
> On Sat, Sep 28, 2024 at 7:52 PM Junwang Zhao wrote:
> >
> > PFA v2, use COLLATE keyword to supply the collation suggested by
> > Andreas offlist.
> >
> this is better. otherwise we need extra care to hand
On Fri, Sep 27, 2024 at 9:15 PM Junwang Zhao wrote:
>
> Hi hackers,
>
> per David's suggestion, this patch implements general
> purpose array sort.
>
> We can do the following with this patch:
>
> SELECT array_sort('{1.1,3.3,5.5,2.2,4.4,6.6}'::float
,ȺȺȺ,ⱥⱥⱥ,ⱥȺ}'::text[]);
SELECT array_sort('{abc DEF 123abc,ábc sßs ßss DÉF,DŽxxDŽ džxxDž
Džxxdž,ȺȺȺ,ⱥⱥⱥ,ⱥȺ}'::text[], 'asc', 'pg_c_utf8');
--
Regards
Junwang Zhao
v1-0001-general-purpose-array_sort.patch
Description: Binary data
Hi Tom and Michael,
On Fri, Sep 20, 2024 at 12:38 PM Tom Lane wrote:
>
> Michael Paquier writes:
> > On Fri, Sep 20, 2024 at 11:51:49AM +0800, Junwang Zhao wrote:
> >> Should you also bump the catalog version?
>
> > No need to worry about that when sending a pat
machine, not skipped are all OK.
Should you also bump the catalog version?
--
Regards
Junwang Zhao
==64983==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 248 byte(s) in 1 object(s) allocated from:
#0 0x7fc7729df9cf in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x55bff5480e8b in save_ps_display_args
../postgres/src/backend/utils/misc/ps_status.c:190
#2 0x55bff4a5a298 in main ../postgres/src/backend/main/main.c:90
#3 0x7fc771924249 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 19 byte(s) in 1 object(s) allocated from:
#0 0x7fc77299777b in __interceptor_strdup
../../../../src/libsanitizer/asan/asan_interceptors.cpp:439
#1 0x55bff5480f41 in save_ps_display_args
../postgres/src/backend/utils/misc/ps_status.c:198
#2 0x55bff4a5a298 in main ../postgres/src/backend/main/main.c:90
#3 0x7fc771924249 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
I worked around by moving *new_environ* as a global variable, I think this is
false positive report so maybe this deserves a patch?
I tried to apply your v2 patch set but v2-0004 seems out of date.
--
Regards
Junwang Zhao
On Wed, Sep 4, 2024 at 7:41 PM Antonin Houska wrote:
>
> Junwang Zhao wrote:
>
> > Thanks for working on this, I think this is a very useful feature.
> >
> > The patch doesn't compile in the debug build with errors:
> >
> > ../postgres
ntext for saving skipped keys */
>
> And this has nothing to do with skipped keys.
>
> So I adjusted that way and pushed.
>
I didn't get the time to reply to you quickly, sorry about that.
Thank you for improving the patch and appreciate your time
for working on this.
>
>
> Thanks for the report / patch.
>
> --
> Tomas Vondra
--
Regards
Junwang Zhao
CC'd hackers list.
On Wed, Sep 4, 2024 at 7:54 PM Tomas Vondra wrote:
>
> On 9/4/24 11:55, Junwang Zhao wrote:
> > ...
> >
> > ISTM that the JsonUniqueHashEntry.key point to an address later got
> > invalidated by enlargeStringInfo, we can resolve this by ex
TION),
- errmsg("could
not change table \"%s\" to unlogged because it references logged table
\"%s\"",
+errmsg("could
not change table \"%s\" to unlogged because it is referenced by logged
table \"%s\"",
What do you think?
--
Regards
Junwang Zhao
ch can be implemented by doing the
> initial runtime pruning in that separate step. That way, we'll have
> all the necessary locks before calling ExecInitNode() and so we don't
> need to sprinkle the CachedPlanStillValid() checks all over the place
> and worry about missed checks and dealing with partially initialized
> PlanState trees.
>
> --
> Thanks, Amit Langote
@@ -1241,7 +1244,7 @@ GetCachedPlan(CachedPlanSource *plansource,
ParamListInfo boundParams,
if (customplan)
{
/* Build a custom plan */
- plan = BuildCachedPlan(plansource, qlist, boundParams, queryEnv);
+ plan = BuildCachedPlan(plansource, qlist, boundParams, queryEnv, true);
Is the *true* here a typo? Seems it should be *false* for custom plan?
--
Regards
Junwang Zhao
umStmt changes in gram.y, how do we suppose to
use the vacuum full concurrently? I tried the following but no success.
[local] postgres@demo:5432-36097=# vacuum (concurrently) aircrafts_data;
ERROR: CONCURRENTLY can only be specified with VACUUM FULL
[local] postgres@demo:5432-36097=# vacuum full (concurrently) full
aircrafts_data;
ERROR: syntax error at or near "("
LINE 1: vacuum full (concurrently) full aircrafts_data;
--
Regards
Junwang Zhao
On Sat, Aug 24, 2024 at 9:47 PM Peter Eisentraut wrote:
>
> On 24.08.24 14:49, Junwang Zhao wrote:
> > What I haven't addressed is that the repo still uses specific local
> > paths, I think
> > this is ok since the code is not going into the core.
>
> I'm n
Hi hackers,
On Sun, Aug 4, 2024 at 10:12 PM Andrew Dunstan wrote:
>
>
> On 2024-08-03 Sa 10:13 PM, Junwang Zhao wrote:
> > On Sat, Aug 3, 2024 at 7:30 PM Andrew Dunstan wrote:
> >>
> >> On 2024-08-02 Fr 2:45 PM, Peter Eisentraut wrote:
> >>> On 01.
On Fri, Aug 23, 2024 at 9:02 PM Peter Eisentraut wrote:
>
> On 15.08.24 12:25, Junwang Zhao wrote:
> > I noticed that there is a magic number which can be replaced by
> > CATCACHE_MAXKEYS
> > in struct cachedesc, I checked some other struct like CatCache, CatCTu
nbuckets; /* number of
hash buckets for this cache */
};
[0]:
https://www.postgresql.org/message-id/flat/603c8f071003281532t5e6c68eex458825485d4fcd98%40mail.gmail.com
--
Regards
Junwang Zhao
v1-0001-replace-magic-num-with-CATCACHE_MAXKEYS.patch
Description: Binary data
-0002-xxx
by using:
git format-patch -2 -v 3
Another kind reminder: Do not top-post when you reply ;)
>
> Thanks,
> Steven
>
> Steven Niu 于2024年8月12日周一 18:11写道：
>>
>> Kirill,
>>
>> Good catch!
>> I will split the patch into two to cover both cases.
&g
-81,6 +81,7 @@ typedef struct ParallelBlockTableScanDescData
BlockNumber phs_startblock; /* starting block number */
pg_atomic_uint64 phs_nallocated; /* number of blocks allocated to
* workers so far. */
+ BlockNumber phs_numblock; /* max number of blocks to scan */
} ParallelBlockTableScanDescData;
Can this be reorganized by putting phs_numblock after phs_startblock?
>
>
>
>
>
--
Regards
Junwang Zhao
On Fri, Aug 9, 2024 at 5:20 PM Kirill Reshke wrote:
>
> On Thu, 1 Aug 2024 at 17:32, Junwang Zhao wrote:
> >
> > Hi Steven,
> >
> > On Wed, Jul 31, 2024 at 11:16 AM Steven Niu wrote:
> > >
> > > Hello, hackers,
> > >
> &g
Hi Fujii,
Thanks for your review.
On Wed, Aug 7, 2024 at 9:54 PM Fujii Masao wrote:
>
>
>
> On 2024/08/06 19:28, Junwang Zhao wrote:
> > Attached v2 addressed all the problems you mentioned, thanks.
>
> Thanks for updating the patches!
>
>
> In the ALTER TABL
On Tue, Aug 6, 2024 at 5:34 PM Amul Sul wrote:
>
> On Mon, Aug 5, 2024 at 9:05 PM Junwang Zhao wrote:
> >
> > Hi Amul,
> >
> > Thanks for your review.
> >
> > On Mon, Aug 5, 2024 at 8:38 PM Amul Sul wrote:
> > >
> &g
Hi Amul,
Thanks for your review.
On Mon, Aug 5, 2024 at 8:38 PM Amul Sul wrote:
>
> On Mon, Jul 15, 2024 at 11:19 AM Junwang Zhao wrote:
> >
> > In [1], it is suggested that it might be a good idea to support
> > specifying the tablespace for each merged/split partitio
> repo, but got an error with the Docker build, which kinda reinforces
> your point.
The reason symlink does not work is that configure_vscode needs to copy
launch.json and tasks.json into .vscode, it has to be in the
WORKDIR/.devcontainer.
>
> Your point about "one person's preferences" is well taken - some of the
> git aliases supplied clash with mine.
>
Yeah, I will remove that.
>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
--
Regards
Junwang Zhao
ed, maybe to set indentation
> style or something.
>
Yeah, reasonable, I will discuss it with Andrey after he tries .devcontainer.
--
Regards
Junwang Zhao
On Fri, Aug 2, 2024 at 5:38 AM Andrew Dunstan wrote:
>
>
> On 2024-08-01 Th 10:56 AM, Junwang Zhao wrote:
> > Stack Overflow 2024 developer survey[1] said VSCode
> > is the most used development environment.
> >
> > In a PostgreSQL Hacker Mentoring discussio
On Fri, Aug 2, 2024 at 12:29 AM Jelte Fennema-Nio wrote:
>
> On Thu, 1 Aug 2024 at 16:56, Junwang Zhao wrote:
> > I post my daily used devcontainer config[2] , Jelte(ccd)
> > suggested that it might be a good idea we integrate the
> > config into postgres repo so that
o I left the author as empty,
have you ever registered? If you have a account, you can put your
name in the Authors list.
> Best Regards,
> Steven
>
> Junwang Zhao 于2024年8月1日周四 20:32写道：
>>
>> Hi Steven,
>>
>> On Wed, Jul 31, 2024 at 11:16 AM Steven Niu wrote:
rocess(e.g. postgres backend) and debug
with vscode.
PFA and please give it a try if you are a VSCode user.
[1]:
https://survey.stackoverflow.co/2024/technology#1-integrated-development-environment
[2]: https://github.com/atomicdb/devcontainer/tree/main/postgres
--
Regards
Junwang Zhao
v1-000
iacted behavior?
>
> So I make this patch. Could someone take a look at it?
>
> Thanks for your help,
> Steven
>
> From Highgo.com
>
>
You change LGTM, but the patch seems not to be applied to HEAD,
I generate the attached v2 using `git format` with some commit m
also copy format don't change during copy, we don't need to check
> binary or nor for each datum value.
I believe what you proposed is included in the patch 0002
attached in [1], but you use foreach_int, which I think is
an improvement.
[1]
https://www.postgresql.org/message-id/20240724.173059.909782980111496972.kou%40clear-code.com
--
Regards
Junwang Zhao
lly filled to define the OID of
+ * the type to pass to the input function. `atttypid` is the OID of data
+ * type used by the relation's attribute.
+typedef struct CopyToRoutine
+{
+ /*
+ * Called when COPY TO is started to set up the output functions
+ * associated to the relation's attributes reading from. `finfo` can be
+ * optionally filled. `atttypid` is the OID of data type used by the
+ * relation's attribute.
The second comment has a simplified description for `finfo`, I think it
should match the first by:
`finfo` can be optionally filled to provide the catalog information of the
output function.
After I post the patch diffs, the gmail grammer shows some hints that
it should be *associated with* rather than *associated to*, but I'm
not sure about this one.
I think the patches are in good shape, I can help to do some
further tests if needed, thanks for working on this.
>
> Thanks,
> --
> kou
--
Regards
Junwang Zhao
Hi, Peter
On Fri, Jul 26, 2024 at 11:06 PM Peter Eisentraut wrote:
>
> On 30.06.24 15:17, Junwang Zhao wrote:
> > Is there any extension that uses meson as build systems?
> > I'm starting a extension project that written in c++, cmake is my
> > initial choice a
1 - 100 of 254 matches
Mail list logo
