Hi,
> Hi,
>
> On 2024-06-17 15:39:27 -0400, Robert Haas wrote:
>> As I mentioned in my talk at 2024.pgconf.dev, I think that the biggest
>> problem with autovacuum as it exists today is that the cost delay is
>> sometimes too low to keep up with the amount of vacuuming that needs
>> to be done.
Hi,
Let's me clarify the current state of this patch and what kind of help
is needed. You can check [1] for what kind of problem it try to solve
and what is the current approach.
The current blocker is if the approach is safe (potential to memory leak
crash etc.). And I want to have some agre
On Fri, Jun 21, 2024, at 05:25, Michael Paquier wrote:
> Interesting idea.
>
> I am not really convinced that the regproc and regclass overloads are
> really necessary, considering the fact that one of the goals
> mentioned, as far as I understand, is to be able to get an idea of the
> ACLs associa
On 21.06.2024 23:35, Robert Haas wrote:
On Fri, Jun 21, 2024 at 1:05 PM Alena Rybakina
wrote:
I'm confused, I have seen that we have two threads [1] and [2] about this
thread and I haven't found any explanation for how they differ.
And I don't understand, why am I not listed as the author of
On 20/06/2024 19:12, Robert Haas wrote:
I'm working to start a mentoring program where code contributors can
be mentored by current committers. Applications are now open:
https://forms.gle/dgjmdxtHYXCSg6aB7
Periodically, someone -- most likely not me, since a few people have
been kind enough
On Thu, Jun 13, 2024 at 05:35:49PM -0700, Noah Misch wrote:
> On Mon, Jun 10, 2024 at 07:45:25PM -0700, Noah Misch wrote:
> > On Thu, Jun 06, 2024 at 09:48:51AM -0400, Robert Haas wrote:
> > > It's not this patch set's fault, but I'm not very pleased to see that
> > > the injection point wait event
Hi, Alena.
On Fri, Jun 21, 2024 at 8:05 PM Alena Rybakina
wrote:
>
> I'm confused, I have seen that we have two threads [1] and [2] about this
> thread and I haven't found any explanation for how they differ.
>
> And I don't understand, why am I not listed as the author of the patch? I was
> de
On Fri, Jun 21, 2024 at 11:22:05AM +0200, Jelte Fennema-Nio wrote:
> 0001 is some cleanup after f4b54e1ed9
Oops. I'll plan on committing this after the 17beta2 release freeze is
lifted.
--
nathan
Hannu Krosing writes:
> This is my current patch which also adds running % and optionally uses
> faster way to count leading zeros, though I did not see a change from
> that.
I've not read the patch yet, but I did create a CF entry [1]
to get some CI cycles on this. The cfbot complains [2] abou
On Tue, Jun 18, 2024 at 07:43:36PM -0500, Nathan Bossart wrote:
> On Tue, Jun 18, 2024 at 02:33:31PM -0700, Andres Freund wrote:
>> Another one:
>>
>> Have a general cap of 64, but additionally limit it to something like
>> max(1, min(WORKER_CAP, max_connections / 4))
>>
>> so that cases lik
On Fri, Jun 21, 2024 at 1:05 PM Alena Rybakina
wrote:
> I'm confused, I have seen that we have two threads [1] and [2] about this
> thread and I haven't found any explanation for how they differ.
>
> And I don't understand, why am I not listed as the author of the patch? I was
> developing the f
While investigating a bug over on [1], I found that
vacuum_set_xid_limits() is calculating freezeLimit in an unsafe way on
at least Postgres 14 and 15.
limit = *oldestXmin - freezemin;
safeLimit = ReadNextTransactionId() - autovacuum_freeze_max_age;
if (TransactionIdPrecedes(limit, saf
On Fri, Jun 21, 2024 at 03:50:00PM -0400, Tom Lane wrote:
> Allow specification of physical standbys that must be synchronized
> before they are visible to subscribers (Hou Zhijie, Shveta Malik)
>
> it seems like the name ought to have some connection to
> synchronization. Perhaps somethi
Thanks Tom Lane. You are more insightful.
Regards,
Ikram
On Sat, Jun 22, 2024 at 12:50 AM Tom Lane wrote:
> Muhammad Ikram writes:
> > A humble input, as on primary we have #primary_slot_name = '' then
> should
> > not it be okay to have standby_slot_names or standby_slot_name ? It seems
> >
Muhammad Ikram writes:
> A humble input, as on primary we have #primary_slot_name = '' then should
> not it be okay to have standby_slot_names or standby_slot_name ? It seems
> consistent with the Guc on primary.
> Another suggestion is *standby_replication_slots*.
IIUC, Bruce's complaint is tha
Jelte Fennema-Nio writes:
> On Fri, 21 Jun 2024 at 10:46, Дмитрий Питаков wrote:
>> Why not increase the buffer size?
> I think changing the buffer size sounds like a reasonable idea, if
> that speeds stuff up. But I think it would greatly help your case if
> you showed the perf increase using a
Hi,
A humble input, as on primary we have #primary_slot_name = '' then should
not it be okay to have standby_slot_names or standby_slot_name ? It seems
consistent with the Guc on primary.
Another suggestion is *standby_replication_slots*.
Regards,
Muhammad Ikram
Bitnine Global.
On Fri, Jun 21,
John Naylor writes:
> Pushed. I'll clear the open item once all buildfarm members have reported in.
Just to confirm, my raspberry pi 4 got through "make
installcheck-parallel" under valgrind after this commit.
regards, tom lane
On Fri Jun 21, 2024 at 10:46 AM CDT, Dave Page wrote:
On Fri, 21 Jun 2024 at 16:15, Robert Haas wrote:
> As a practical matter, I don't think MSVC is coming back. The
> buildfarm was already changed over to use meson, and it would be
> pretty disruptive to try to re-add buildfarm coverage for a
I'm confused, I have seen that we have two threads [1] and [2] about
this thread andIhaven'tfoundanyexplanationfor howtheydiffer.
And I don't understand, whyam Inotlistedas the authorof the patch?
Iwasdevelopingthe firstpartof the patchbeforeAndreycameto review it[3]
andhisfirstparthasn'tchang
We are continuing to work on the changes…
> Do you still care about 32-bit binaries on AIX? If not, let's make that
> the default in configure or a check for it, and remove the instructions
> on building 32-bit binaries from the docs.
As most of the products are moving towards 64bit, we wil
Hi,
On Tue, 16 Apr 2024 at 12:34, Alexander Korotkov wrote:
>
> You're right. No sense trying to fix this. Reverted.
I just noticed that this revert (commit 6377e12a) seems to have
introduced two comment blocks atop TableAmRoutine's
scan_analyze_next_block, and I can't find a clear reason why
On 6/21/24 00:07, Tomas Vondra wrote:
> Here's a fix adding the missing headers to pg_combinebackup, and fixing
> some compile-time issues in the ifdef-ed block.
>
> I've done some basic manual testing today - I plan to test this a bit
> more tomorrow, and I'll also look at integrating this into t
pá 21. 6. 2024 v 17:55 odesílatel Nathan Bossart
napsal:
> On Fri, Jun 21, 2024 at 04:36:13PM +0200, Jelte Fennema-Nio wrote:
> > I recently got write access to the cfbot repo[1] and machine from
> > Thomas. And I deployed a few improvements this week. The most
> > significant one is that it is n
pá 21. 6. 2024 v 16:36 odesílatel Jelte Fennema-Nio napsal:
>
> I recently got write access to the cfbot repo[1] and machine from
> Thomas. And I deployed a few improvements this week. The most
> significant one is that it is now much easier to use GitHub as part of
> your patch review workflow.
>
On Fri, Jun 21, 2024 at 04:36:13PM +0200, Jelte Fennema-Nio wrote:
> I recently got write access to the cfbot repo[1] and machine from
> Thomas. And I deployed a few improvements this week. The most
> significant one is that it is now much easier to use GitHub as part of
> your patch review workflo
On Fri, Jun 21, 2024 at 11:37:54AM -0400, Bruce Momjian wrote:
> The release notes have this item:
>
> Allow specification of physical standbys that must be synchronized
> before they are visible to subscribers (Hou Zhijie, Shveta Malik)
>
> The new server variable is standby_sl
On Fri, 21 Jun 2024 at 16:15, Robert Haas wrote:
> On Fri, Jun 21, 2024 at 7:21 AM Dave Page wrote:
> > My assumption all along was that Meson would replace autoconf etc.
> before anything happened with MSVC, precisely because that's the type of
> environment all the Postgres devs work in primar
On Thu, Jun 20, 2024 at 07:57:16PM -0700, David G. Johnston wrote:
> I like this. Losing the table turned out to be ok. Thank you.
Awesome.
> I would probably put pg_monitor first in the list.
Done.
> + A user granted this role cannot however send signals to a backend owned
> by a superuser.
The release notes have this item:
Allow specification of physical standbys that must be synchronized
before they are visible to subscribers (Hou Zhijie, Shveta Malik)
The new server variable is standby_slot_names.
Is standby_slot_names an accurate name for this GUC? It
On Fri, 21 Jun 2024 07:12:25 +
wrote:
> * Is this feature useful? Is there a possibility it will be accepted?
I think adding such information to EXPLAIN outputs is useful because it
will help users confirm the effect of a multicolumn index on a certain query
and decide to whether leave, drop
On Fri, Jun 21, 2024 at 7:21 AM Dave Page wrote:
> My assumption all along was that Meson would replace autoconf etc. before
> anything happened with MSVC, precisely because that's the type of environment
> all the Postgres devs work in primarily. Instead we seem to have taken what I
> think is
Peter Eisentraut writes:
> - strlcpy(errbuf, strerror(ERR_GET_REASON(ecode)), SSL_ERR_LEN);
> + strerror_r(ERR_GET_REASON(ecode), errbuf, SSL_ERR_LEN);
Most of libpq gets at strerror_r via SOCK_STRERROR for Windows
portability. Is that relevant here?
regards,
Hi
On Fri, 21 Jun 2024 at 12:20, Dave Page wrote:
>
> We/I *could* add cmake/pc file generation to that tool, which would make
> things work nicely with PostgreSQL 17 of course.
>
For giggles, I took a crack at doing that, manually creating .pc files for
everything I've been working with so far
I recently got write access to the cfbot repo[1] and machine from
Thomas. And I deployed a few improvements this week. The most
significant one is that it is now much easier to use GitHub as part of
your patch review workflow.
On the cfbot website[2] there's now a "D" (diff) link next to each
comm
On 21/06/2024 02:25, Heikki Linnakangas wrote:
Hmm, looking closer, I think this might be a more appropriate place for
the RelationCloseSmgr() call:
/*
* If it's a mapped relation, immediately update its
rd_locator in
*
Hi,
Thanks for taking a look.
On Fri, Jun 21, 2024 at 4:05 PM jian he wrote:
> On Tue, Jun 18, 2024 at 5:02 PM Amit Langote wrote:
> > On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> > > On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > > > Peter Eisentraut writes:
> > > > > On 02.06.2
> On 21 Jun 2024, at 13:15, Peter Eisentraut wrote:
> I noticed that this change uses not-thread-safe strerror() in libpq code.
>
> Perhaps something like this would be better (and simpler):
Nice catch, LGTM.
--
Daniel Gustafsson
Hi,
On Wed, Jun 19, 2024 at 02:11:50PM +, Bertrand Drouvot wrote:
> To sum up, I did not see any cases that did not lead to 1. or 2., so I think
> it's safe to not add an extra lock for the RelationRelationId case. If, for
> any
> reason, there is still cases that are outside 1. or 2. then th
On Fri, Jun 21, 2024 at 12:42 PM wrote:
> Hi,
>
>
>
> Regarding the multicolumn B-Tree Index, I'm considering
>
> if we can enhance the EXPLAIN output. There have been requests
>
> for this from our customer.
>
>
>
> As the document says, we need to use it carefully.
>
> > The exact rule is that
On Fri, Jun 21, 2024 at 9:47 AM David G. Johnston
wrote:
> On Thu, Jun 20, 2024 at 9:01 AM jian he wrote:
>>
>> On Thu, Jun 20, 2024 at 5:46 PM Amit Langote wrote:
>> >
>> > On Thu, Jun 20, 2024 at 1:03 AM David G. Johnston
>> > wrote:
>> > > On Wed, Jun 19, 2024 at 8:29 AM jian he
>> > > wro
On Fri, 21 Jun 2024 at 10:46, Дмитрий Питаков wrote:
> Why not increase the buffer size?
I think changing the buffer size sounds like a reasonable idea, if
that speeds stuff up. But I think it would greatly help your case if
you showed the perf increase using a simple benchmark, especially if
peo
Hi,
On Thu, Jun 20, 2024 at 5:58 PM V N G Samba Siva Reddy Chinta <
sambasivareddychi...@gmail.com> wrote:
> Hello Team,
> Good Day,
>
> I have been working on adding a CustomScanState object in the executor
> state in my project. As part of CustomScanState, I execute queries and
> store their re
Dear Hackers,
This is a follow-up thread for pg_createsubscriber [1]. I started a new thread
since there is no activity around here.
## Problem
Assuming that there is a cascading replication like below:
node A --(logical replication)--> node B --(streaming replication)--> node C
In this case,
Hi
On Thu, 20 Jun 2024 at 21:58, Andres Freund wrote:
>
> > I don't think requiring or expecting vcpkg or conan is reasonable at all,
> > for a number of reasons:
> >
> > - Neither supports all the dependencies at present.
> > - There are real supply chain verification concerns for vendors.
> >
On 08.03.24 01:46, Tom Lane wrote:
Daniel Gustafsson writes:
On 7 Mar 2024, at 20:58, Tom Lane wrote:
This could probably do with a comment, and we need to propagate
the fix into libpq's copy of the function too. Barring objections,
I'll take care of that and push it later today.
LGTM.
On Thu, Jun 20, 2024 at 2:58 PM John Naylor wrote:
> the struct. If that's agreeable I'll commit it that way tomorrow
> unless someone beats me to it.
Pushed. I'll clear the open item once all buildfarm members have reported in.
> On 21.06.2024, at 07:38, David G. Johnston wrote:
>
> On Thursday, June 20, 2024, Markus Winand wrote:
>
>
> > On 21.06.2024, at 06:46, David G. Johnston
> > wrote:
> >>
>
> >
> > 2 also has the benefit of being standard conforming while 1 does not.
>
> Why do you think so? Do you ha
Hello, Michael!
> This is a non-fresh Friday-afternoon idea, but it would make sure that
> we don't have any transactions using the indexes switched to _ccold
> with indisvalid that are waiting for a drop in phase 5. Your tests
> seem to pass with that, and that keeps the operation intact
> concu
After initially trying to add trace support for
StartupMessage/SSLRequest/GSSENCRequest[1] I realized there were many
more cases where PQtrace was not correctly tracing messages, or not
even tracing them at all. These patches fix all of the issues that I
was able to find.
0001 is some cleanup afte
On Fri, Jun 21, 2024 at 11:11 AM David G. Johnston
wrote:
>
> On Thu, Jun 20, 2024 at 7:30 PM jian he wrote:
>>
>> "predicate check expressions return the single three-valued result of
>>
>> the predicate: true, false, or unknown."
>> "unknown" is wrong, because `select 'unknown'::jsonb;` will fa
In libpq, in the code of the lo_import function, for each piece of a file
of 8KB in size, lo_write is called, which greatly slows down the work of
lo_import because lo_write sends a request and waits for a response. The
size of 8KB is specified in define LO_BUFSIZE which changed from 1KB to 8KB
24
> On 21 Jun 2024, at 10:36, Michael Paquier wrote:
>
> On Fri, Jun 14, 2024 at 03:12:50PM -0500, Nathan Bossart wrote:
>> On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
>>> This patch looks good to me.
>>
>> Thanks for looking.
>
> While double-checking the whole, where I
Hi,
> > I'm working to start a mentoring program where code contributors can
> > be mentored by current committers. Applications are now open:
> > https://forms.gle/dgjmdxtHYXCSg6aB7
>
> This is amazing! Thank you for putting it together, Robert.
Great initiative! Thanks Rovert and to everyone in
Hi Shubham/Shlok.
FYI, there is some other documentation page that mentions generated
column replication messages.
This page [1] says:
"Next, the following message part appears for each column included in
the publication (except generated columns):"
But, with the introduction of your new feature
Hi, Here are some review comments for patch v9-0003
==
Commit Message
/fix/fixes/
==
1.
General. Is tablesync enough?
I don't understand why is the patch only concerned about tablesync?
Does it make sense to prevent VIRTUAL column replication during
tablesync, if you aren't also going t
On Tue, Jun 18, 2024 at 5:02 PM Amit Langote wrote:
>
> On Tue, Jun 4, 2024 at 7:03 PM Amit Langote wrote:
> > On Tue, Jun 4, 2024 at 2:20 AM Tom Lane wrote:
> > > Peter Eisentraut writes:
> > > > On 02.06.24 21:46, Tom Lane wrote:
> > > >> If you don't
> > > >> like our current behavior, then
57 matches
Mail list logo
