Minor style fix; sorry for the spam.
v9-0001-Refactor-GetLockConflicts-into-more-general-GetLo.patch
Description: Binary data
v9-0002-Allow-specifying-single-lockmode-in-WaitForLocker.patch
Description: Binary data
v9-0003-Add-pg_wait_for_lockers-function.patch
Description: Binary data
On Mon, Jan 29, 2024 at 14:50 Amit Kapila wrote:
> Pushed!
Thanks for pushing.
Regards,
Wang Wei
Thank you fixing the issue.
At Tue, 23 Jan 2024 11:43:43 +0200, Heikki Linnakangas wrote i
n
> There's an existing AmWalReceiverProcess() macro too. Let's use that.
Mmm. I sought an Is* function becuase "IsLogicalWorker()" is placed on
the previous line. Our convention regarding those
On Fri, Jan 26, 2024 at 11:05 PM Masahiko Sawada wrote:
>
> On Wed, Jan 24, 2024 at 3:42 PM John Naylor wrote:
> >
> > On Tue, Jan 23, 2024 at 10:58 AM Masahiko Sawada
> > wrote:
> > >
> > > The new patches probably need to be polished but the VacDeadItemInfo
> > > idea looks good to me.
> >
>
On Wed, Jan 17, 2024 at 10:57 PM Bharath Rupireddy
wrote:
>
> Thank you. I'm attaching v8 patch-set here which includes use of new
> insert TAMs for COPY FROM. With this, postgres not only will have the
> new TAM for inserts, but they also can make the following commands
> faster - CREATE TABLE
On Mon, Jan 29, 2024 at 2:03 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Sat, 27 Jan 2024 14:15:02 +0800,
> Junwang Zhao wrote:
>
> > I have been working on a *COPY TO JSON* extension since yesterday,
> > which is
On Sun, 28 Jan 2024 19:14:58 -0700
"David G. Johnston" wrote:
> > Also, I think "invalid input syntax" is a bit ambiguous. For example,
> > COPY FROM raises an error when the number of input column does not match
> > to the table schema, but this error is not ignored by ON_ERROR while
> > this
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sat, 27 Jan 2024 14:15:02 +0800,
Junwang Zhao wrote:
> I have been working on a *COPY TO JSON* extension since yesterday,
> which is based on your V6 patch set, I'd like to give you more input
> so you can
On Fri, Jan 26, 2024 at 11:08 PM Alvaro Herrera wrote:
>
> I've continued to review this and decided that I don't like the mess
> this patch proposes in order to support pg_commit_ts's deletion of all
> files. (Yes, I know that I was the one that proposed this idea. It's
> still a bad one). I'd
On Thu, Jan 25, 2024 at 10:03 PM Alvaro Herrera wrote:
>
> On 2024-Jan-25, Alvaro Herrera wrote:
>
> > Here's a touched-up version of this patch.
>
> > diff --git a/src/backend/storage/lmgr/lwlock.c
> > b/src/backend/storage/lmgr/lwlock.c
> > index 98fa6035cc..4a5e05d5e4 100644
> > ---
On Fri, Jan 26, 2024 at 6:47 AM Wei Wang (Fujitsu)
wrote:
>
> It looks good to me. So, I updated the patch as suggested.
>
Pushed!
--
With Regards,
Amit Kapila.
Kyotaro Horiguchi writes:
> Having said that, I'm a bit concerned about the case where an overly
> long string is given there. However, considering that we already have
> "invalid input syntax for type xxx: %x" messages (including for the
> numeric), this concern might be unnecessary.
Yeah, we
On Mon, Jan 29, 2024 at 10:38 AM Zhijie Hou (Fujitsu)
wrote:
>
> I noticed one minor thing that the upgrade doc refers to the old 'conflicting'
> column of pg_replication_slot. As the column has been changed to
> 'conflict_reason',
> I think the doc needs to be updated like the attachment.
>
At Sun, 28 Jan 2024 22:47:02 -0500, Tom Lane
wrote in
Kyotaro Horiguchi writes:
> They seem to be suggesting that PostgreSQL has the types
"decimal" and
> "number". I know of the former, but I don't think PostgreSQL has
the
> latter type. Perhaps the "number" was intended to refer to
Hi,
I noticed one minor thing that the upgrade doc refers to the old 'conflicting'
column of pg_replication_slot. As the column has been changed to
'conflict_reason',
I think the doc needs to be updated like the attachment.
Best Regards,
Hou Zhijie
On Mon, 29 Jan 2024 at 06:34, Peter Smith wrote:
>
> Hi Vignesh,
>
> Here are some review comments for patch v4.
>
> These are cosmetic only; otherwise v4 LGTM.
>
> ==
> doc/src/sgml/ref/pgupgrade.sgml
>
> 1.
> Configure the servers for log shipping. (You do not need to run
>
I guess the output of the deadlock test was unstable, so I simply
removed it in v8 here, but I can try to fix it instead if it seems
important to test that.
v8-0001-Refactor-GetLockConflicts-into-more-general-GetLo.patch
Description: Binary data
v8-0003-Add-pg_wait_for_lockers-function.patch
On Mon, Jan 29, 2024 at 9:21 AM Peter Smith wrote:
>
> Here are some review comments for v70-0001.
>
> ==
> doc/src/sgml/protocol.sgml
>
> 1.
> Related to this, please also review my other patch to the same docs
> page protocol.sgml [1].
>
We can check that separately.
> ==
>
Here are some review comments for v70-0001.
==
doc/src/sgml/protocol.sgml
1.
Related to this, please also review my other patch to the same docs
page protocol.sgml [1].
==
src/backend/replication/logical/tablesync.c
2.
walrcv_create_slot(LogRepWorkerWalRcvConn,
slotname, false
Kyotaro Horiguchi writes:
> I have two possible issues in a recent commit.
> Commit 66ea94e8e6 has introduced the following messages:
>> errmsg("numeric argument of jsonpath item method .%s() is out of range for
>> type decimal or number",
> They seem to be suggesting that PostgreSQL has the
On Mon, Jan 29, 2024 at 11:20 AM vignesh C wrote:
> On Mon, 29 Jan 2024 at 08:01, Richard Guo wrote:
> > On Sat, Jan 27, 2024 at 10:08 AM vignesh C wrote:
> >> I have changed the status of the commitfest entry to "Committed" as I
> >> noticed the patch has already been committed.
> >
> > Well,
Hi,
Here's a quick status report after the fourth week:
Status summary:
status| w1 | w2 | w3| w4
---+---+++--
Needs review: |238 | 213| 181| 147
On Mon, Jan 29, 2024 at 11:22 AM Masahiko Sawada wrote:
>
> On Mon, Jan 29, 2024 at 12:10 PM Junwang Zhao wrote:
> >
> > On Mon, Jan 29, 2024 at 10:42 AM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Jan 26, 2024 at 6:02 PM Junwang Zhao wrote:
> > > >
> > > > On Fri, Jan 26, 2024 at 4:55 PM
On Fri, Jan 26, 2024 at 4:54 AM vignesh C wrote:
>
> CFBot shows that there is one warning as in [1]:
> patching file doc/src/sgml/libpq.sgml
> ...
> [09:30:40.000] [943/2212] Compiling C object
> src/backend/postgres_lib.a.p/storage_lmgr_lock.c.obj
> [09:30:40.000]
On Mon, Jan 29, 2024 at 12:10 PM Junwang Zhao wrote:
>
> On Mon, Jan 29, 2024 at 10:42 AM Masahiko Sawada
> wrote:
> >
> > On Fri, Jan 26, 2024 at 6:02 PM Junwang Zhao wrote:
> > >
> > > On Fri, Jan 26, 2024 at 4:55 PM Sutou Kouhei wrote:
> > > >
> > > > Hi,
> > > >
> > > > In
> > > > "Re:
On Mon, 29 Jan 2024 at 08:01, Richard Guo wrote:
>
>
> On Sat, Jan 27, 2024 at 10:08 AM vignesh C wrote:
>>
>> On Mon, 8 Jan 2024 at 22:21, Tom Lane wrote:
>> >
>> > Richard Guo writes:
>> > > On Sun, Jan 7, 2024 at 6:41 AM Tom Lane wrote:
>> > >> Thanks for the report! I guess we need
In [1] we've reached a conclusion that for a MATERIALIZED CTE it's okay
to 'allow our statistics or guesses for the sub-query to subsequently
influence what the upper planner does'. Commit f7816aec23 exposes
column statistics to the upper planner. In the light of that, here is a
patch that
I have two possible issues in a recent commit.
Commit 66ea94e8e6 has introduced the following messages:
(Aplogizies in advance if the commit is not related to this thread.)
jsonpath_exec.c:1287
> if (numeric_is_nan(num) || numeric_is_inf(num))
> RETURN_ERROR(ereport(ERROR,
>
On Fri, Jan 26, 2024 at 10:44 PM jian he
wrote:
I doubt the following part:
If the log value is specified,
COPY behaves the same as
ignore, exept that
it logs information that should have resulted in errors to
PostgreSQL log at
INFO level.
I think it does something
On Mon, Jan 29, 2024 at 10:42 AM Masahiko Sawada wrote:
>
> On Fri, Jan 26, 2024 at 6:02 PM Junwang Zhao wrote:
> >
> > On Fri, Jan 26, 2024 at 4:55 PM Sutou Kouhei wrote:
> > >
> > > Hi,
> > >
> > > In
> > > "Re: Make COPY format extendable: Extract COPY TO format
> > > implementations" on
On Wed, 13 Sept 2023 at 06:57, bt23nguyent wrote:
>
> Hi,
>
> Currently, the psql's tab completion feature does not support properly
> for ATTACH PARTITION. When key is typed after "ALTER TABLE
> ATTACH PARTITION ", all possible table names should be
> displayed, however, foreign table names
On Fri, Jan 26, 2024 at 6:02 PM Junwang Zhao wrote:
>
> On Fri, Jan 26, 2024 at 4:55 PM Sutou Kouhei wrote:
> >
> > Hi,
> >
> > In
> > "Re: Make COPY format extendable: Extract COPY TO format implementations"
> > on Fri, 26 Jan 2024 16:41:50 +0800,
> > Junwang Zhao wrote:
> >
> > >
On Sat, Jan 27, 2024 at 10:08 AM vignesh C wrote:
> On Mon, 8 Jan 2024 at 22:21, Tom Lane wrote:
> >
> > Richard Guo writes:
> > > On Sun, Jan 7, 2024 at 6:41 AM Tom Lane wrote:
> > >> Thanks for the report! I guess we need something like the attached.
> >
> > > +1.
> >
> > Pushed, thanks
Dear Vignesh,
Thanks for updating the patch! For now, v4 patch LGTM.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
https://www.fujitsu.com/
On Fri, Jan 26, 2024 at 4:04 PM Masahiko Sawada wrote:
>
> On Thu, Jan 25, 2024 at 10:17 PM Aleksander Alekseev
> wrote:
> >
> > Hi,
> >
> > > > Here is the corrected patch.
> > >
> > > Thank you for updating the patch! I have some comments:
> >
> > Thanks for the review.
> >
> > > -
On Sunday, January 28, 2024, Yugo NAGATA wrote:
> On Fri, 26 Jan 2024 08:04:45 -0700
> "David G. Johnston" wrote:
>
> > On Fri, Jan 26, 2024 at 2:30 AM Yugo NAGATA wrote:
> >
> > > On Fri, 26 Jan 2024 00:00:57 -0700
> > > "David G. Johnston" wrote:
> > >
> > > > I will need to make this tweak
On 2024-01-27 00:04, David G. Johnston wrote:
On Fri, Jan 26, 2024 at 2:30 AM Yugo NAGATA
wrote:
On Fri, 26 Jan 2024 00:00:57 -0700
"David G. Johnston" wrote:
I will need to make this tweak and probably a couple others to my
own
suggestions in 12 hours or so.
And here is my v2.
On Fri, 26 Jan 2024 08:04:45 -0700
"David G. Johnston" wrote:
> On Fri, Jan 26, 2024 at 2:30 AM Yugo NAGATA wrote:
>
> > On Fri, 26 Jan 2024 00:00:57 -0700
> > "David G. Johnston" wrote:
> >
> > > I will need to make this tweak and probably a couple others to my own
> > > suggestions in 12
On Fri, Jan 26, 2024, at 4:55 AM, Hayato Kuroda (Fujitsu) wrote:
> Again, thanks for updating the patch! There are my random comments for v9.
Thanks for checking v9. I already incorporated some of the points below into
the next patch. Give me a couple of hours to include some important points.
>
Hi Vignesh,
Here are some review comments for patch v4.
These are cosmetic only; otherwise v4 LGTM.
==
doc/src/sgml/ref/pgupgrade.sgml
1.
Configure the servers for log shipping. (You do not need to run
pg_backup_start() and
pg_backup_stop()
or take a file system
On Sun, Jan 28, 2024 at 4:51 PM jian he wrote:
> On Fri, Jan 26, 2024 at 11:09 PM David G. Johnston
> wrote:
> >
> > Hi,
> >
> > The option choice of "ignore" in the COPY ON_ERROR clause seems overly
> generic. There would seem to be two relevant ways to ignore bad column
> input data - drop
On Fri, Jan 26, 2024 at 12:08:46PM +0900, Michael Paquier wrote:
> Well, I'm OK with this consensus on 1d35f705e if folks think this is
> useful enough for all the stable branches.
I have done that down to REL_15_STABLE for now as this is able to
apply cleanly there. Older branches have a lack
I fixed your tests, some of your tests can be simplified, (mainly
primary key constraint is unnecessary for the failed tests)
also your foreign key patch test table, temporal_rng is created at
line 141, and we use it at around line 320.
it's hard to get the definition of temporal_rng. I drop the
On Fri, Jan 26, 2024 at 11:09 PM David G. Johnston
wrote:
>
> Hi,
>
> The option choice of "ignore" in the COPY ON_ERROR clause seems overly
> generic. There would seem to be two relevant ways to ignore bad column input
> data - drop the entire row or just set the column value to null. I can
On Fri, Jan 19, 2024 at 1:44 AM Dean Rasheed wrote:
>
>
> Thanks for reviewing. Updated patch attached.
>
> The wider question is whether people are happy with the overall
> approach this patch now takes, and the new MERGING() function and
> MergingFunc node.
>
one minor white space issue:
git
On 1/28/24 19:11, Michael Paquier wrote:
On Fri, Jan 26, 2024 at 06:27:30PM +0530, vignesh C wrote:
Please post an updated version for the same.
[1] - http://cfbot.cputube.org/patch_46_3511.log
With the recent introduction of incremental backups that depend on
backup_label and the rather
On Fri, Jan 26, 2024 at 06:27:30PM +0530, vignesh C wrote:
> Please post an updated version for the same.
>
> [1] - http://cfbot.cputube.org/patch_46_3511.log
With the recent introduction of incremental backups that depend on
backup_label and the rather negative feedback received, I think that
On Sun, 28 Jan 2024 at 20:01, Pavel Stehule wrote:
> There is another reason - compatibility with other drivers. We maintain just
> libpq, but there are JDBC, Npgsql, and some native Python drivers. I didn't
> checked, but maybe they expect GUC with GUC_REPORT flag.
This doesn't matter,
On Sun, Jan 28, 2024 at 1:29 PM Pavel Luzanov
wrote:
> I'd suggest pulling out this system view change into its own patch.
>
>
> But within this thread or new one?
>
>
>
Thread. The subject line needs to make clear we are proposing changing a
system view.
The connection limit can be set to 0.
On 23.01.2024 01:59, David G. Johnston wrote:
The attribute names correspond to the keywords of the CREATE ROLE command.
The attributes are listed in the same order as in the documentation.
(I think that the LOGIN attribute should be moved to the first place,
both in the
> On Sun, Jan 28, 2024 at 08:34:40PM +0100, Pavel Stehule wrote:
> > * I've noticed an interesting result when a LET statement is used to
> > assign a
> > value without a subquery:
> >
> > create variable test as text;
> > -- returns NULL
> > select test;
> >
> >
On 23.01.2024 04:18, Tom Lane wrote:
I think expecting the pg_roles view to change for this is problematic.
You can't have that in the back branches, so with this patch psql
will show something different against a pre-17 server than later
versions. At best, that's going to be confusing.
I've
ne 28. 1. 2024 v 19:00 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> Thanks for the update, smaller patches looks promising.
>
> Off the list Pavel has mentioned that the first two patches contain a
> bare minimum for session variables, so I've reviewed them once more and
> suggest
ne 28. 1. 2024 v 10:42 odesílatel Jelte Fennema-Nio
napsal:
> On Sat, 27 Jan 2024 at 20:44, Pavel Stehule
> wrote:
> > client_encoding, standard_conforming_strings, server_version,
> default_transaction_read_only, in_hot_standby and scram_iterations
> > are used by libpq directly, so it can be
> On 28 Jan 2024, at 17:49, Alvaro Herrera wrote:
>
> I'd appreciate it if you or Horiguchi-san can update his patch to remove
> use of usleep in favor of a CV in multixact, and keep this CF entry to
> cover it.
Sure! Sounds great!
> Perhaps a test to make the code reach the usleep(1000) can
Thanks for the update, smaller patches looks promising.
Off the list Pavel has mentioned that the first two patches contain a
bare minimum for session variables, so I've reviewed them once more and
suggest to concentrate on them first. I'm afraid the memory cleanup
patch has to be added to the
On 2024-Jan-27, Andrey Borodin wrote:
> thanks for the ping! Most important parts of this patch set are discussed in
> [0]. If that patchset will be committed, I'll withdraw entry for this thread
> from commitfest.
> There's a version of Multixact-specific optimizations [1], but I hope they
>
By the way, the Go language has also already implemented a function for UUIDv7:
https://pkg.go.dev/github.com/gofrs/uuid#NewV7
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Thursday, 25 January 2024 at 12:49:46 am GMT+3, Sergey Prokhorenko
wrote:
That's right! There is no
On Sun, 28 Jan 2024 at 10:51, Jelte Fennema-Nio wrote:
> Both of those are fixed now.
Okay, there turned out to also be an issue on Windows with
setKeepalivesWin32 not being available in fe-cancel.c. That's fixed
now too (as well as some minor formatting issues).
From
On Sun, 28 Jan 2024 at 04:15, vignesh C wrote:
> CFBot shows that the patch has few compilation errors as in [1]:
> [17:07:07.621] /usr/bin/ld:
> ../../../src/fe_utils/libpgfeutils.a(cancel.o): in function
> `handle_sigint':
> [17:07:07.621] cancel.c:(.text+0x50): undefined reference to
On Sat, 27 Jan 2024 at 20:44, Pavel Stehule wrote:
> client_encoding, standard_conforming_strings, server_version,
> default_transaction_read_only, in_hot_standby and scram_iterations
> are used by libpq directly, so it can be wrong to introduce the possibility
> to break it.
libpq could add
On 26.01.2024 05:37, vignesh C wrote:
On Tue, 24 Oct 2023 at 01:47, Alena Rybakina wrote:
Hi!
I looked through your patch and noticed that it was not applied to the current
version of the master. I rebased it and attached a version. I didn't see any
problems and, honestly, no big changes
Hello Peter,
26.01.2024 16:42, Peter Eisentraut wrote:
I have committed all this. These are great improvements.
Please look at the segmentation fault triggered by the following query since
4d969b2f8:
CREATE TABLE t1(a text COMPRESSION pglz);
CREATE TABLE t2(a text);
CREATE TABLE t3()
63 matches
Mail list logo
