Gurjeet Singh writes:
> On Sun, Mar 16, 2025 at 7:53 PM Robert Haas wrote:
>> I'm confused. Tom and I both said we didn't like this change,
> To me, Tom's feedback felt as being between ambivalent to the change and
> perhaps
> agree with the change, as long as pgindent did not throw a fit, whic
On Mon, 3 Feb 2025 at 21:08, Dmitry Koval wrote:
>
> Hi, Alexander!
> Thanks for your advices and recommendations!
>
> >I don't think we need a separate 0003 patch with refactoring. It's
> >probably good idea to keep this functionality as a separate patch, but
> >let's make then it a 0001, whi
On Fri, 7 Mar 2025 at 17:22, Andreas Karlsson wrote:
>
> Hi,
>
> Here is a rebased version of it to make the CI happy. I plan to work
> more on this next week but am happy with any feedback on what is already
> there.
I noticed that Kirill's comments from [1] are not yet addressed, I
have changed
On Saturday, November 23, 2024, Andrey M. Borodin
wrote:
>
>
> It seems that protection of temp tables should belong to ACL stuff. And in
> a logic of this subsystem would be natural to just allow superuser do
> whatever they want with.
>
My understanding is the limitation of an owner of a tempor
On 2025-Mar-16, Robert Haas wrote:
> On Fri, Mar 14, 2025 at 3:38 PM Álvaro Herrera
> wrote:
> > I forgot to send a note here that I pushed this patch. Thank you.
>
> I'm confused. Tom and I both said we didn't like this change, so you
> committed the patch without further discussion?
Tom did
On Thu, 27 Feb 2025 at 23:30, Alena Rybakina wrote:
>
> Hi!
> On 17.02.2025 17:46, Alena Rybakina wrote:
> > On 04.02.2025 18:22, Alena Rybakina wrote:
> >> Hi! Thank you for your review!
> >>
> >> On 02.02.2025 23:43, Alexander Korotkov wrote:
> >>> On Mon, Jan 13, 2025 at 3:26 PM Alena Rybakina
On Mon, Mar 10, 2025 at 11:46 AM Shlok Kyal wrote:
>
>
> I tried to reproduce the scenario described using the following steps:
>
> Here are the steps:
>
> 1. set max_replication_slots = 2
>
> 2. create two logical replication slot, lets say slot1 and slot2. drop
> the first slot (slot1).
>
> 3. N
On Mon, 27 Jan 2025 at 07:51, jian he wrote:
>
> hi.
>
> I forgot to attach the patch.
> here we are.
I noticed that David's comments from [1] have not yet been addressed,
I have changed the status of commitfest entry to "Waiting on Author",
please address them and change the status to "Needs rev
On Fri, 20 Dec 2024 at 10:50, Andreas Karlsson wrote:
>
> Hi,
>
> Jeff pointed out to me that the case conversion functions in ICU have
> UTF-8 specific versions which means we can call those directly if the
> database encoding is UTF-8 and skip having to convert to and from UChar.
>
> Since most
On Mon, 3 Mar 2025 at 17:26, Álvaro Herrera wrote:
>
> On 2025-Feb-18, Sami Imseih wrote:
>
> > > It's not a question about whether it's possible to implement this,
> > > but about whether it makes sense. In case of plain constants it's
> > > straightforward -- they will not change anything meanin
On Fri, 28 Feb 2025 at 19:37, wrote:
>
> Hi,
>
> Fix an error in the patch.
Currently we have the following commitfest entries for this thread:
[1] - https://commitfest.postgresql.org/patch/5611/
[2] - https://commitfest.postgresql.org/patch/5513/
I have closed the second entry at [2].
Regards,
On Fri, 14 Mar 2025 at 14:11, Peter Eisentraut wrote:
>
> On 05.03.25 17:40, Peter Eisentraut wrote:
> > On 03.03.25 11:17, Peter Eisentraut wrote:
> >> Update for the hackers list: This patch set was briefly committed but
> >> had to be reverted because it crashed on some older Python versions;
>
On Sat, Mar 15, 2025 at 03:26:10PM +0900, Michael Paquier wrote:
> Thanks for digging into all that. Agreed that it would be nice to
> apply a more consistent style for this release. I'll look more into
> what you have here.
The changes in pg_dump's 010_dump_connstr.pl read the same.
extension_
On Mon, Mar 17, 2025 at 6:53 AM Hayato Kuroda (Fujitsu)
wrote:
>
> OK, let me share patched for back branches. Mostly the same fix patched as
> master
> can be used for PG14-PG17, like attached.
>
A few comments:
==
1.
+SnapBuildDistributeSnapshotAndInval(SnapBuild *builder, XLogRecP
Hi,
Recently I took more careful measurements of the performance. I
compared three branches with each other: HEAD, Patched and Patched
with tuplestore.
Here are the results :
1)
Test case : matview creation test attached in the email from Jingtang Zhang.
10 measurements for each branch.
Result in
Jan Wieck writes:
> As the original author of the TOAST I vote for TOAST being used as the
> name/acronym of the feature, but toast in all other cases like as verb.
Well, if we're appealing to history ... I dug in the archives
and found that you seem to have invented the name here [1]:
Sinc
On Sun, 16 Mar 2025 at 19:38, Peter Smith wrote:
> But, because of all the differing views expressed here I'm not sure
> now how to proceed. Any ideas?
>
May I suggest that you start with a patch to Appendix J, section 6 to
codify whatever is decided?
https://www.postgresql.org/docs/current/do
As the original author of the TOAST I vote for TOAST being used as the
name/acronym of the feature, but toast in all other cases like as verb.
Best Regards, Jan
On 3/16/25 22:49, Robert Haas wrote:
On Sun, Mar 16, 2025 at 7:38 PM Peter Smith wrote:
If I understand correctly, the summary is
On Tue, 11 Mar 2025 at 09:41, vignesh C wrote:
>
Here's a quick commitfest status report as of today:
status | start | 10th | 17th
+-+-+-
Needs review: | 198 | 182 | 134
Waiting on Author: |
Jelte Fennema-Nio writes:
> On Sun, 15 Dec 2024 at 10:00, Alexander Lakhin wrote:
>> shows that the subscription and publication tests are not concurrent-safe,
>> because modifying the same pg_database entry might fail with the "tuple
>> concurrently updated" error.
> This seems related to this
On Sunday, March 16, 2025, Robert Haas wrote:
>
>
> WARNING: you just caused a problem for somebody else
>
> The user has no particular reason to care about the fact that the
> password they just typed ended up in the log.
>
It could also be:
warning: your password is known to Big Brother
hint:
On Mon, Mar 17, 2025 at 1:50 PM Robert Haas wrote:
>
> On Sun, Mar 16, 2025 at 7:38 PM Peter Smith wrote:
> > If I understand correctly, the summary is:
> > - Tom: +1 for "TOAST table", but changing all the combined forms is
> > maybe not worth the effort.
> > - DavidJ: Wants to uppercase TOAST
On Sat, Mar 15, 2025 at 8:03 PM David G. Johnston
wrote:
>
> On Friday, March 14, 2025, Amit Kapila wrote:
>>
>>
>> Style-1 sounds reasonable to me, but how exactly we want to do. One
>> idea is to have short and long switches like -r and
>> --remove_exiting_object=publication. The user would be
On Fri, Mar 14, 2025 at 2:50 PM Greg Sabino Mullane wrote:
> I'd rather not sit on this another year, if we can help it. We really should
> be warning people about this practice. The exact wording of the hint can be
> up for debate (or postponed - we technically don't have to say anything other
On Fri, Mar 14, 2025 at 3:38 PM Álvaro Herrera wrote:
> I forgot to send a note here that I pushed this patch. Thank you.
I'm confused. Tom and I both said we didn't like this change, so you
committed the patch without further discussion?
I mean, this is a pretty unimportant detail, so I don't
"David G. Johnston" writes:
> On Sunday, March 16, 2025, Steven Niu wrote:
>> +# is missing, we must link not just compile, and store the results in
>> global
> I’d probably add a comma before the “not” though. Or maybe: we must also
> link and store the results in global
A comma there wouldn'
On Sun, Mar 16, 2025 at 7:38 PM Peter Smith wrote:
> If I understand correctly, the summary is:
> - Tom: +1 for "TOAST table", but changing all the combined forms is
> maybe not worth the effort.
> - DavidJ: Wants to uppercase TOAST only when it refers to 'technique';
> lowercase otherwise.
> - R
Dear Amit,
> IIUC, workloads C and D will have regression in back branches, and
> HEAD will have regression only for workload D. We have avoided
> workload C regression in HEAD via commits 7c99dc587a and 3abe9dc188.
Right.
> We can backpatch those commits if required, but I think it is better
>
On Sunday, March 16, 2025, Steven Niu wrote:
>
> +# is missing, we must link not just compile, and store the results in
> global
>
> The "compile" should be "compiler"?
>
No. Compile is the verb that pairs with link. Compiler is a noun, its
compliment being the linker.
I’d probably add a comm
Steven Niu writes:
> +# is missing, we must link not just compile, and store the results in
> global
> The "compile" should be "compiler"?
I think it's okay as-is: "link" and "compile" are both being used
as verbs. We could say "run the compiler", but that's longer
without being better.
Besid
+# is missing, we must link not just compile, and store the results in
global
The "compile" should be "compiler"?
Regards,
Steven
在 2025/3/15 7:04, Tom Lane 写道:
I noticed that our configuration-time checks for the presence
of CRC intrinsics generally look like
unsigned int crc = 0;
Hi,
If I understand correctly, the summary is:
- Tom: +1 for "TOAST table", but changing all the combined forms is
maybe not worth the effort.
- DavidJ: Wants to uppercase TOAST only when it refers to 'technique';
lowercase otherwise.
- RobertT: The verbs should be lowercase (e.g. laser). Each-wa
There was a minor typo in the test module. I built and ran the
test_dsm_registry extension before submitting the patch but perhaps it
got mixed up with an older version.
From 06ddb42e39b3bd0e411a9bc96467ca6797673b8a Mon Sep 17 00:00:00 2001
From: swchangdev
Date: Fri, 14 Mar 2025 10:00:12 +0900
Su
When I try to show details of a commit, I see an empty page.
Example:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blobdiff;f=src/backend/access/transam/xlog.c;h=4b6c694a3f71941b190293d4ef8f346b8fdd3229;hp=799fc739e18cd8a7d122dd54adbe21968933e565;hb=5721e5453ebc59360b6756fe72d7499c4a02177c
Thanks for pushing it.
==
Kind Regards,
Peter Smith.
Fujitsu Australia
Greg Sabino Mullane writes:
> Re-reviewed this patch: still compiles, tests pass, and does what it says
> on the tin. +1
Pushed with minor corrections:
* The patch still hadn't absorbed jian he's point that pg_dump main()
needs to fill ropt->no_policies from dopt.no_policies. It's possible
that
On Fri, Mar 14, 2025 at 04:14:25PM +1300, David Rowley wrote:
> I don't think I'm discarding them... As far as I'm aware, your
> remaining concern is with custom jumble functions and you showed an
> example in [1] of a hypothetical jumble function that could cause the
> same bug as this thread is d
2025년 3월 14일 (금) 오후 11:36, Nathan Bossart 님이 작성:
> My expectation is that the error handling takes care of these things. Are
> there cases where it does not? In any case, I would expect these errors to
> be extremely rare to the point of virtually never happening in practice.
I don't see any log
On Sat, Mar 15, 2025 at 11:09:28AM +0900, Michael Paquier wrote:
> Let's remove it for this release. Perhaps we will not even need this
> part if we are able to rebuild the most critical stats from WAL after
> a crash. This itself needs more work, one point mentioned being to
> move some table s
On Sun, Mar 16, 2025 at 1:29 AM Laurenz Albe wrote:
>
> On Sat, 2025-03-15 at 17:14 -0700, Gurjeet Singh wrote:
> > > One other difference in my version of the patch [0] is to call this GUC
> > > vacuum_truncate and have it apply to both autovacuum and VACUUM. I did
> > > this for the following r
>
> * The custom format actually does two WriteToc() calls, and since these
> patches move the queries to this part of pg_dump, it means we'll run all
> the queries twice. The comments around this code suggest that the second
> pass isn't strictly necessary and that it is really only useful
Thanks for working on this, Corey.
On Fri, Mar 14, 2025 at 04:03:16PM -0400, Corey Huinker wrote:
> 0003 -
>
> Storing the restore function calls in the archive entry hogged a lot of
> memory and made people nervous. This introduces a new function pointer that
> generates those restore SQL calls
Hi Hackers,
Just leaving a quick note: I know this patch has through a lot of variations. I
am keen on shipping this for v18 if possible, and while it’s a learning process
for me, I am more than happy to iterate on any feedback. Let me know if there
is anything I can do to help to keep the mome
On Fri, Mar 14, 2025 at 12:50 PM Greg Sabino Mullane
wrote:
> I'd rather not sit on this another year, if we can help it. We really
> should be warning people about this practice. The exact wording of the hint
> can be up for debate (or postponed - we technically don't have to say
> anything othe
hi.
before commit 4618045bee4a6d3efcb489c319649d8dd9aaa738 ([0])
select array_sort(array(select '1 4'::int2vector union all select '1
2'::int2vector));
array_sort
--
[1:2][0:1]={{1,2},{1,4}}
(1 row)
after
select array_sort(array(select '1 4'::int2vector union al
> On 14 Mar 2025, at 15:27, Peter Eisentraut wrote:
>
> On 13.03.25 19:31, Tom Lane wrote:
>> Jacob Champion writes:
>>> Adding the PG prefix to the envvar name addresses my collision
>>> concern, but I think Tom's comment upthread [1] was saying that we
>>> should not provide any envvar at all:
On Sat, 8 Mar 2025 at 02:41, Jeff Davis wrote:
>
> On Wed, 2025-03-05 at 20:43 -0600, Nathan Bossart wrote:
> > I see. Do we provide any suggested next steps for users to assess
> > the
> > potentially-affected relations?
>
> I don't know exactly where we should document it, but I've attached a
>
On Wed, 12 Mar 2025 at 20:14, Yura Sokolov wrote:
>
> Otherwise v6 is just rebased v5.
I noticed that Tomas's comments from [1] are not yet addressed, I have
changed the commitfest status to Waiting on Author, please address
them and update it to Needs review.
[1] -
https://www.postgresql.org/me
On Wed, 12 Feb 2025 at 00:11, Matheus Alcantara
wrote:
>
> Hi,
>
> Em ter., 11 de fev. de 2025 às 03:39, jian he
> escreveu:
> > hi. some minor issue i found.
> >
> > +#include "storage/block.h"
> > no need, since "#include "storage/bufmgr.h" already included it.
> >
> Fixed
>
> > do we need to a
On Sat, 29 Jun 2024 at 02:27, David G. Johnston
wrote:
>
> A documentation comment came in [1] causing me to review some of our backup
> documentation and I left the current content and location of the standalone
> backups was odd. I propose to move it to a better place, under file system
> ba
On Fri, 14 Mar 2025 at 03:38, Daniel Gustafsson wrote:
>
>
>
> > On 13 Mar 2025, at 19:31, Tom Lane wrote:
> >
> > Jacob Champion writes:
> >> Adding the PG prefix to the envvar name addresses my collision
> >> concern, but I think Tom's comment upthread [1] was saying that we
> >> should not pr
On Thu, 12 Sept 2024 at 04:30, Jacob Champion
wrote:
>
> On Wed, Sep 11, 2024 at 12:08 PM Lars Kanis wrote:
> > How did you verify the issue on the server side - with YugabyteDB or
> > with a modified Postgres server? I'd like to verify the GSSAPI part and
> > I'm familiar with the Postgres serve
On Fri, 7 Feb 2025 at 05:45, Anton A. Melnikov
wrote:
>
> Here is a small patch that does it and eliminates multiple warnings.
> Would be glad if you take a look on it.
I noticed that Kirill's comments from [1] are not yet addressed, I
have changed the status of commitfest entry to Waiting on Aut
On Sun, 9 Mar 2025 at 03:27, Nathan Bossart wrote:
>
> On Sun, Mar 09, 2025 at 03:01:41AM +0530, Ayush Vatsa wrote:
> > Maybe we can move ahead with the patch if we can see no other concerns.
>
> I think we should allow some time in case others want to review the patch.
> I do see a concern upthre
On Sat, 8 Mar 2025 at 08:06, Matthias van de Meent
wrote:
>
> Here's a patchset that uses that approach. Naming of functions, types,
> fields and arguments TBD. The patch works and passes the new
> VACUUM-conflict tests, though I suspect the SP-GIST tests to have
> bugs, as an intermediate version
On Wed, 5 Mar 2025 at 16:43, Matthias van de Meent
wrote:
>
> On Sun, 2 Mar 2025 at 01:35, Tom Lane wrote:
> >
> > Peter Geoghegan writes:
> > > Is everybody in agreement about committing and back patching this fix,
> > > which simply disables the optimization altogether?
> > > I myself don't se
On Thu, 14 Nov 2024 at 14:26, Daniil Davydov <3daniss...@gmail.com> wrote:
>
> On Wed, Oct 30, 2024 at 7:32 PM Rafia Sabih wrote:
>
> > Good catch. I agree with this being an unwarranted behaviour.
> > A minor comment from my end is the wording of the error message.
> > Based on the Postgresql err
On Wed, 27 Nov 2024 at 21:29, Nathan Bossart wrote:
>
> On Wed, Nov 27, 2024 at 03:20:19PM +0900, Michael Paquier wrote:
> > On Mon, Nov 25, 2024 at 01:29:31PM -0600, Nathan Bossart wrote:
> >> Or we could just enforce that you have an active snapshot whenever you
> >> modify a catalog with a TOAS
On Tue, Mar 11, 2025 at 04:06:14PM +0900, Michael Paquier wrote:
> Right. This improves the clarity of the code, so agreed about the use
> of a local variable here.
More code paths of pg_createsubscriber.c have similar loops, but this
is the only one where LogicalRepInfo can be used. So, applied
59 matches
Mail list logo
