On Mon, Oct 7, 2024 at 4:03 PM vignesh C wrote:
>
> On Mon, 7 Oct 2024 at 12:26, Hayato Kuroda (Fujitsu)
> wrote:
>
> > One comment for your patch;
> > Shouldn't we add a streaming=off case for pg_dump test? You added lines but
> > no one
> > passes it.
> >
>
> Update existing pg_dump tests to c
On 15.10.24 17:04, Tom Lane wrote:
Peter Eisentraut writes:
but after the recent improvements to pg_locale_t handling, we don't need
all three anymore. All the information we have is contained in
pg_locale_t, so we just need to keep that one. This allows us to
structure the locale-using regul
On 21/10/2024 06:32, Dagfinn Ilmari Mannsåker wrote:
Alexander Korotkov writes:
+static Oid *in_progress_list;
+static int in_progress_list_len;
+static int in_progress_list_maxlen;
Is there any particular reason not to use pg_list.h for this?
Sure. The type cache lookup has to be a
On 21/10/2024 00:36, Alexander Korotkov wrote:
On Thu, Oct 17, 2024 at 12:41 PM Andrei Lepikhov wrote:
I think the first patch may already be committed, and this little burden
may be avoided in future versions.
I've integrated your patch. But I think
finalize_in_progress_typentries() is more
On Fri, 18 Oct 2024 at 17:42, Shubham Khanna
wrote:
>
> On Thu, Oct 17, 2024 at 12:58 PM vignesh C wrote:
> >
> > On Wed, 16 Oct 2024 at 23:25, Shubham Khanna
> > wrote:
> > >
> > > On Wed, Oct 9, 2024 at 9:08 AM vignesh C wrote:
> > > >
> > > > On Tue, 8 Oct 2024 at 11:37, Shubham Khanna
> >
On Fri, Oct 18, 2024 at 4:30 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Wednesday, October 9, 2024 2:34 PM shveta malik
> wrote:
> >
> > On Wed, Oct 9, 2024 at 8:58 AM shveta malik
> > wrote:
> > >
> > > On Tue, Oct 8, 2024 at 3:12 PM Nisha Moond
> > wrote:
> > > >
> > >
> >
> > Please find few com
On Fri, 18 Oct 2024 at 17:42, Shubham Khanna
wrote:
>
>
> I have fixed all the given comments. The attached v40-0001 patch
> contains the required changes.
1) The recent patch removed the function header comment where
generated column is specified, that change is required:
@@ -511,7 +511,6 @@ pub
On Sun, Oct 20, 2024 at 04:06:42PM +0900, Michael Paquier wrote:
> Yes, you are right. This reads better without the second "can".
Fixed that as well.
--
Michael
signature.asc
Description: PGP signature
On Mon, Oct 21, 2024 at 08:00:00AM +0800, jian he wrote:
> see picture attached.
It does not seem like you have used an exact message-id. We have
cases in the CF app where a pgsql-bugs messages is used, like this
one:
https://commitfest.postgresql.org/50/5242/
And a quick attempt at using one of
On Fri, Oct 18, 2024 at 06:16:50PM +0900, Michael Paquier wrote:
> Sure, why not.
Used "basic" as test name at the end, tweaked the comment close to
what you have suggested, and applied the result.
Thanks for the review.
--
Michael
signature.asc
Description: PGP signature
Hello!
> Sorry for being noisy, just for the case, want to notice that [1] needs
to be addressed before any real usage of conflict resolution.
> [1]:
https://www.postgresql.org/message-id/flat/OS0PR01MB5716E30952F542E256DD72E294802%40OS0PR01MB5716.jpnprd01.prod.outlook.com#8aa2083efa76e6a65f51b8a7
Hi,
While reading the fast-path lock code, I noticed that GetLockStatusData()
checks all slots for every backend to gather fast-path lock data. However,
backends with PID=0 don't hold fast-path locks, right? If so, we can
improve efficiency by having GetLockStatusData() skip those backends early.
hi.
click through
src/backend/commands/copyfromparse.c
comments link.
/*
* These macros centralize code used to process line_buf and input_buf buffers.
* They are macros because they often do continue/break control and to avoid
* function call overhead in tight COPY loops.
*
* We must use "if
Alexander Korotkov writes:
> +static Oid *in_progress_list;
> +static int in_progress_list_len;
> +static int in_progress_list_maxlen;
Is there any particular reason not to use pg_list.h for this?
- ilmari
On Sun, Oct 20, 2024 at 9:00 PM Alexander Korotkov wrote:
> On Sun, Oct 20, 2024 at 8:47 PM Alexander Korotkov
> wrote:
> > On Tue, Oct 15, 2024 at 12:50 PM jian he
> > wrote:
> > > build from source, DCLOBBER_CACHE_ALWAYS takes a very long time.
> > > So I gave up.
> > >
> > >
> > > in lookup
On Sun, Oct 20, 2024, at 23:03, Joel Jacobson wrote:
> On Sun, Oct 20, 2024, at 16:52, Joel Jacobson wrote:
>> On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote:
>>> I think the function calls should be in the FROM clause, and restrict the
>>> pg_shdepend rows to only the ones in the current dat
On Sun, Oct 20, 2024, at 16:52, Joel Jacobson wrote:
> On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote:
>> I think the function calls should be in the FROM clause, and restrict the
>> pg_shdepend rows to only the ones in the current database:
>
> Cool. I assume pg_ownerships should be changed
On Sun, Oct 20, 2024 at 8:47 PM Alexander Korotkov wrote:
> On Tue, Oct 15, 2024 at 12:50 PM jian he wrote:
> > build from source, DCLOBBER_CACHE_ALWAYS takes a very long time.
> > So I gave up.
> >
> >
> > in lookup_type_cache, we unconditionally do
> > in_progress_list_len++;
> > in_progress_li
On Tue, Oct 15, 2024 at 12:50 PM jian he wrote:
>
> On Tue, Oct 15, 2024 at 4:09 PM Alexander Korotkov
> wrote:
> >
> > Hi, Jian!
> >
> > Thank you for your review.
> >
> > On Tue, Oct 15, 2024 at 10:34 AM jian he
> > wrote:
> > > I don't fully understand all of it. but I did some tests anyway
On Thu, Oct 17, 2024 at 12:41 PM Andrei Lepikhov wrote:
> On 10/15/24 15:08, Alexander Korotkov wrote:
> > Yep, they didn't get updated. Fixed in the attached patchset.
> Let me wear Alexander Lakhin's mask for a moment and say that the code
> may cause a segfault:
>
> #0 0x55e0da186000 in i
Peter Eisentraut writes:
> This no longer works because in C23, because an empty argument list is
> now equivalent to (void), rather than an indeterminate one as before.
> And so this results in an incompatible function pointer type and
> compiler warnings. (gcc and clang agree on this.)
> I
On Sun, Oct 20, 2024, at 12:14, Alvaro Herrera wrote:
> I think the function calls should be in the FROM clause, and restrict the
> pg_shdepend rows to only the ones in the current database:
Cool. I assume pg_ownerships should be changed in the same way?
New patch attached.
> Now, depending on pg
> On 20 Oct 2024, at 15:16, Junwang Zhao wrote:
>
> I'm not sure if I did not express myself correctly, I didn't mean to
> restart the stream,
> I mean we can create a new stream for each outer loop, I attached a
> refactor 0002
> based on your 0001, correct me if I'm wrong.
I really like how
On Mon, Oct 14, 2024 at 3:15 PM Nitin Motiani wrote:
>
> On Sun, Oct 13, 2024 at 6:15 AM Noah Misch wrote:
> >
> > On Sat, Oct 12, 2024 at 06:05:06PM +0530, Nitin Motiani wrote:
> > > 1. In heap_inplace_update_and_unlock, currently both buffer and tuple
> > > are unlocked outside the critical sec
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* in each loop of the outer for?
>
> Thanks for rev
Hello,
On 2024-Oct-20, Joel Jacobson wrote:
> Here is an attempt to revive this patch from 2021-2022, that has been ready
> now
> for a while, thanks to pg_get_acl() function that was committed in
> 4564f1c and d898665.
Nice.
I think the function calls should be in the FROM clause, and restric
On 2024-Oct-20, Peter Eisentraut wrote:
> diff --git a/src/bin/pg_dump/pg_backup_utils.c
> b/src/bin/pg_dump/pg_backup_utils.c
> index a0045cf5e58..80715979a1a 100644
> --- a/src/bin/pg_dump/pg_backup_utils.c
> +++ b/src/bin/pg_dump/pg_backup_utils.c
> @@ -13,7 +13,9 @@
> */
> #include "postgr
On 2024-Oct-20, Peter Eisentraut wrote:
> diff --git a/contrib/tablefunc/tablefunc.h b/contrib/tablefunc/tablefunc.h
> index 2009382ce7d..b78030044b5 100644
> --- a/contrib/tablefunc/tablefunc.h
> +++ b/contrib/tablefunc/tablefunc.h
> @@ -34,6 +34,4 @@
> #ifndef TABLEFUNC_H
> #define TABLEFUNC_H
This is a continuation of [0] ("backend *.c #include cleanup (IWYU)"),
which removed a bunch of unneeded #include's, found by the
include-what-you-use (IWYU) tool. I went through the rest of the code
and did similar cleanups. The patches are organized by code area, but
they are otherwise not
> 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* in each loop of the outer for?
Thanks for reviewing!
AFAIK we cannot restart stream if it's finished, so we have a rac
Commit a67a49648d9 fixed a compiler error under C23. After that, there
is one compiler warning left under C23. It has to do with this in
src/include/nodes/pathnodes.h:
struct IndexOptInfo
{
...
/* AM's cost estimator */
/* Rather than include amapi.h here, we declare amcostestimat
On Sun, Oct 20, 2024 at 11:20:34AM +0800, Junwang Zhao wrote:
> /*
> * 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.
Yes, you are right. This reads better without
32 matches
Mail list logo
