On Friday, March 1, 2024 2:11 PM Masahiko Sawada wrote:
>
> On Fri, Mar 1, 2024 at 12:42 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Friday, March 1, 2024 10:17 AM Zhijie Hou (Fujitsu)
> wrote:
> > >
> > >
> > > Attach the V102 patch set which addressed Amit and Shveta's comments.
> > > Thanks
Hi,
When I think about how to add a test case for v5 version patch, and I want
to test if v5 version patch has memory leak.
This thread [1] provided a way how to repeat the memory leak, so I used it
to test v5 patch. I didn't found memory leak on
v5 patch.
But I found other interesting issue.
Hi,
On Fri, Mar 01, 2024 at 03:22:55PM +1100, Peter Smith wrote:
> Here are some review comments for v102-0001.
>
> ==
> doc/src/sgml/config.sgml
>
> 1.
> +
> +Lists the streaming replication standby server slot names that
> logical
> +WAL sender processes will wait
On Fri, Mar 1, 2024 at 12:08 PM Michael Paquier wrote:
>
> On Thu, Feb 29, 2024 at 12:41:38PM +0100, Peter Eisentraut wrote:
> > On 27.02.24 08:57, Alvaro Herrera wrote:
> >> On 2024-Feb-27, Michael Paquier wrote:
> >>> These would cause compilation failures. Saying that, this is a very
> >>>
I wrote:
> Secondly, I thought about my recent work to skip checking if we first
> need to create a root node, and that has a harmless (for vacuum at
> least) but slightly untidy behavior: When RT_SET is first called, and
> the key is bigger than 255, new nodes will go on top of the root node.
>
Hi,
On Fri, Mar 01, 2024 at 11:02:01AM +0900, Michael Paquier wrote:
> On Thu, Feb 29, 2024 at 06:19:58PM +0500, Andrey M. Borodin wrote:
> > Works fine for me. Thanks!
>
> + "timed out waiting for the backend type to wait for the injection
> point name";
>
> The log should provide
On Fri, Mar 1, 2024 at 9:53 AM Peter Smith wrote:
>
> Here are some review comments for v102-0001.
>
>
> 7.
> + /*
> + * Return false if not all the standbys have caught up to the specified WAL
> + * location.
> + */
> + if (caught_up_slot_num != list_length(standby_slot_names_list))
> + return
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 1 Mar 2024 14:31:38 +0900,
Michael Paquier wrote:
> I guess so. It does not make much of a difference, though. The thing
> is that the dispatch caused by the custom callbacks called for each
> row
Hi,
In <20240222.183948.518018047578925034@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 22 Feb 2024 18:39:48 +0900 (JST),
Sutou Kouhei wrote:
> How about adding "is_csv" to CopyReadline() and
> CopyReadLineText() too?
I tried this
On Fri, Mar 1, 2024 at 5:11 PM Masahiko Sawada wrote:
>
...
> +/*
> + * "*" is not accepted as in that case primary will not be able to
> know
> + * for which all standbys to wait for. Even if we have physical slots
> + * info, there is no way to confirm whether
On Fri, Mar 1, 2024 at 12:42 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, March 1, 2024 10:17 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> >
> > Attach the V102 patch set which addressed Amit and Shveta's comments.
> > Thanks Shveta for helping addressing the comments off-list.
>
> The cfbot
On Fri, Mar 01, 2024 at 11:08:21AM +0530, Amit Kapila wrote:
> I wanted to wait for two or three days to see if any other fixes in
> docs, typos, or cosmetic stuff are reported in this functionality then
> I can combine and push them. However, there is no harm in pushing them
> separately, so if
On Mon, Feb 19, 2024 at 12:06:19PM +0530, Amul Sul wrote:
> Agreed, now they will have an error as _could not read file "": Is
> a directory_. But, IIUC, that what usually happens with the dev version, and
> the extension needs to be updated for compatibility with the newer version for
> the same
On Fri, Mar 1, 2024 at 4:25 AM Michael Paquier wrote:
>
> On Thu, Feb 29, 2024 at 02:42:08PM +0530, Amit Kapila wrote:
> > +1. LGTM as well.
>
> This has been introduced by ddd5f4f54a02, so if you wish to fix it
> yourself, please feel free. If you'd prefer that I take care of it,
> I'm OK to do
On Thu, Feb 22, 2024 at 06:39:48PM +0900, Sutou Kouhei wrote:
> If so, adding the change independently on HEAD makes
> sense. But I don't know why that improves
> performance... Inlining?
I guess so. It does not make much of a difference, though. The thing
is that the dispatch caused by the
On Fri, 1 Mar 2024 at 06:08, Michael Paquier wrote:
> Mostly OK to me. Just note that this comment is incorrect because
> pg_enc2gettext_tbl[] includes elements in the range
> [PG_SJIS,_PG_LAST_ENCODING_[ ;)
fixed
From 0d66d374697eff2b276b667ce24cf4599432dbd5 Mon Sep 17 00:00:00 2001
From:
On Fri, 1 Mar 2024 at 06:15, Michael Paquier wrote:
>
> On Fri, Mar 01, 2024 at 05:43:25AM +0100, Jelte Fennema-Nio wrote:
> > I think we should set the AM OID explicitly. Because an important
> > thing to consider is: What behaviour makes sense when later
> > default_table_access_method is
This is a preliminary review. I'll look at this more closely soon.
On Thu, 29 Feb 2024 at 22:26, Heikki Linnakangas wrote:
> If the client requests the "_pq_.extended_query_cancel" protocol
> feature, the server will generate a longer 256-bit cancellation key.
Huge +1 for this general idea.
On Fri, Mar 01, 2024 at 05:43:25AM +0100, Jelte Fennema-Nio wrote:
> I think we should set the AM OID explicitly. Because an important
> thing to consider is: What behaviour makes sense when later
> default_table_access_method is changed?
> I think if someone sets it explicitly on the partitioned
On Fri, Mar 01, 2024 at 05:34:05AM +0100, Jelte Fennema-Nio wrote:
> diff --git a/src/include/mb/pg_wchar.h b/src/include/mb/pg_wchar.h
> index fd91aefbcb7..32e25a1a6ea 100644
> --- a/src/include/mb/pg_wchar.h
> +++ b/src/include/mb/pg_wchar.h
> @@ -225,7 +225,8 @@ typedef unsigned int pg_wchar;
On Fri, Mar 01, 2024 at 05:43:25AM +0100, Jelte Fennema-Nio wrote:
> I think we should set the AM OID explicitly. Because an important
> thing to consider is: What behaviour makes sense when later
> default_table_access_method is changed?
Per the latest discussion of the thread, we've kind of
On Wed, Feb 28, 2024 at 12:10:00PM +0530, Bharath Rupireddy wrote:
> On Mon, Feb 26, 2024 at 5:47 PM torikoshia wrote:
>> + if (cstate->opts.on_error != COPY_ON_ERROR_STOP)
>> + {
>> + ereport(NOTICE,
>>
>> I think cstate->opts.on_error is not
On Fri, 1 Mar 2024 at 02:57, Michael Paquier wrote:
> When it comes to partitioned tables, there is a still a tricky case:
> what should we do when a user specifies a non-default value in the SET
> ACCESS METHOD clause and it matches default_table_access_method?
> Should the relam be 0 or should
On Fri, 1 Mar 2024 at 05:12, Michael Paquier wrote:
> Shouldn't PG_MULE_INTERNAL point to NULL in pg_enc2gettext_tbl[]?
> That just seems safer to me, and more consistent because its values
> satisfies PG_VALID_ENCODING().
Safety wise it doesn't matter, because gaps in a designated
initializer
On Fri, Mar 1, 2024 at 8:58 AM shveta malik wrote:
>
> On Wed, Feb 28, 2024 at 4:51 PM Amit Kapila wrote:
> >
> > On Wed, Feb 28, 2024 at 3:26 PM shveta malik wrote:
> > >
> > >
> > > Here is the patch which addresses the above comments. Also optimized
> > > the test a little bit. Now we use
Here are some review comments for v102-0001.
==
doc/src/sgml/config.sgml
1.
+
+Lists the streaming replication standby server slot names that logical
+WAL sender processes will wait for. Logical WAL sender processes will
+send decoded changes to plugins only
At Fri, 01 Mar 2024 12:37:55 +0900 (JST), Kyotaro Horiguchi
wrote in
> Anyway, our current policy here is to avoid record-rereads beyond
> source switches. However, fixing this seems to require that source
> switches cause record rereads unless some additional information is
> available to know
I'm looking at RT_FREE_RECURSE again (only used for DSA memory), and
I'm not convinced it's freeing all the memory. It's been many months
since we discussed this last, but IIRC we cannot just tell DSA to free
all its segments, right? Is there currently anything preventing us
from destroying the
On Thu, Feb 29, 2024 at 04:01:47AM +0100, Jelte Fennema-Nio wrote:
> On Thu, 29 Feb 2024 at 01:57, Michael Paquier wrote:
>> I have doubts about the changes in raw_pg_bind_textdomain_codeset(),
>> as the encoding could come from the value in the pg_database tuples
>> themselves. The current
On Thu, Feb 29, 2024 at 12:41:38PM +0100, Peter Eisentraut wrote:
> On 27.02.24 08:57, Alvaro Herrera wrote:
>> On 2024-Feb-27, Michael Paquier wrote:
>>> These would cause compilation failures. Saying that, this is a very
>>> nice cleanup, so I've fixed these and applied the patch after checking
>
>
> That’s certainly a fair point and my initial reaction (which could
> certainly be wrong) is that it’s unlikely to be an issue- but also, if you
> feel you could make it work with an array and passing all the attribute
> info in with one call, which I suspect would be possible but just a bit
On Friday, March 1, 2024 10:17 AM Zhijie Hou (Fujitsu)
wrote:
>
>
> Attach the V102 patch set which addressed Amit and Shveta's comments.
> Thanks Shveta for helping addressing the comments off-list.
The cfbot reported a compile warning, here is the new version patch which fixed
it,
Also
At Fri, 01 Mar 2024 12:04:31 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 01 Mar 2024 10:29:12 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > After reading this, I came up with a possibility that walreceiver
> > recovers more quickly than the calling interval to
> >
On Wed, Feb 28, 2024 at 4:51 PM Amit Kapila wrote:
>
> On Wed, Feb 28, 2024 at 3:26 PM shveta malik wrote:
> >
> >
> > Here is the patch which addresses the above comments. Also optimized
> > the test a little bit. Now we use pg_sync_replication_slots() function
> > instead of worker to test the
At Fri, 01 Mar 2024 10:29:12 +0900 (JST), Kyotaro Horiguchi
wrote in
> After reading this, I came up with a possibility that walreceiver
> recovers more quickly than the calling interval to
> WaitForWALtoBecomeAvailable(). If walreceiver disconnects after a call
> to the function
On Thursday, February 29, 2024 5:54 PM Amit Kapila
wrote:
>
> On Thu, Feb 29, 2024 at 8:29 AM Peter Smith
> wrote:
> >
> > On Wed, Feb 28, 2024 at 1:23 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Tuesday, February 27, 2024 3:18 PM Peter Smith
> wrote:
> > ...
> > > > 20.
> > > > +#
> >
On Thursday, February 29, 2024 7:36 PM shveta malik
wrote:
>
> On Thu, Feb 29, 2024 at 7:04 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Here is the v101 patch set which addressed above comments.
> >
>
> Thanks for the patch. Few comments:
>
> 1) Shall we mention in doc that shutdown will wait
On Thursday, February 29, 2024 7:17 PM Amit Kapila
wrote:
>
> On Thu, Feb 29, 2024 at 3:23 PM Amit Kapila
> wrote:
> >
> > Few additional comments on the latest patch:
> > =
> > 1.
> > static XLogRecPtr
> > WalSndWaitForWal(XLogRecPtr loc)
> > {
> > ...
> > +
On Thu, Feb 29, 2024 at 04:10:26PM +0800, jian he wrote:
> why not just shovel these to standard_ProcessUtility.
> so ProcessUtility will looking consistent with (in format)
> * ExecutorStart()
> * ExecutorRun()
> * ExecutorFinish()
> * ExecutorEnd()
That's one of the points of the change:
On Thu, Feb 29, 2024 at 06:19:58PM +0500, Andrey M. Borodin wrote:
> Works fine for me. Thanks!
+ "timed out waiting for the backend type to wait for the injection
point name";
The log should provide some context about the caller failing, meaning
that the backend type and the injection
On Thu, Feb 29, 2024 at 08:51:31AM -0600, Justin Pryzby wrote:
> On Wed, Feb 28, 2024 at 05:08:49PM +0900, Michael Paquier wrote:
>> I have implemented that so as we keep the default, historical
>> behavior: if pg_class.relam is 0 for a partitioned table, use the AM
>> defined by
At Fri, 1 Mar 2024 08:17:04 +0900, Michael Paquier wrote
in
> On Thu, Feb 29, 2024 at 05:44:25PM +0100, Alexander Kukushkin wrote:
> > On Thu, 29 Feb 2024 at 08:18, Kyotaro Horiguchi
> > wrote:
> >> In the first place, it's important to note that we do not guarantee
> >> that an async standby
On Thu, Feb 29, 2024 at 6:44 PM Tomas Vondra
wrote:
>
> On 2/29/24 23:44, Tomas Vondra wrote:
> >
> > ...
> >
> >>>
> >>> I do have some partial results, comparing the patches. I only ran one of
> >>> the more affected workloads (cyclic) on the xeon, attached is a PDF
> >>> comparing master and
On Mon, 2023-10-02 at 16:06 -0400, Robert Haas wrote:
> It seems to me that this overlooks one of the major points of Jeff's
> proposal, which is that we don't reject text input that contains
> unassigned code points. That decision turns out to be really painful.
Attached is an implementation of
On Thu, Feb 29, 2024 at 5:44 PM Tomas Vondra
wrote:
>
>
>
> On 2/29/24 22:19, Melanie Plageman wrote:
> > On Thu, Feb 29, 2024 at 7:54 AM Tomas Vondra
> > wrote:
> >>
> >>
> >>
> >> On 2/29/24 00:40, Melanie Plageman wrote:
> >>> On Wed, Feb 28, 2024 at 6:17 PM Tomas Vondra
> >>> wrote:
>
Hi,
This original patch made by Tomas improves the usability of extended
statistics,
so I rebased it on 362de947, and I'd like to re-start developing it.
The previous thread [1] suggested something to solve. I'll try to solve it as
best I can, but I think this feature is worth it with some
On Thu, Feb 29, 2024 at 1:08 PM Daniel Gustafsson wrote:
> + /* TODO */
> + CHECK_SETOPT(actx, CURLOPT_WRITEDATA, stderr);
> I might be missing something, but what this is intended for in
> setup_curl_handles()?
Ah, that's cruft left over from early debugging, just so that I could
see what
Attached please find a patch to adjust the behavior of the pgbench program
and make it behave like the other programs that connect to a database
(namely, psql and pg_dump). Specifically, add support for using -d and
--dbname to specify the name of the database. This means that -d can no
longer be
On Wed, Feb 28, 2024 at 9:40 AM Daniel Gustafsson wrote:
> +#define ALLOC(size) malloc(size)
> I wonder if we should use pg_malloc_extended(size, MCXT_ALLOC_NO_OOM) instead
> to self document the code. We clearly don't want feature-parity with server-
> side palloc here. I know we use malloc in
Greetings,
On Thu, Feb 29, 2024 at 17:48 Corey Huinker wrote:
> Having looked through this thread and discussed a bit with Corey
>> off-line, the approach that Tom laid out up-thread seems like it would
>> make the most sense overall- that is, eliminate the JSON bits and the
>> SPI and instead
On Thu, Feb 29, 2024 at 05:44:25PM +0100, Alexander Kukushkin wrote:
> On Thu, 29 Feb 2024 at 08:18, Kyotaro Horiguchi
> wrote:
>> In the first place, it's important to note that we do not guarantee
>> that an async standby can always switch its replication connection to
>> the old primary or
On Thu, Feb 29, 2024 at 02:42:08PM +0530, Amit Kapila wrote:
> +1. LGTM as well.
This has been introduced by ddd5f4f54a02, so if you wish to fix it
yourself, please feel free. If you'd prefer that I take care of it,
I'm OK to do so as well.
--
Michael
signature.asc
Description: PGP signature
>
>
>
> Having looked through this thread and discussed a bit with Corey
> off-line, the approach that Tom laid out up-thread seems like it would
> make the most sense overall- that is, eliminate the JSON bits and the
> SPI and instead export the stats data by running queries from the new
>
On 2/29/24 22:19, Melanie Plageman wrote:
> On Thu, Feb 29, 2024 at 7:54 AM Tomas Vondra
> wrote:
>>
>>
>>
>> On 2/29/24 00:40, Melanie Plageman wrote:
>>> On Wed, Feb 28, 2024 at 6:17 PM Tomas Vondra
>>> wrote:
On 2/28/24 21:06, Melanie Plageman wrote:
> On Wed, Feb
On Thu, Feb 29, 2024 at 10:02:21PM +, Maiquel Grassi wrote:
> Sorry for the delay. I will make the adjustments as requested soon.
Looking forward to it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 2/13/24 21:00, jian he wrote:
Hi
more minor issues.
+ FindFKComparisonOperators(
+ fkconstraint, tab, i, fkattnum,
+ _check_ok, _pfeqop_item,
+ pktypoid[i], fktypoid[i], opclasses[i],
+ is_temporal, false,
+ [i], [i], [i]);
+ }
+ if (is_temporal) {
+ pkattnum[numpks] = pkperiodattnum;
+
On Sat, Feb 17, 2024 at 02:53:43PM +, Maiquel Grassi wrote:
>> The "pg_stat_ssl" view is available from >= PG 9.5, and the "pg_stat_gssapi"
>> view is
>> available from >= PG 12. The "compression" column was removed from the
>> "pg_stat_ssl" from >= PG 14. All of these cases introduce greater
We are now hours away from starting the last commitfest for v17 and AFAICS
there have been no volunteers for the position of Commitfest manager (cfm) yet.
As per usual it's likely beneficial if the CFM of the last CF before freeze is
someone with an seasoned eye to what can make it and what can't,
Currently, cancel request key is a 32-bit token, which isn't very much
entropy. If you want to cancel another session's query, you can
brute-force it. In most environments, an unauthorized cancellation of a
query isn't very serious, but it nevertheless would be nice to have more
protection
On Thu, Feb 29, 2024 at 7:54 AM Tomas Vondra
wrote:
>
>
>
> On 2/29/24 00:40, Melanie Plageman wrote:
> > On Wed, Feb 28, 2024 at 6:17 PM Tomas Vondra
> > wrote:
> >>
> >>
> >>
> >> On 2/28/24 21:06, Melanie Plageman wrote:
> >>> On Wed, Feb 28, 2024 at 2:23 PM Tomas Vondra
> >>> wrote:
>
> On 27 Feb 2024, at 20:20, Jacob Champion
> wrote:
>
> On Fri, Feb 23, 2024 at 5:01 PM Jacob Champion
> wrote:
>> The
>> patchset is now carrying a lot of squash-cruft, and I plan to flatten
>> it in the next version.
>
> This is done in v17, which is also now based on the two patches pulled
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Greetings,
* Corey Huinker (corey.huin...@gmail.com) wrote:
> On Thu, Feb 15, 2024 at 4:09 AM Corey Huinker
> wrote:
> > Posting v5 updates of pg_import_rel_stats() and pg_import_ext_stats(),
> > which address many of the concerns listed earlier.
> >
> > Leaving the export/import scripts off for
On Wed, Feb 28, 2024 at 2:54 PM Daniel Gustafsson wrote:
> I rank that as one of my better typos actually. Fixed though.
LGTM!
Thanks,
--Jacob
On Thu, 2024-02-29 at 19:24 +, Dean Rasheed wrote:
> Attached is a rebased version on top of 5f2e179bd3 (support for MERGE
> into views), with a few additional tests to confirm that MERGE ...
> RETURNING works for views as well as tables.
Thank you for the rebase. I just missed your message
Can we get some input on whether the current MERGE ... RETURNING patch
is the right approach from a language standpoint?
We've gone through a lot of iterations -- thank you Dean, for
implementing so many variations.
To summarize, most of the problem has been in retrieving the action
Alvaro Herrera writes:
> On 2024-Feb-29, Tom Lane wrote:
>> I agree that perminfoindex seems to have suffered from add-at-the-end
>> syndrome, and if we do touch the field order you made an improvement
>> there. (BTW, who thought they needn't bother with a comment for
>> perminfoindex?)
> There
Hi,
Historically many public hospitals I work for had IBM Power hardware.
The SMT8 (8 threads/cores) capabilities of Power CPU are useful to lower Oracle
licence & support cost. We migrate to PostgreSQL and it runs very well on
Power, especially since the (relatively) recent parallel executions
On 2024-Feb-29, Tom Lane wrote:
> I agree that perminfoindex seems to have suffered from add-at-the-end
> syndrome, and if we do touch the field order you made an improvement
> there. (BTW, who thought they needn't bother with a comment for
> perminfoindex?)
There is a comment for it, or at
On Thu, 2024-02-29 at 21:47 +0700, Danil Anisimow wrote:
> Answering your questions might take some time as I want to write a
> sample patch for pg_stat_statements and make some tests.
> What do you think about putting the patch to commitfest as it closing
> in a few hours?
Added to March CF.
I
Peter Eisentraut writes:
> In nodes/parsenodes.h, it says both
> This *must* be false for RTEs other than RTE_RELATION entries.
Well, that's true in the parser ...
> and also puts it under
> Fields valid in all RTEs:
> which are both wrong on opposite ends of the spectrum.
> I think
On Thu, Feb 29, 2024 at 10:04 PM Nathan Bossart
wrote:
>
> Here is a new version of the patch that uses the new atomic read/write
> functions with full barriers that were added in commit bd5132d. Thoughts?
Thanks for getting the other patch in. The attached v6 patch LGTM.
--
Bharath Rupireddy
Dear All,
Consider, please, my patch for async commit for twophase transactions. It can
be applicable when catchup performance is not enought with publication
parameter twophase = on.
The key changes are:
* Use XLogSetAsyncXactLSN instead of XLogFlush as it is for usual
transactions. * In
Moaaz Assali writes:
> However, I don't see the issue with the INT64 -> UINT64 mapping. The
> current implementation results in integer overflows (errors instead after
> the recent patch) even for valid timestamps where the result of date_bin()
> is also another valid timestamp.
> On the other
Looks good to me.
* John
From: Nathan Bossart
Date: Thursday, February 29, 2024 at 8:34 AM
To: Andres Freund
Cc: Stephen Frost , John Morris
, Bharath Rupireddy
, Michael Paquier
, Robert Haas ,
pgsql-hack...@postgresql.org
Subject: Re: Atomic ops for unlogged LSN
Here is a new
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> Here is a new version of the patch that uses the new atomic read/write
> functions with full barriers that were added in commit bd5132d. Thoughts?
Saw that commit go in- glad to see it. Thanks for updating this patch
too. The
Hi Kyotaro,
On Thu, 29 Feb 2024 at 08:18, Kyotaro Horiguchi
wrote:
In the first place, it's important to note that we do not guarantee
> that an async standby can always switch its replication connection to
> the old primary or another sibling standby. This is due to the
> variations in
On Thu, 29 Feb 2024 at 09:50, Alvaro Herrera wrote:
>
> By all means let's get the feature out there. It's not a frequently
> requested thing but it does seem to come up.
>
Pushed. Thanks for reviewing.
Regards,
Dean
Hi Michael,
On Thu, 29 Feb 2024 at 06:05, Michael Paquier wrote:
>
> Wow. Have you seen that in an actual production environment?
>
Yes, we see it regularly, and it is reproducible in test environments as
well.
> my $start_page = start_of_page($end_lsn);
> my $wal_file = write_wal($primary,
Here is a new version of the patch that uses the new atomic read/write
functions with full barriers that were added in commit bd5132d. Thoughts?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From c40594c62ccfbf75cb0d3787cb9367d15ae37de8 Mon Sep 17 00:00:00 2001
From: Nathan
Committed. Thank you for reviewing!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Feb 28, 2024 at 05:08:49PM +0900, Michael Paquier wrote:
> On Wed, Feb 21, 2024 at 08:46:48AM +0100, Peter Eisentraut wrote:
> > Yes, I think most people agreed that that would be the preferred behavior.
>
> Challenge accepted. As of the patch attached.
Thanks for picking it up. I find
[re-adding the CC list I dropped earlier]
On Wed, Feb 28, 2024 at 1:52 PM Daniel Gustafsson wrote:
>
> > On 28 Feb 2024, at 22:50, Andrew Dunstan wrote:
> > Can you give some more details about what this python gadget would buy us?
> > I note that there are a couple of CPAN modules that
On Tue, Feb 27, 2024 at 2:56 AM Jeff Davis wrote:
> Let's pick this discussion back up, then. Where should the hook go?
> Does it need to be broken into phases like resource owners? What
> guidance can we provide to extension authors to use it correctly?
>
> Simon's right that these things don't
> On 29 Feb 2024, at 15:20, Bertrand Drouvot
> wrote:
>
> done in v2 attached.
Works fine for me. Thanks!
Best regards, Andrey Borodin.
On 26.02.24 02:08, Michael Paquier wrote:
On Fri, Feb 23, 2024 at 06:52:54PM -0500, Tom Lane wrote:
Julien Rouhaud writes:
On Fri, Feb 23, 2024 at 04:26:53PM +0100, Peter Eisentraut wrote:
- funcordinality
This was probably just forgotten. It should be included because the WITH
ORDINALITY
On 23.02.24 16:19, Tom Lane wrote:
Dean Rasheed writes:
On Fri, 23 Feb 2024 at 14:35, Peter Eisentraut wrote:
Various code comments say that the RangeTblEntry field inh may only be
set for entries of kind RTE_RELATION.
Yes, it's explained a bit more clearly/accurately in
On 2024-Feb-13, Tomas Vondra wrote:
> One thing that is not very clear to me is that I don't think there's a
> very good way to determine which places need the cleanup call. Because
> it depends on (a) what kind of index is used and (b) what happens in the
> code called earlier (which may easily
On Tue, Feb 20, 2024 at 1:59 PM Masahiko Sawada wrote:
> - v63-0008 patch fixes a bug in tidstore.
- page->nwords = wordnum + 1;
- Assert(page->nwords = WORDS_PER_PAGE(offsets[num_offsets - 1]));
+ page->nwords = wordnum;
+ Assert(page->nwords == WORDS_PER_PAGE(offsets[num_offsets - 1]));
On 27.02.24 08:57, Alvaro Herrera wrote:
On 2024-Feb-27, Michael Paquier wrote:
These would cause compilation failures. Saying that, this is a very
nice cleanup, so I've fixed these and applied the patch after checking
that the one-one replacements were correct.
Oh, I thought we were going
On Thu, Feb 29, 2024 at 7:04 AM Zhijie Hou (Fujitsu)
wrote:
>
> Here is the v101 patch set which addressed above comments.
>
Thanks for the patch. Few comments:
1) Shall we mention in doc that shutdown will wait for standbys in
standby_slot_names to confirm receiving WAL:
Suggestion for
On Thu, Feb 29, 2024 at 3:23 PM Amit Kapila wrote:
>
> Few additional comments on the latest patch:
> =
> 1.
> static XLogRecPtr
> WalSndWaitForWal(XLogRecPtr loc)
> {
> ...
> + if (!XLogRecPtrIsInvalid(RecentFlushPtr) && loc <= RecentFlushPtr &&
> +
On 2024-Feb-29, Kyotaro Horiguchi wrote:
> At Tue, 27 Feb 2024 18:33:18 +0100, Alvaro Herrera
> wrote in
> > Here's the complete set, with these two names using the singular.
>
> The commit by the second patch added several GUC descriptions:
>
> > Sets the size of the dedicated buffer pool
On 2024-Feb-28, Jelte Fennema-Nio wrote:
> diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
> index 699d9d0a241..553e4785520 100644
> --- a/src/backend/utils/error/elog.c
> +++ b/src/backend/utils/error/elog.c
> @@ -843,6 +843,8 @@ matches_backtrace_functions(const
Hi!
I'd like to suggest two independent patches to improve performance of type cache
cleanup. I found a case where type cache cleanup was a reason for low
performance. In short, customer makes 100 thousand temporary tables in one
transaction.
1 mapRelType.patch
It just adds a local map
> On 22 Jan 2024, at 11:09, Daniel Gustafsson wrote:
> Feel free to go ahead with that
> version, or let me know if you want me to deal with it.
I took the liberty to add this to the upcoming CF to make sure we don't lose
track of it.
--
Daniel Gustafsson
Hi,
On Thu, Feb 29, 2024 at 02:34:35PM +0500, Andrey M. Borodin wrote:
>
>
> > On 29 Feb 2024, at 13:35, Bertrand Drouvot
> > wrote:
> >
> > Something like the attached?
>
> There's extraneous print "done\n";
doh! bad copy/paste ;-)
> Also can we have optional backend type :)
done in v2
> On 28 Feb 2024, at 19:50, Jelte Fennema-Nio wrote:
>
> On Wed, 28 Feb 2024 at 19:04, Daniel Gustafsson wrote:
>> This should be "equal to or higher" right?
>
> Correct, nicely spotted. Fixed that. I also updated the docs for the
> new backtrace_functions_min_level GUC itself too, as well as
On Thu, Feb 29, 2024 at 9:13 AM Peter Smith wrote:
>
> On Tue, Feb 27, 2024 at 11:35 PM Amit Kapila wrote:
> >
>
> > Also, adding wait sounds
> > more like a boolean. So, I don't see the proposed names any better
> > than the current one.
> >
>
> Anyway, the point is that the current GUC name
> On 29 Feb 2024, at 10:24, Michael Banck wrote:
> On Thu, Feb 29, 2024 at 12:57:31AM -0800, Andres Freund wrote:
>> Then these users should have paid somebody to actually do maintenance work on
>> the AIX support,o it doesn't regularly stand in the way of implementing
>> various things.
>
>
1 - 100 of 115 matches
Mail list logo
