At the end of SetupLockInTable(), there is a check for the "lock already
held" error.
Because the nRequested and requested[lockmode] value of a lock is bumped
before "lock already held" error, and there is no way to reduce them later
for
this situation, then it will keep the inconsistency in lock s
Hi,
On Wed, 11 Sept 2024 at 01:38, Noah Misch wrote:
>
> On Tue, Sep 10, 2024 at 02:35:46PM +0300, Nazir Bilal Yavuz wrote:
> > Your patch is correct. I wrongly assumed it would catch blockno bug,
> > the attached version catches it. I made blockno = 0 invisible and not
> > frozen before copying
On Mon, Sep 02, 2024 at 10:11:43AM +0900, Michael Paquier wrote:
> I need to spend a bit more time with my head down for this thread, but
> couldn't we use these commands with various query patterns in
> pg_stat_statements and look at the shmem counters reported through its
> view?
My apologies fo
On Wednesday, September 11, 2024 1:03 PM shveta malik
wrote:
>
> On Wed, Sep 11, 2024 at 10:15 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Wednesday, September 11, 2024 12:18 PM shveta malik
> wrote:
> > >
> > > ~~
> > >
> > > Another query is about 3 node setup. I couldn't figure out what
> >
On Wed, Sep 11, 2024 at 10:15 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Wednesday, September 11, 2024 12:18 PM shveta malik
> wrote:
> >
> > On Tue, Sep 10, 2024 at 4:30 PM Zhijie Hou (Fujitsu)
> >
> > wrote:
> > >
> > > On Tuesday, September 10, 2024 5:56 PM shveta malik
> > wrote:
> > > >
> > >
On Tue, Sep 10, 2024 at 8:56 PM Bertrand Drouvot
wrote:
>
> On Mon, Sep 09, 2024 at 04:24:09PM +0530, Amit Kapila wrote:
> > On Fri, Aug 30, 2024 at 5:18 PM Bertrand Drouvot
> > wrote:
> > > as we decided not to expose the SnapBuildOnDisk and SnapBuild structs to
> > > public
> > > and to create
On Wednesday, September 11, 2024 12:18 PM shveta malik
wrote:
>
> On Tue, Sep 10, 2024 at 4:30 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Tuesday, September 10, 2024 5:56 PM shveta malik
> wrote:
> > >
> > > Thanks for the example. Can you please review below and let me know
> > > if my under
On Tue, Sep 10, 2024 at 2:16 PM Amit Kapila wrote:
>
> On Tue, Sep 10, 2024 at 11:36 AM vignesh C wrote:
> >
> > On Mon, 9 Sept 2024 at 13:12, Amit Kapila wrote:
> > >
> > > The second part of the assertion is incomplete. The
> > > IsIndexUsableForReplicaIdentityFull() should be used only when t
On Tue, Sep 10, 2024 at 4:30 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Tuesday, September 10, 2024 5:56 PM shveta malik
> wrote:
> >
> > On Tue, Sep 10, 2024 at 1:40 PM Zhijie Hou (Fujitsu)
> >
> > wrote:
> > >
> > > On Tuesday, September 10, 2024 2:45 PM shveta malik
> > wrote:
> > > >
> > > > T
In some cases, we may want to transfer a HAVING clause into WHERE in
hopes of eliminating tuples before aggregation instead of after.
Previously, we couldn't do this if there were any nonempty grouping
sets, because we didn't have a way to tell if the HAVING clause
referenced any columns that were
Here are a some more review comments for patch v30-0001.
==
src/sgml/ref/create_publication.sgml
1.
+
+ If the publisher-side column is also a generated column
then this option
+ has no effect; the publisher column will be filled as normal with the
+ publis
On Tue, Sep 10, 2024 at 11:24 PM Bharath Rupireddy
wrote:
>
>
> Please find the attached v2 patch also having Shveta's review comments
> addressed.
The v2 patch looks good to me.
thanks
Shveta
On Mon, Sep 09, 2024 at 06:20:01PM -0500, Sami Imseih wrote:
> On 14/8/2024 23:05, Imseih (AWS), Sami wrote:
>> Also, while writing the test, I found out that now, JumbleQuery takes
>> into account constants of the A_Const node, and calls of the same
>> prepared statement with different parameter
On Tuesday, September 10, 2024 7:25 PM Amit Kapila
wrote:
>
> On Thu, Sep 5, 2024 at 5:07 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > ---
> > ISSUES and SOLUTION
> > ---
> >
> > To detect update_deleted conflicts, we need to search for dead tuples
> > in the table. However, dead tuples can be remo
Richard Guo 于2024年8月21日周三 15:11写道：
> On Fri, Aug 16, 2024 at 4:14 PM Richard Guo
> wrote:
> > I had a self-review of this patchset and made some refactoring,
> > especially to the function that creates the RelAggInfo structure for a
> > given relation. While there were no major changes, the cod
On Wed, Sep 11, 2024 at 3:54 AM Bharath Rupireddy
wrote:
>
> Hi,
>
> Thanks for reviewing.
>
> On Tue, Sep 10, 2024 at 8:40 AM Peter Smith wrote:
> >
> > Commit message
> >
> > 1.
> > ALTER_REPLICATION_SLOT on invalidated replication slots is unnecessary
> > as there is no way...
> >
> > suggesti
Andy Fan writes:
> Just to be clearer, I'd like work on the out function only due to my
> internal assignment. (Since David planned it for PG18, so it is better
> say things clearer eariler). I'd put parts of out(print) function
> refactor in the next 2 days. I think it deserves a double check bef
On Wed, Sep 11, 2024 at 2:18 AM Alvaro Herrera wrote:
>
> Hello, here's a v2 of this patch. I have fixed --I think-- all the
> issues you and Tender Wang reported (unless I declined a fix in some
> previous email).
>
+ /*
+ * The constraint must appear as inherited in children, so create a
+ * m
Hello David & Andreas,
> On 8/29/24 1:51 PM, David Rowley wrote:
>> I had planned to work on this for PG18, but I'd be happy for some
>> assistance if you're willing.
>
> I am interested in working on this, unless Andy Fan wants to do this
> work. :) I believe that optimizing the out, in and se
On Mon, Sep 02, 2024 at 09:20:21PM +1200, Thomas Munro wrote:
> 2. If a Windows client tries to send() and gets an ECONNRESET/EPIPE
> error, then the network stack seems to drop already received data, so
> a following recv() will never see it. In other words, it depends on
> whether the applicati
On Tue, Sep 10, 2024 at 02:35:46PM +0300, Nazir Bilal Yavuz wrote:
> Your patch is correct. I wrongly assumed it would catch blockno bug,
> the attached version catches it. I made blockno = 0 invisible and not
> frozen before copying the vm file. So, in the blockno buggy version;
> callback will sk
Hi,
On 2024-09-10 13:33:36 -0400, Robert Haas wrote:
> On Tue, Sep 10, 2024 at 12:59 PM Andres Freund wrote:
> > I still think that we'd be better off to just return an error to the client
> > in
> > postmaster, rather than deal with this dead-end children mess. That was
> > perhaps justified at
On Tue, Sep 10, 2024 at 01:58:50PM -0700, Noah Misch wrote:
> On Tue, Sep 10, 2024 at 02:51:23PM -0400, Robert Haas wrote:
>> I think unique names are a good idea. If a user doesn't care about the
>> difference between sdgjsA and sdjgsB, they can easily ignore the
>> trailing suffix, and IME, peopl
On Tue, Sep 10, 2024 at 10:44:42AM +0200, Daniel Gustafsson wrote:
> This change will be committed together with the TLSv1.3 cipher suite pathcset,
> just wanted to bring it up here and not hide it in another thread.
As you wish ;)
--
Michael
signature.asc
Description: PGP signature
On Tue, Sep 10, 2024 at 05:56:47PM -0400, Tom Lane wrote:
> Masahiko Sawada writes:
> > On Tue, Sep 10, 2024 at 11:57 AM Tom Lane wrote:
> >> Yeah, that seems like it could work. But are we sure that replicas
> >> get a copy of the primary's control file rather than creating their
> >> own?
>
>
Masahiko Sawada writes:
> On Tue, Sep 10, 2024 at 11:57 AM Tom Lane wrote:
>> Yeah, that seems like it could work. But are we sure that replicas
>> get a copy of the primary's control file rather than creating their
>> own?
> Yes, I think so. Since at least the system identifiers of primary and
On Tue, Sep 10, 2024 at 11:57 AM Tom Lane wrote:
>
> Masahiko Sawada writes:
> > An alternative way would be that we store the char signedness in the
> > control file, and gin_trgm_ops opclass reads it if the bytes in the
> > meta page shows 'unset'. The char signedness in the control file
> > do
On Wed, 11 Sept 2024 at 03:12, Nathan Bossart wrote:
>
> On Tue, Sep 10, 2024 at 10:16:34AM +1200, David Rowley wrote:
> > If we get the skip scan feature for PG18, then there's likely going to
> > be lots of people with indexes that they might want to consider
> > removing after upgrading. Maybe
Hi Shveta,
On Sun, Sep 8, 2024 at 11:16 PM shveta malik wrote:
>
> I was trying to have a look at the patch again, it doesn't apply on
> the head, needs rebase.
>
Rebased with the latest changes.
> Regarding 'mode = SyncRepWaitMode', FWIW, SyncRepWaitForLSN() also
> does in a similar way. It g
On Tue, Sep 10, 2024 at 02:51:23PM -0400, Robert Haas wrote:
> On Tue, Sep 10, 2024 at 1:27 PM Noah Misch wrote:
> > On Tue, Sep 10, 2024 at 02:29:57PM +0900, Michael Paquier wrote:
> > > You are adding twelve event points with only 5
> > > new wait names. Couldn't it be better to have a one-one
On 2024-09-09 Mo 3:54 PM, Andrew Dunstan wrote:
On 2024-09-09 Mo 1:19 PM, Robert Haas wrote:
On Mon, Sep 9, 2024 at 1:03 PM Andrew Dunstan
wrote:
I guess I could try to write code to migrate everything, but it
would be
somewhat fragile. And what would we do if we ever decided to migrate
"m
On Sep 10, 2024, at 16:17, Tom Lane wrote:
> Not as things stand. If we adopt Peter's nearby position that
> the current behavior is actually buggy, then probably back-patching
> a corrected version would be worthwhile as a part of fixing it.
Oh, I see now that my reply to him points out the sa
On Sep 10, 2024, at 16:10, Peter Eisentraut wrote:
> These JSON path functions are specified by the SQL standard, so they
> shouldn't depend on PostgreSQL-specific settings. At least in new
> functionality we should avoid that, no?
Does that also apply to `datetime(template)`, where it uses t
David Rowley writes:
> On Wed, 11 Sept 2024 at 03:06, Tom Lane wrote:
>> We could accomplish what you suggest by re-ordering the calls so that
>> we build the hash table before enlarging the array. 0001 attached
>> is the same as before (modulo line number changes from being rebased
>> up to HEA
On Wed, 11 Sept 2024 at 03:06, Tom Lane wrote:
> We could accomplish what you suggest by re-ordering the calls so that
> we build the hash table before enlarging the array. 0001 attached
> is the same as before (modulo line number changes from being rebased
> up to HEAD) and then 0002 implements
Jim Jones writes:
> [ xmlserialize patches ]
Pushed with minor editorialization. Notably, I got rid of scribbling
on xmlBufferContent's buffer --- I don't know how likely that is to
upset libxml2, but it seems like a fairly bad idea given that they
declare the result as "const xmlChar*". Castin
"David E. Wheeler" writes:
> On Sep 10, 2024, at 14:51, Tom Lane wrote:
>> Pushed with a little additional polishing.
> Thank you! Do you think it’d be worthwhile to back port to 17?
Not as things stand. If we adopt Peter's nearby position that
the current behavior is actually buggy, then prob
Peter Eisentraut writes:
> These JSON path functions are specified by the SQL standard, so they
> shouldn't depend on PostgreSQL-specific settings. At least in new
> functionality we should avoid that, no?
Hmm ... but does the standard precisely define the output format?
Since these conversio
On 10.09.24 10:00, Amit Langote wrote:
Sorry for missing this report and thanks Andrew for the offlist heads up.
On Wed, Sep 4, 2024 at 7:16 PM Peter Eisentraut wrote:
On 28.08.24 11:21, Peter Eisentraut wrote:
These are ok:
select json_query('{"a": 1, "b": 42}'::jsonb, 'lax $.b' without wra
Isn't this behavior actually a bug that should be fixed rather than
documented?
These JSON path functions are specified by the SQL standard, so they
shouldn't depend on PostgreSQL-specific settings. At least in new
functionality we should avoid that, no?
On 10.09.24 21:43, David E. Wheeler
On 9/5/24 06:06, Junwang Zhao wrote:
>
> ...
>
> I found two other places called json_unique_check_key.
>
> One is *json_build_object_worker*, and the usage is the same as
> *json_object_agg_transfn_worker*, I fix that the same way, PSA
>
> The following sql should trigger the problem, I haven'
On Sep 10, 2024, at 14:51, Tom Lane wrote:
> Pushed with a little additional polishing.
Thank you! Do you think it’d be worthwhile to back port to 17?
> I thought the best way to address jian's complaint about DateStyle not
> being clearly locked down was to change horology.sql to verify the
>
On Tue, Sep 10, 2024 at 8:51 AM Daniel Gustafsson wrote:
> Since there doesn't seem to be much interest in going all the way to Markdown,
Just for the record, I suspect going to Markdown is actually the right
thing to do. I am personally unenthusiastic about it because I need
one more thing to wo
Masahiko Sawada writes:
> An alternative way would be that we store the char signedness in the
> control file, and gin_trgm_ops opclass reads it if the bytes in the
> meta page shows 'unset'. The char signedness in the control file
> doesn't mean to be used for the compatibility check for physical
"David E. Wheeler" writes:
> Rebase on 47c9803. I also changed the commitfest item[1] to “ready for
> committer”, since jian reviewed it, though I couldn’t see a way to add jian
> as a reviewer in the app. Hope that makes sense.
Pushed with a little additional polishing.
I thought the best way
On Tue, Sep 10, 2024 at 1:27 PM Noah Misch wrote:
> On Tue, Sep 10, 2024 at 02:29:57PM +0900, Michael Paquier wrote:
> > You are adding twelve event points with only 5
> > new wait names. Couldn't it be better to have a one-one mapping
> > instead, adding twelve entries in wait_event_names.txt?
>
On Sun, Sep 8, 2024 at 1:08 PM Lars Kanis wrote:
> I'm the maintainer of ruby-pg the ruby interface to the PostgreSQL
> database. This binding uses the asynchronous API of libpq by default to
> facilitate the ruby IO wait and scheduling mechanisms.
>
> This works well with the vanilla postgresql s
On Mon, Sep 9, 2024 at 11:25 PM Tom Lane wrote:
>
> Masahiko Sawada writes:
> > On Mon, Sep 9, 2024 at 4:42 PM Tom Lane wrote:
> >> Do you have an idea for how we'd get
> >> this to happen during pg_upgrade, exactly?
>
> > What I was thinking is that we have "pg_dump --binary-upgrade" emit a
> >
> On 10 Sep 2024, at 17:37, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Since there doesn't seem to be much interest in going all the way to
>> Markdown,
>> the attached 0001 is just the formatting changes for achieving (to some
>> degree)
>> consistency among the README's. This mostly b
Hi,
Thanks for reviewing.
On Tue, Sep 10, 2024 at 8:40 AM Peter Smith wrote:
>
> Commit message
>
> 1.
> ALTER_REPLICATION_SLOT on invalidated replication slots is unnecessary
> as there is no way...
>
> suggestion:
> ALTER_REPLICATION_SLOT for invalid replication slots should not be
> allowed b
Hi,
On 2024-08-12 12:55:00 +0300, Heikki Linnakangas wrote:
> @@ -2864,6 +2777,8 @@ PostmasterStateMachine(void)
>*/
> if (pmState == PM_STOP_BACKENDS)
> {
> + uint32 targetMask;
> +
> /*
>* Forget any pending requests for back
Jim Jones writes:
> This patch introduces the CANONICAL option to xmlserialize, which
> serializes xml documents in their canonical form - as described in
> the W3C Canonical XML Version 1.1 specification. This option can
> be used with the additional parameter WITH [NO] COMMENTS to keep
> or remo
On Tue, Sep 10, 2024 at 12:59 PM Andres Freund wrote:
> I still think that we'd be better off to just return an error to the client in
> postmaster, rather than deal with this dead-end children mess. That was
> perhaps justified at some point, but now it seems to add way more complexity
> than it'
On Tue, Sep 10, 2024 at 02:29:57PM +0900, Michael Paquier wrote:
> You are adding twelve event points with only 5
> new wait names. Couldn't it be better to have a one-one mapping
> instead, adding twelve entries in wait_event_names.txt?
No, I think the patch's level of detail is better. One sho
+ pg_log_error("pg_waldump cannot read from a tar");
"tar" isn't normally used as a noun as you do here, so I think this
should say "pg_waldump cannot read tar files".
Technically, the position of this check could lead to an unnecessary
failure, if -n wasn't specified but pg
On Thu, Sep 5, 2024 at 11:12 AM Thomas Munro wrote:
> On Thu, Sep 5, 2024 at 6:45 PM Mats Kindahl wrote:
> > Forgive me for asking, but I am not entirely sure why the ReadStream
> struct is opaque. The usual reasons are:
> >
> > You want to provide an ABI to allow extensions to work with new maj
Hi,
On 2024-09-06 16:13:43 +0300, Heikki Linnakangas wrote:
> On 04/09/2024 17:35, Andres Freund wrote:
> > On 2024-08-12 12:55:00 +0300, Heikki Linnakangas wrote:
> > > From dc53f89edbeec99f8633def8aa5f47cd98e7a150 Mon Sep 17 00:00:00 2001
> > > From: Heikki Linnakangas
> > > Date: Mon, 12 Aug
On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio wrote:
>
> On Tue, 10 Sept 2024 at 04:47, Bruce Momjian wrote:
> > Yes. There are so many changes at the source code level it is unwise to
> > try and get them into the main release notes. If someone wants to
> > create an addendum, like was sug
I looked at the patch set and found it quite useful.
The first 7 patches are just refactoring and may be committed separately if
needed.
There were minor problems: patch #5 don't want to apply clearly and the #8
is complained
about partitionLock is unused if we build without asserts. So, I add a
P
On 2024-Sep-10, Jim Jones wrote:
> Is \conninfo+ no longer supposed to return the results in tabular form?
> At least it wasn't the case till v28.
I suspect the reason it's no longer a table is that it was previously a
query (which is easily printed as a table by calling printQuery) and now
it's
On 10.09.24 06:32, Hunaid Sohail wrote:
>
> I have attached a rebased patch.
Thanks.
Is \conninfo+ no longer supposed to return the results in tabular form?
At least it wasn't the case till v28.
$ /usr/local/postgres-dev/bin/psql -d postgres -h 0 -c "\conninfo+"
You are connected to database
Daniel Gustafsson writes:
> Since there doesn't seem to be much interest in going all the way to Markdown,
> the attached 0001 is just the formatting changes for achieving (to some
> degree)
> consistency among the README's. This mostly boils down to using a consistent
> amount of whitespace aro
Hi,
On Mon, Sep 09, 2024 at 04:24:09PM +0530, Amit Kapila wrote:
> On Fri, Aug 30, 2024 at 5:18 PM Bertrand Drouvot
> wrote:
> > as we decided not to expose the SnapBuildOnDisk and SnapBuild structs to
> > public
> > and to create/expose 2 new functions in snapbuild.c then the functions in
> >
On Tue, Sep 10, 2024 at 4:39 AM Daniel Gustafsson wrote:
> Pushed, thanks!
Thank you!
--Jacob
On Tue, Sep 10, 2024 at 10:16:34AM +1200, David Rowley wrote:
> I think the primary use case here is to assist in dropping useless
> indexes in a way that can very quickly be undone if the index is more
> useful than thought. If you didn't keep the index up-to-date then that
> would make the featur
David Rowley writes:
> On Tue, 30 Jul 2024 at 10:14, Tom Lane wrote:
>> On my development machine, it takes over 14 minutes to pg_upgrade
>> this, and it turns out that that time is largely spent in column
>> name de-duplication while deparsing the CHECK constraints. The
>> attached patch reduce
On Tue, Sep 3, 2024 at 11:50 AM Nathan Bossart
wrote:
> Do you think these acronyms make it difficult for some to contribute to
> Postgres? I've always felt that they were pretty easy to figure out and a
> nice way to save some typing for common phrases, but I'm not sure it's ever
> really been
On 8/23/24 14:50, Tomas Vondra wrote:
>
> On 8/23/24 14:00, Peter Eisentraut wrote:
>> On 30.06.24 20:58, Tomas Vondra wrote:
>>> I've pushed the first three patches, fixing the headers, adding the
>>> --copy option and PG_TEST_PG_COMBINEBACKUP_MODE variable.
>>>
>>> I haven't pushed the CI change
On 2024-Sep-02, Tender Wang wrote:
> The attached patch adds List *nnconstraints, which store the not-null
> definition, in struct CreateStmt. This makes me a little confused
> about List *constraints in struct CreateStmt. Actually, the List
> constraints store ckeck constraint, and it will be b
On 2024-Sep-09, jian he wrote:
> bold idea. print out the constraint name: violates not-null constraint \"%s\"
> for the following code:
> ereport(ERROR,
> (errcode(ERRCODE_NOT_NULL_VIOLATION),
> errmsg("null value in column \"%s\" o
Hello,
Thank you for the detailed information and feedback David. Comments inline.
P.S Re-sending it to the mailing list, because I accidentally didn't select
reply-all on the last reply.
On Mon, Sep 9, 2024 at 6:16 PM David Rowley wrote:
> On Tue, 10 Sept 2024 at 09:39, Shayon Mukherjee wrot
I see following issue with the latest patch,
relnode.c:2122:32: error: use of undeclared identifier 'ojrelids'
RINFO_IS_PUSHED_DOWN(rinfo, ojrelids,
joinrel->relids))
On Thu, 18 Apr 2024 at 09:34, Richard Guo wrote:
> Here is another rebase over 3af7040985. Nothing else
+1 for the new flag as well, since it'd be nice to be able to
enable/disable indexes without having to worry about the missed updates /
having to rebuild it.
Shayon
On Tue, Sep 10, 2024 at 8:02 AM David Rowley wrote:
> On Tue, 10 Sept 2024 at 22:46, Michael Banck wrote:
> > How about the indisl
On 2024-09-09 16:56, Michael Harris wrote:
Thanks for updating the patch.
Here is a minor comment.
@@ -944,20 +948,32 @@ expand_vacuum_rel(VacuumRelation *vrel,
MemoryContext vac_context,
MemoryContextSwitchTo(oldcontext);
}
..
+* Unless the user has specified ONLY,
On Tue, 10 Sept 2024 at 22:46, Michael Banck wrote:
> How about the indislive flag instead? I haven't looked at the code, but
> from the documentation ("If false, the index is in process of being
> dropped, and
> should be ignored for all purposes") it sounds like we made be able to
> piggy-back o
> On 9 Sep 2024, at 23:21, Daniel Gustafsson wrote:
>
>> On 9 Sep 2024, at 20:41, Jacob Champion
>> wrote:
>>
>> On Mon, Sep 9, 2024 at 11:30 AM Daniel Gustafsson wrote:
>>> Just to make sure I understand, this is for guarding against overreads in
>>> validation of strings containing torn MB
Hi,
On Tue, 10 Sept 2024 at 00:32, Noah Misch wrote:
>
> Copying the vm file is a good technique. In my test runs, this does catch the
> "never detect" bug, but it doesn't catch the blkno bug. Can you make it catch
> both? It's possible my hand-patching to recreate the blkno bug is what went
>
On Thu, Sep 5, 2024 at 5:07 PM Zhijie Hou (Fujitsu)
wrote:
>
> ---
> ISSUES and SOLUTION
> ---
>
> To detect update_deleted conflicts, we need to search for dead tuples in the
> table. However, dead tuples can be removed by VACUUM at any time. Therefore,
> to
> ensure consistent and accurate conf
On Tuesday, September 10, 2024 5:56 PM shveta malik
wrote:
>
> On Tue, Sep 10, 2024 at 1:40 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Tuesday, September 10, 2024 2:45 PM shveta malik
> wrote:
> > >
> > > Thank You Hou-San for explaining the design. But to make it easier
> > > to understand,
Hi,
On Tue, Sep 10, 2024 at 10:16:34AM +1200, David Rowley wrote:
> On Tue, 10 Sept 2024 at 09:39, Shayon Mukherjee wrote:
> > Adding and removing indexes is a common operation in PostgreSQL. On
> > larger databases, however, these operations can be
> > resource-intensive. When evaluating the per
On Mon, Sep 9, 2024 at 7:20 PM Robert Haas wrote:
> On Mon, Sep 9, 2024 at 1:03 PM Andrew Dunstan wrote:
> > I guess I could try to write code to migrate everything, but it would be
> > somewhat fragile. And what would we do if we ever decided to migrate
> > "master" to another name like "main"?
Hi Shayon
Thank you for your work on this , I think it's great to have this
feature implemented ,I checked the doucment on other databases,It seems
both MySQL 8.0 and oracle supports it, sql server need to rebuild indexes
after disabled,It seems disable the index, it's equivalent to deletin
On Tue, 30 Jul 2024 at 10:14, Tom Lane wrote:
> -
> for (my $i = 0; $i < 100; $i++)
> {
> print "CREATE TABLE test_inh_check$i (\n";
> for (my $j = 0; $j < 1000; $j++)
> {
> print "a$j float check (a$j > 10.2),\n";
> }
> print "b float);\
On Tue, Sep 10, 2024 at 1:40 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Tuesday, September 10, 2024 2:45 PM shveta malik
> wrote:
> > > ---
> > > THE DESIGN
> > > ---
> > >
> > > To achieve the above, we plan to allow the logical walsender to
> > > maintain and advance the slot.xmin to protect the da
> On 22 Jul 2024, at 23:25, Andreas Karlsson wrote:
>
> I have bench marked the two patches now and failed to measure any speedup or
> slowdown from the first patch (removing return) but I think it is a good idea
> anyway.
>
> For the second patch (optimize strict) I managed to measure a ~1% s
On 2024-Sep-10, Jelte Fennema-Nio wrote:
> I think as an extension author there are usually three types of
> changes that are relevant:
>
> 1. New APIs/hooks that are meant for extension authors
> For 1, I think adding them to the release notes makes total sense,
> especially if the new APIs are
On Thu, Sep 5, 2024 at 4:04 PM Amit Kapila wrote:
>
> On Mon, Sep 2, 2024 at 9:19 PM Nitin Motiani wrote:
> >
> > I think that the partial data replication for one table is a bigger
> > issue than the case of data being sent for a subset of the tables in
> > the transaction. This can lead to inco
On Tue, Sep 10, 2024 at 11:36 AM vignesh C wrote:
>
> On Mon, 9 Sept 2024 at 13:12, Amit Kapila wrote:
> >
> > The second part of the assertion is incomplete. The
> > IsIndexUsableForReplicaIdentityFull() should be used only when the
> > remote relation has REPLICA_IDENTITY_FULL set. I haven't te
On Mon, 9 Sep 2024 22:59:34 +0900
Fujii Masao wrote:
>
>
> On 2024/07/02 16:34, Yugo NAGATA wrote:
> > So, I would like to propose to add
> > has_large_object_function for checking if a user has the privilege on a
> > large
> > object.
>
> +1
Thank you for your looking into this!
I've attach
> On 10 Sep 2024, at 00:53, Michael Paquier wrote:
>
> On Mon, Sep 09, 2024 at 11:29:09PM +0200, Daniel Gustafsson wrote:
>> Agreed. OpenSSL 1.1.1 is very different story and I suspect we'll be stuck
>> on
>> that level for some time, but 1.1.0 is gone from production use.
>
> The cleanup indu
IIUC, previously there was a subscriber side option
'include_generated_columns', but now since v30* there is a publisher
side option 'publish_generated_columns'.
Fair enough, but in the v30* patches I can still see remnants of the
old name 'include_generated_columns' all over the place:
- in the c
> On 10 Sep 2024, at 10:01, Peter Eisentraut wrote:
>> And pushed. All BF owners with animals using 1.0.2 have been notified but
>> not
>> all have been updated (or modified to skip SSL) so there will be some
>> failing.
>
> A small follow-up for this: With the current minimum OpenSSL versio
On Tuesday, September 10, 2024 2:45 PM shveta malik
wrote:
> > ---
> > THE DESIGN
> > ---
> >
> > To achieve the above, we plan to allow the logical walsender to
> > maintain and advance the slot.xmin to protect the data in the user
> > table and introduce a new logical standby feedback message.
On 03.09.24 19:26, Mark Dilger wrote:
On Sep 3, 2024, at 9:52 AM, Peter Eisentraut wrote:
Here is a cleaned-up version of the v17-0004 patch. I have applied the
renaming discussed above. I have also made a wrapper function
btgettreeheight() that calls _bt_getrootheight(). That way, if we e
On 02.09.24 14:26, Daniel Gustafsson wrote:
On 2 Sep 2024, at 10:03, Daniel Gustafsson wrote:
On 23 Aug 2024, at 01:56, Michael Paquier wrote:
On Thu, Aug 22, 2024 at 11:13:15PM +0200, Daniel Gustafsson wrote:
On 22 Aug 2024, at 02:31, Michael Paquier wrote:
Just do it :)
That's my plan
Sorry for missing this report and thanks Andrew for the offlist heads up.
On Wed, Sep 4, 2024 at 7:16 PM Peter Eisentraut wrote:
> On 28.08.24 11:21, Peter Eisentraut wrote:
> > These are ok:
> >
> > select json_query('{"a": 1, "b": 42}'::jsonb, 'lax $.b' without wrapper);
> > json_query
> > --
On Wed, Sep 4, 2024 at 3:54 PM Michael Paquier wrote:
>
...
> 0001 and 0004 have been applied with these tweaks. I am still not
> sure about the changes for DateStyle and IntervalStyle in 0002 and
> 0003. Perhaps others have an opinion that could drive to a consensus.
>
Thanks for pushing the p
On Thu, Sep 05, 2024 at 09:51:25PM -0400, Bruce Momjian wrote:
> On Tue, Sep 3, 2024 at 10:44:01AM -0500, Nathan Bossart wrote:
> > While freely acknowledging that I am biased because I wrote it, I am a bit
> > surprised to see the DSM registry left out of the release notes (commit
> > 8b2bcf3, do
98 matches
Mail list logo
