Nice approach! Thankyou Peter for the guidance.
Regards...
Yasir
On Fri, May 17, 2024 at 11:34 AM Peter Eisentraut
wrote:
> On 17.05.24 08:09, Yasir wrote:
> > I have been playing with PG on the Windows platform recently. An
> > annoying thing I faced is that a lot of Visual Studio's temp file
On 17.05.24 08:09, Yasir wrote:
I have been playing with PG on the Windows platform recently. An
annoying thing I faced is that a lot of Visual Studio's temp files kept
appearing in git changed files. Therefore, I am submitting this very
trivial patch to ignore these temp files.
Our general r
Hi Hackers,
I have been playing with PG on the Windows platform recently. An annoying
thing I faced is that a lot of Visual Studio's temp files kept appearing in
git changed files. Therefore, I am submitting this very trivial patch to
ignore these temp files.
Looking forward to the PG guru's guid
On 16.05.24 23:27, Daniel Gustafsson wrote:
On 16 May 2024, at 11:43, Peter Eisentraut wrote:
You might want to run your patch through pgperltidy. The result doesn't look
bad, but a bit different than what you had crafted.
Ugh, I thought I had but clearly had forgotten. Fixed now.
appen
On 16.05.24 16:45, Tom Lane wrote:
Peter Eisentraut writes:
In these cases, I think for
NotificationHash
ResourceOwnerData
WalSyncMethod
we can just get rid of the typedef.
I have no objection to dealing with NotificationHash as you have here.
ReadBuffersFlags shouldn't be an enum at all, b
On Fri, May 17, 2024 at 10:24:57AM +0900, Michael Paquier wrote:
> Yep. I can handle that in 2~3 hours.
And done with 110eb4aefbad. If there's anything else, feel free to
let me know.
--
Michael
signature.asc
Description: PGP signature
On 4/25/24 00:05, Robert Haas wrote:
On Tue, Apr 23, 2024 at 7:23 PM David Steele wrote:
I don't understand what you mean here. I thought we were in agreement
that verifying contents would cost a lot more. The verification that
we can actually do without much cost can only check for missing fil
On 17.05.24 04:26, Robert Haas wrote:
I do*emphatically* think we need a parking lot.
People seem to like this idea; I'm not quite sure I follow it. If you
just want the automated patch testing, you can do that on your own by
setting up github/cirrus for your own account. If you keep email
On 17.05.24 00:13, Tom Lane wrote:
So a third status that encompasses the various other situations like
maybe forgotten by author, disagreements between author and reviewer,
process difficulties, needs some senior developer intervention, etc.
could be helpful.
Hmm, "forgotten by author" seems t
The specific problem here is that LocalProcessControlFile() runs in
every launched child for EXEC_BACKEND builds. Windows uses
EXEC_BACKEND, and Windows' NTFS file system is one of the two file
systems known to this list to have the concurrent read/write data
mashing problem (the other being ext4)
Hi Kuroda-san,
I did not apply these v12* patches, but I have diff'ed all of them
with the previous v11* patches and confirmed that all of my previous
review comments now seem to be addressed.
I don't have any more comments to make at this time. Thanks!
==
Kind Regards,
Peter Smith.
Fujitsu
Hello,
I'm a hamerkop maintainer.
Sorry I have missed the scm error for so long.
Today I switched scmrepo from git.postgresql.org/git/postgresql.git
to github.com/postgres/postgres.git and successfully modernized
the build target code.
with best regards, Haruka Takatsuka
On Thu, 16 May 2024 1
On Thu, May 16, 2024 at 9:35 PM Peter Eisentraut wrote:
>
> On 04.01.24 07:53, Peter Smith wrote:
> >> Now that I read this again, I think this is wrong.
> >>
> >> We should decide the quoting for a category, not the actual content.
> >> Like, quote all file names; do not quote keywords.
> >>
> >>
On 4/16/24 18:55, Stefan Fercot wrote:
Hi,
On Sunday, March 10th, 2024 at 4:47 AM, David Steele wrote:
I've had a new idea which may revive this patch. The basic idea is to
keep backup_label but also return a copy of pg_control from
pg_stop_backup(). This copy of pg_control would be safe from t
Hackers,
This is greatly simplified implementation of the patch proposed in [1]
and hopefully it addresses the concerns expressed there. Since the
implementation is quite different it seemed like a new thread was
appropriate, especially since the old thread title would be very
misleading rega
On Thu, May 16, 2024 at 5:46 PM Tom Lane wrote:
> Right, so what can we do about that? Does Needs Review state need to
> be subdivided, and if so how?
It doesn't really matter how many states we have if they're not set accurately.
> At this point it seems like there's consensus to have a "parki
Hi, Here are my remaining review comments for the latest v11* patches.
//
v11-0001
//
No changes. No comments.
//
v11-0002
//
==
doc/src/sgml/ref/alter_subscription.sgml
2.1.
ALTER SUBSCRIPTION ... SET (failover = on|off) and
- ALTER SUBSCRIPTION ... S
On Thu, May 16, 2024 at 04:37:10PM +, Imseih (AWS), Sami wrote:
> I thought 256 was a good enough limit. In practice, I doubt anyone will
> benefit from more than a few dozen autovacuum workers.
> I think 1024 is way too high to even allow.
WFM
> I don't think combining 1024 + 5 = 1029 is a
On Tue, Apr 16, 2024 at 4:10 AM Robert Haas wrote:
> On Wed, Apr 10, 2024 at 9:55 PM Thomas Munro wrote:
> > To rescue my initdb --rel-segsize project[1] for v18, I will have a go
> > at making that dynamic. It looks like we don't actually need to
> > allocate that until we get to the GetFileBac
Here is a rebased version of 0002, which I intend to commit once v18
development begins.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From e9cba5e4303c7fa5ad2d7d5deb23fe0b1c740b09 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 7 May 2024 14:35:34 -0500
Subject: [PATCH
On Thu, May 16, 2024 at 09:09:36PM -0400, Tom Lane wrote:
> WFM, and this is probably a place where we don't want to change the
> API in v17 and again in v18, so I agree with pushing now.
>
> Reminder though: beta1 release freeze begins Saturday.
> Not many hours left.
Yep. I can handle that in 2
On Thu, May 16, 2024 at 05:09:55PM -0700, Jeff Davis wrote:
> How much complexity do you avoid by using async instead of multiple
> processes?
If we didn't want to use async, my guess is we'd want to use threads to
avoid complicated IPC. And if we followed pgbench's example for using
threads, it
On Thu, May 16, 2024 at 03:54:52PM -0700, Jeff Davis wrote:
> On Mon, 2024-05-13 at 11:15 +1200, Thomas Munro wrote:
>> Perhaps a no-image, no-change registered buffer should not be
>> including an image, even for XLR_CHECK_CONSISTENCY? It's
>> actually
>> useless for consistency c
Michael Paquier writes:
> On Thu, May 16, 2024 at 10:45:18AM -0400, Tom Lane wrote:
>> ... I think the enum should be nuked altogether, but
>> it's a bit late to be redesigning that for v17 perhaps.
> You're right, WaitEventExtension is better gone. The only thing that
> matters is that we want
On Thu, May 16, 2024 at 10:45:18AM -0400, Tom Lane wrote:
> I am also quite confused by that. It seems to be kind of an enum
> that is supposed to be extended at runtime, meaning that neither
> of the existing enum member values ought to be used as such, although
> either autoprewarm.c didn't get
On Tue, May 14, 2024 at 09:52:35AM -0400, Robert Haas wrote:
> We are down to three open items, all of which have proposed fixes.
> That is great, but we need to keep things moving along, because
> according to https://wiki.postgresql.org/wiki/PostgreSQL_17_Open_Items
> we are due to release beta1
On Thu, 2024-05-16 at 16:16 -0500, Nathan Bossart wrote:
> I am posting this early to get thoughts on the general approach. If
> we
> proceeded with this strategy, I'd probably create some generic
> tooling that
> each relevant step would provide a set of callback functions.
The documentation sta
On Thu, May 16, 2024 at 08:41:11AM +0200, Peter Eisentraut wrote:
> On this specific patch, maybe reword "parameter too large" to "parameter
> number too large".
WFM here.
> Also, I was bemused by the use of atol(), which is notoriously unportable
> (sizeof(long)). So I poked around and found mo
On Thu, May 16, 2024 at 09:00:47AM +0530, Amit Kapila wrote:
> This can only be a problem if the apply worker generates more LOG
> entries with the required context but it won't do that unless there is
> an operation on the publisher to replicate. If we see any such danger
> then I agree this can b
On Thu, May 16, 2024 at 4:11 PM Michael Paquier wrote:
> On Thu, May 16, 2024 at 11:57:10AM +0300, Aleksander Alekseev wrote:
> > I propose my original v1 patch for correcting the --help output of
> > 'postgres' too. I agree with the above comments that corresponding
> > changes in v4 became some
On Mon, 2024-05-13 at 12:11 +0200, Peter Eisentraut wrote:
> Some of these issues might be design flaws in the underlying
> mechanisms,
> like range types and exclusion constraints. Like, if you're supposed
> to
> use this for scheduling but you can use empty ranges to bypass
> exclusion
> cons
On Thu, May 16, 2024 at 11:57:10AM +0300, Aleksander Alekseev wrote:
> I propose my original v1 patch for correcting the --help output of
> 'postgres' too. I agree with the above comments that corresponding
> changes in v4 became somewhat unwieldy.
Thanks for compiling the rest.
-printf(_("
On Thu, May 16, 2024 at 10:42 PM David Rowley wrote:
>
> On Thu, 16 May 2024 at 19:05, Peter Smith wrote:
> >
> > On Thu, May 16, 2024 at 3:11 PM David Rowley wrote:
> > > If you want to do this, what's the reason to limit it to just this one
> > > page of the docs?
> >
> > Yeah, I had a vested
On Fri, May 17, 2024 at 3:17 AM Nazir Bilal Yavuz wrote:
> Actually, 32 bit builds are working but the Perl version needs to be
> updated to 'perl5.36-i386-linux-gnu' in .cirrus.tasks.yml. I changed
> 0001 with the working version of 32 bit builds [1] and the rest is the
> same. All tests pass now
On Mon, 2024-05-13 at 11:15 +1200, Thomas Munro wrote:
> > > > > Perhaps a no-image, no-change registered buffer should not be
> > > > > including an image, even for XLR_CHECK_CONSISTENCY? It's
> > > > > actually
> > > > > useless for consistency checking too I guess, this issue
> > > > > aside,
>
On Wed, May 15, 2024 at 11:25:34AM -0400, Robert Haas wrote:
> I think that we need to get a more definitive answer to the question
> of whether command-line editing works or not. I have the impression
> that it never has. If it's started working, we should establish that
> for certain and probably
On Thu, May 16, 2024 at 5:04 PM Tom Lane wrote:
>
> Jacob Champion writes:
> > ... Similar to how people currently use the
> > Reviewer field as a personal TODO list... it might be nice to
> > officially separate the ideas a bit.
>
> Oh, that's an independent pet peeve of mine. Usually, if I'm
>
Peter Eisentraut writes:
> On 16.05.24 23:46, Tom Lane wrote:
>> Right, so what can we do about that? Does Needs Review state need to
>> be subdivided, and if so how?
> Maybe a new state "Unclear". ...
> I think, if we consider the core mission of the commitfest app, we need
> to be more prote
On 16.05.24 23:46, Tom Lane wrote:
Peter Eisentraut writes:
The problem is if we have 180 patches in Needs Review, and only 20 are
really actually ready to be reviewed. And a second-order problem is
that if you already know that this will be the case, you give up before
even looking.
Right,
Daniel Gustafsson writes:
> Pulling in the information from the CFBot regarding test failures and whether
> the patch applies at all, and automatically altering the state to WOA for at
> least the latter category would be nice.
+1. There are enough intermittent test failures that I don't think
c
On 5/16/24 17:36, Jacob Champion wrote:
On Thu, May 16, 2024 at 2:29 PM Joe Conway wrote:
If no one, including the author (new or otherwise) is interested in
shepherding a particular patch, what chance does it have of ever getting
committed?
That's a very different thing from what I think wil
> On 16 May 2024, at 23:46, Tom Lane wrote:
> At this point it seems like there's consensus to have a "parking"
> section of the CF app, separate from the time-boxed CFs, and I hope
> somebody will go make that happen. But I don't think that's our only
> issue, so we need to keep thinking about
Peter Eisentraut writes:
> The problem is if we have 180 patches in Needs Review, and only 20 are
> really actually ready to be reviewed. And a second-order problem is
> that if you already know that this will be the case, you give up before
> even looking.
Right, so what can we do about that
On Thu, May 16, 2024 at 2:04 PM Tom Lane wrote:
> Oh, that's an independent pet peeve of mine. Usually, if I'm
> looking over the CF list for a patch to review, I skip over ones
> that already show an assigned reviewer, because I don't want to
> step on that person's toes. But it seems very comm
On 16.05.24 23:06, Joe Conway wrote:
On 5/16/24 16:57, Jacob Champion wrote:
On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
Maybe we should just make it a policy that *nothing* gets moved forward
from commitfest-to-commitfest and therefore the author needs to care
enough to register for the
On 16.05.24 23:04, Tom Lane wrote:
I think it'd be great if we could separate "I'm actively reviewing
this" from "I'm interested in this". As a bonus, adding yourself
to the "interested" list would be a fine proxy for the thumbs-up
or star markers mentioned upthread.
If those were separate colu
On Thu, May 16, 2024 at 2:29 PM Joe Conway wrote:
> If no one, including the author (new or otherwise) is interested in
> shepherding a particular patch, what chance does it have of ever getting
> committed?
That's a very different thing from what I think will actually happen, which is
- new aut
On 16.05.24 22:46, Melanie Plageman wrote:
I was reflecting on why a general purpose patch tracker sounded
appealing to me, and I realized that, at least at this time of year, I
have a few patches that really count as "waiting on author" that I
know I need to do additional work on before they nee
Andrew Dunstan writes:
> On 2024-05-16 Th 17:15, Tom Lane wrote:
>> I'd rather have some visible status on the BF dashboard. Invariably,
>> with a problem like this, the animal's owner is unaware there's a
>> problem. If it's just silently not reporting, then no one else will
>> notice either, a
On 5/16/24 17:24, Jacob Champion wrote:
On Thu, May 16, 2024 at 2:06 PM Joe Conway wrote:
Maybe the word "care" was a poor choice, but forcing authors to think
about and decide if they have the "time to shepherd a patch" for the
*next CF* is exactly the point. If they don't, why clutter the CF
> On 16 May 2024, at 11:43, Peter Eisentraut wrote:
> You might want to run your patch through pgperltidy. The result doesn't look
> bad, but a bit different than what you had crafted.
Ugh, I thought I had but clearly had forgotten. Fixed now.
> append_conf() opens and closes the file for eac
On 2024-05-16 Th 17:15, Tom Lane wrote:
Andrew Dunstan writes:
On 2024-05-16 Th 16:18, Tom Lane wrote:
Andrew: maybe the buildfarm server could be made to flag
animals building exceedingly old commits? This is the second
problem of this sort that I've noticed this month, and you
really have
On Thu, May 16, 2024 at 2:06 PM Joe Conway wrote:
> Maybe the word "care" was a poor choice, but forcing authors to think
> about and decide if they have the "time to shepherd a patch" for the
> *next CF* is exactly the point. If they don't, why clutter the CF with it.
Because the community regul
On Tue, Apr 30, 2024 at 09:10:52AM +0530, Amit Kapila wrote:
> On Tue, Apr 30, 2024 at 2:58 AM Noah Misch wrote:
> > On Mon, Apr 29, 2024 at 10:18:35AM +0530, Amit Kapila wrote:
> > > 3a9b18b309 didn't change the docs of pg_terminate_backend and whatever
> > > is mentioned w.r.t permissions in the
A number of pg_upgrade steps require connecting to each database and
running a query. When there are many databases, these steps are
particularly time-consuming, especially since this is done sequentially in
a single process. At a quick glance, I see the following such steps:
* create_lo
On Thu, May 16, 2024 at 1:46 PM Melanie Plageman
wrote:
>
> I should probably simply
> withdraw and re-register them. My justification was that I'll lose
> them if I don't keep them in the commitfest app. But, I could just,
> you know, save them somewhere myself instead of polluting the
> commitf
Andrew Dunstan writes:
> On 2024-05-16 Th 16:18, Tom Lane wrote:
>> Andrew: maybe the buildfarm server could be made to flag
>> animals building exceedingly old commits? This is the second
>> problem of this sort that I've noticed this month, and you
>> really have to look closely to realize it's
On 5/16/24 16:48, Magnus Hagander wrote:
On Thu, May 16, 2024 at 10:46 PM Melanie Plageman
I was reflecting on why a general purpose patch tracker sounded
appealing to me, and I realized that, at least at this time of year, I
have a few patches that really count as "waiting on author
Jacob Champion writes:
> On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
>> Maybe we should just make it a policy that *nothing* gets moved forward
>> from commitfest-to-commitfest and therefore the author needs to care
>> enough to register for the next one?
> I think that's going to severely
On 2024-05-16 Th 16:18, Tom Lane wrote:
Thomas Munro writes:
For citext_utf8, I pushed cff4e5a3. Hamerkop runs infrequently, so
here's hoping for 100% green on master by Tuesday or so.
Meanwhile, back at the ranch, it doesn't seem that changed anything:
https://buildfarm.postgresql.org/cgi
On 5/16/24 16:57, Jacob Champion wrote:
On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
Maybe we should just make it a policy that *nothing* gets moved forward
from commitfest-to-commitfest and therefore the author needs to care
enough to register for the next one?
I think that's going to s
Jacob Champion writes:
> ... Similar to how people currently use the
> Reviewer field as a personal TODO list... it might be nice to
> officially separate the ideas a bit.
Oh, that's an independent pet peeve of mine. Usually, if I'm
looking over the CF list for a patch to review, I skip over one
On Thu, 16 May 2024 at 18:57, Robert Haas wrote:
> Ugh, it's so hard to communicate clearly about this stuff. I didn't
> really have any thought that we'd ever try to handle something as
> complicated as compression using ParameterSet.
Okay, then it's definitely very hard to communicate clearly a
Hi,
On 5/16/24 4:31 PM, Joe Conway wrote:
Yeah. I think that Robert put his finger on a big part of the
problem, which is that punting a patch to the next CF is a lot
easier than rejecting it, particularly for less-senior CFMs
who may not feel they have the authority to say no (or at
least doub
On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
> Maybe we should just make it a policy that *nothing* gets moved forward
> from commitfest-to-commitfest and therefore the author needs to care
> enough to register for the next one?
I think that's going to severely disadvantage anyone who doesn'
Hi,
In the subthread at [1] I needed to trigger multiple rounds of index vacuuming
within one vacuum.
It turns out that with the new dead tuple implementation, that got actually
somewhat expensive. Particularly if all tuples on all pages get deleted, the
representation is just "too dense". Normal
On Thu, May 16, 2024 at 1:46 PM Melanie Plageman
wrote:
> I should probably simply
> withdraw and re-register them. My justification was that I'll lose
> them if I don't keep them in the commitfest app. But, I could just,
> you know, save them somewhere myself instead of polluting the
> commitfest
Melanie Plageman writes:
> I was reflecting on why a general purpose patch tracker sounded
> appealing to me, and I realized that, at least at this time of year, I
> have a few patches that really count as "waiting on author" that I
> know I need to do additional work on before they need more revi
On Thu, May 16, 2024 at 12:14 PM David G. Johnston
wrote:
> Those likely never get out of the new WIP slot discussed above. Your patch
> tracker basically. And there should be less angst in moving something in the
> bimonthly into WIP rather than dropping it outright. There is discussion to
On Thu, May 16, 2024 at 10:46 PM Melanie Plageman
wrote:
> On Thu, May 16, 2024 at 2:30 PM Robert Haas wrote:
> >
> > Hi,
> >
> > The original intent of CommitFests, and of commitfest.postgresql.org
> > by extension, was to provide a place where patches could be registered
> > to indicate that t
On Thu, May 16, 2024 at 2:30 PM Robert Haas wrote:
>
> Hi,
>
> The original intent of CommitFests, and of commitfest.postgresql.org
> by extension, was to provide a place where patches could be registered
> to indicate that they needed to be reviewed, thus enabling patch
> authors and patch review
> I'm unsure if it needs to call ExecutorStart in the bind code. But if we
> don't change the current logic, would it make more sense to move
> pgstat_report_query_id to the ExecutorRun routine?
I initially thought about that, but for utility statements (CTAS, etc.) being
executed with extended q
On 5/16/24 15:47, Tom Lane wrote:
Daniel Gustafsson writes:
On 16 May 2024, at 20:30, Robert Haas wrote:
The original intent of CommitFests, and of commitfest.postgresql.org
by extension, was to provide a place where patches could be registered
to indicate that they needed to be reviewed, thus
Daniel Gustafsson writes:
> On 16 May 2024, at 13:35, Peter Eisentraut wrote:
>> - errmsg("WAL generated with full_page_writes=off was replayed "
>> + errmsg("WAL generated with \"full_page_writes=off\" was replayed "
> I'm not a fan of this syntax, but I at the same time can't offer a better i
Thomas Munro writes:
> For citext_utf8, I pushed cff4e5a3. Hamerkop runs infrequently, so
> here's hoping for 100% green on master by Tuesday or so.
Meanwhile, back at the ranch, it doesn't seem that changed anything:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2024-05-1
Hi,
I built a gist index to try to test a theory in some other thread. For that
the indexes need to cover a lot of entries. With gist creating the index took
a long time, which made me strace the index build process.
Which lead me to notice this:
...
openat(AT_FDCWD, "base/16462/17747_fsm", O_RD
When I was CFM for a couple cycles I started with the idea that I was going
to try being a hardass and rejecting or RWF all the patches that had gotten
negative reviews and been bounced forward.
Except when I actually went through them I didn't find many. Mostly like
Robert I found perfectly reaso
> On 16 May 2024, at 13:56, Alvaro Herrera wrote:
> I think we should also take patch 0005 in pg17, which reduces the number
> of strings to translate.
Agreed, lessening the burden on translators is always a good idea.
--
Daniel Gustafsson
> On 16 May 2024, at 13:35, Peter Eisentraut wrote:
> I think we should accept your two patches
I agree with this.
> v6-0001-GUC-names-docs.patch
+1
> v6-0002-GUC-names-add-quotes.patch
- errmsg("WAL generated with full_page_writes=off was replayed "
+ errmsg("WAL generated with \"full_page_
Daniel Gustafsson writes:
>> On 16 May 2024, at 20:30, Robert Haas wrote:
>> The original intent of CommitFests, and of commitfest.postgresql.org
>> by extension, was to provide a place where patches could be registered
>> to indicate that they needed to be reviewed, thus enabling patch
>> author
> On 16 May 2024, at 20:30, Robert Haas wrote:
> The original intent of CommitFests, and of commitfest.postgresql.org
> by extension, was to provide a place where patches could be registered
> to indicate that they needed to be reviewed, thus enabling patch
> authors and patch reviewers to find e
Thanks for raising this. As someone who is only modestly familiar with
Postgres internals or even C, but would still like to contribute through
review, I find the current process of finding a suitable patch both tedious
and daunting. The Reviewing a Patch article on the wiki [0] says reviews
like m
On Thu, May 16, 2024 at 11:30 AM Robert Haas wrote:
> Hi,
>
> The original intent of CommitFests, and of commitfest.postgresql.org
> by extension, was to provide a place where patches could be registered
> to indicate that they needed to be reviewed, thus enabling patch
> authors and patch review
Op 5/16/24 om 20:30 schreef Robert Haas:
Hi,
The original intent of CommitFests, and of commitfest.postgresql.org
by extension, was to provide a place where patches could be registered
to indicate that they needed to be reviewed, thus enabling patch
authors and patch reviewers to find each other
Hi,
On 2024-05-16 15:01:31 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-05-16 14:50:50 -0400, Tom Lane wrote:
> >> The intention was certainly always that it be atomic. If it isn't
> >> we have got *big* trouble.
>
> > We unfortunately do *know* that on several systems e.g. baseba
Andres Freund writes:
> On 2024-05-16 14:50:50 -0400, Tom Lane wrote:
>> The intention was certainly always that it be atomic. If it isn't
>> we have got *big* trouble.
> We unfortunately do *know* that on several systems e.g. basebackup can read a
> partially written control file, while the con
On Wed, 2024-05-15 at 16:31 -0700, Jeff Davis wrote:
> Even better would be if we could take into account partitioning. That
> might be out of scope for your current work, but it would be very
> useful. We could have a couple new GUCs like modify_table_buffer and
> modify_table_buffer_per_partition
Hi,
On 2024-05-16 14:50:50 -0400, Tom Lane wrote:
> Nathan Bossart writes:
> > I suspect it will be difficult to investigate this one too much further
> > unless we can track down a copy of the control file with the bad checksum.
> > Other than searching for any new code that isn't doing the appr
Nathan Bossart writes:
> I suspect it will be difficult to investigate this one too much further
> unless we can track down a copy of the control file with the bad checksum.
> Other than searching for any new code that isn't doing the appropriate
> locking, maybe we could search the buildfarm for
On Thu, May 16, 2024 at 12:19:22PM -0400, Melanie Plageman wrote:
> Today, after committing a3e6c6f, I saw recovery/018_wal_optimize.pl
> fail and see this message in the replica log [2].
>
> 2024-05-16 15:12:22.821 GMT [5440][not initialized] FATAL: incorrect
> checksum in control file
>
> I'm
Hi,
The original intent of CommitFests, and of commitfest.postgresql.org
by extension, was to provide a place where patches could be registered
to indicate that they needed to be reviewed, thus enabling patch
authors and patch reviewers to find each other in a reasonably
efficient way. I don't thi
On Thu, 2024-05-16 at 05:25 -0400, Corey Huinker wrote:
>
> Per previous comments, it was suggested by others that:
>
> - having them in SECTION_NONE was a grave mistake
> - Everything that could belong in SECTION_DATA should, and the rest
> should be in SECTION_POST_DATA
I don't understand the
Daniel Gustafsson writes:
>> On 5 Jul 2022, at 18:59, Tom Lane wrote:
>> Given the lack of field complaints, it's probably not worth trying
>> to do anything to restore that capability. But we really ought to
>> update pg_upgrade's code and docs in pre-v15 branches to say that
>> the minimum sup
On Thu, May 16, 2024 at 6:57 AM Robert Haas wrote:
>
> Ugh, it's so hard to communicate clearly about this stuff. I didn't
> really have any thought that we'd ever try to handle something as
> complicated as compression using ParameterSet. I tend to agree that
> for compression I'd like to see the
On Thu, May 16, 2024 at 12:09 PM Jelte Fennema-Nio wrote:
> I don't really understand the benefit of your proposal over option 2
> that I proposed. Afaict you're proposing that for e.g. compression we
> first set _pq_.supports_compression=1 in the StartupMessage and use
> that to do feature detec
Peter Smith writes:
> Yeah, I had a vested interest in this one place because I've been
> reviewing the other thread [1] that was mentioned above. If that other
> thread chooses "true|false" then putting "true|false" adjacent to
> another "on|off" will look silly. But if that other thread adopts t
>>> That's true, but using a hard-coded limit means we no longer need to add a
>>> new GUC. Always allocating, say, 256 slots might require a few additional
>>> kilobytes of shared memory, most of which will go unused, but that seems
>>> unlikely to be a problem for the systems that will run Postgr
> On Tue, May 14, 2024 at 11:09:39AM -0400, Robert Haas wrote:
> On Tue, Apr 9, 2024 at 8:44 PM Thomas Munro wrote:
> > I pushed the illegal attribute fix though. Thanks for the detective work!
>
> This was commit 53c8d6c9f157f2bc8211b8de02417e55fefddbc7 and as I
> understand it that fixed the is
On Sun, Jun 7, 2020 at 10:49 PM Thomas Munro wrote:
>
> On Wed, Jun 3, 2020 at 2:03 PM Michael Paquier wrote:
> > On Wed, Jun 03, 2020 at 10:56:13AM +1200, Thomas Munro wrote:
> > > Sorry for my radio silence, I got tangled up with a couple of
> > > conferences. I'm planning to look at 0001 and
On Thu, 16 May 2024 at 17:29, Robert Haas wrote:
> You're probably not going to like this answer, but I feel like this is
> another sign that you're trying to use the protocol extensibility
> facilities in the wrong way. In my first reply to the thread, I
> proposed having the client send _pq_.pro
1 - 100 of 150 matches
Mail list logo
