Thanks for the patch.
I tested the v6 patch using the test script attached on [1], old primary
has succeeded to become new standby.
I have very minor questions on the regression tests mainly regarding the
consistency with other tests for pg_rewind:
+setup_cluster;
+create_standby;
Would
On Fri, Oct 13, 2023 at 6:18 PM Andrei Lepikhov
wrote:
> On 23/8/2023 12:37, Richard Guo wrote:
> > To fix it we may need to modify RelOptInfos for Path, BitmapHeapPath,
> > ForeignPath and CustomPath, and modify IndexOptInfos for IndexPath. It
> > seems that that is not easily done without post
On Wed, Oct 18, 2023 at 02:59:52AM +, Hayato Kuroda (Fujitsu) wrote:
> While discussing [1], I found that in tap tests, wal_level was set to logical
> for
> subscribers too. The setting is not needed for subscriber side, and it may
> cause
> misunderstanding for newcomers. Therefore, I wanted
On Thu, Oct 12, 2023 at 04:46:02PM -0700, Andres Freund wrote:
> The machine skink is hosted on runs numerous buildfarm animals (24 I think
> right now, about to be 28). While it has plenty resources (16 cores/32
> threads, 128GB RAM), test runtime is still pretty variable depending on what
> other
On 10.10.23 10:03, Peter Eisentraut wrote:
On 09.10.23 11:20, Alvaro Herrera wrote:
I tried this out. I agree it's a good change. BTW, this made me
realize that "unlike" is not a good name: maybe it should be called
"except".
right
I would add quotes to the words "like" and "unlike" there.
On 2023-10-16 18:46, Ashutosh Bapat wrote:
On Thu, Oct 12, 2023 at 6:51 PM torikoshia
wrote:
On 2023-10-11 16:22, Ashutosh Bapat wrote:
>
> Considering the similarity with auto_explain I wondered whether this
> function should be part of auto_explain contrib module itself? If we
> do that user
Here are some comments for the patch v51-0002
==
src/bin/pg_upgrade/t/003_upgrade_logical_replication_slots.pl
1.
+# Set max_wal_senders to a lower value if the old cluster is prior to PG12.
+# Such clusters regard max_wal_senders as part of max_connections, but the
+# current TAP tester sets
On Tue, Oct 17, 2023 at 04:44:25PM +0300, Nazir Bilal Yavuz wrote:
> I updated patches based on your comments. v4 is attached.
Thanks for the new versions. I have applied 0001 and backpatched it
for now. 0002 and 0003 look in much cleaner shape than previously.
--
Michael
signature.asc
Descrip
On 18/10/2023 12:15, Tom Lane wrote:
Andrei Lepikhov writes:
"SET foo.bar TO 'smth'" can immediately alter the placeholder's value.
But what is the reason that "ALTER SYSTEM SET foo.bar TO 'smth'" doesn't
do the same?
Because it's not supposed to take effect until you issue a reload
command (
On 17/10/2023 17:09, Ashutosh Bapat wrote:
On Tue, Oct 17, 2023 at 2:05 PM Andrei Lepikhov
wrote:
On 16/10/2023 23:21, Ashutosh Bapat wrote:
On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov
Whenever I visited this idea, I hit one issue prominently - how would
we differentiate different scans
Andrei Lepikhov writes:
> "SET foo.bar TO 'smth'" can immediately alter the placeholder's value.
> But what is the reason that "ALTER SYSTEM SET foo.bar TO 'smth'" doesn't
> do the same?
Because it's not supposed to take effect until you issue a reload
command (and maybe not even then, dependin
On 17/10/2023 07:19, Tom Lane wrote:
Currently we have this odd behavior (for a superuser):
regression=# ALTER SYSTEM SET foo.bar TO 'baz';
ERROR: unrecognized configuration parameter "foo.bar"
regression=# SET foo.bar TO 'baz';
SET
regression=# ALTER SYSTEM SET foo.bar TO 'baz';
ALTER SYSTEM
On Tue, Oct 17, 2023 at 9:06 PM Drouvot, Bertrand
wrote:
>
> On 10/13/23 10:35 AM, shveta malik wrote:
> > On Thu, Oct 12, 2023 at 9:18 AM shveta malik wrote:
> >>
>
> Code:
>
> + True if this logical slot is enabled to be synced to the physical
> standbys
> + so that logical replica
On Tue, Oct 17, 2023 at 9:06 PM Drouvot, Bertrand
wrote:
>
> Hi,
>
> On 10/13/23 10:35 AM, shveta malik wrote:
> > On Thu, Oct 12, 2023 at 9:18 AM shveta malik wrote:
> >>
> >
> > PFA v24 patch set which has below changes:
> >
> > 1) 'enable_failover' displayed in pg_replication_slots.
> > 2) Sup
On Wed, 18 Oct 2023 at 01:47, Robert Haas wrote:
> On Sat, Aug 12, 2023 at 5:53 PM Peter Geoghegan wrote:
> > This policy isn't working.
>
> +1. I think this is more annoying than the status quo ante.
Maybe there are two camps of committers here; ones who care about
committing correctly indented
=?utf-8?B?6YKx5a6H6Iiq?= writes:
> I wrote a script and test on branch REL_[10-16]_STABLE, and do see
> performance drop in REL_13_STABLE, which is about 1~2%.
I'm really skeptical that we should pay much attention to these numbers.
You've made several of the mistakes that we typically tell peop
Hi,
On 2023-10-16 11:04:25 +0300, Anton A. Melnikov wrote:
> On 13.10.2023 05:05, Andres Freund wrote:
> > Could you provide a bit more details about how you ran the benchmark? The
> > reason I am asking is that ~330 TPS is pretty slow for -c20. Even on
> > spinning
> > rust and using the defau
On Tue, Oct 17, 2023 at 11:57:33AM +0530, Amit Kapila wrote:
> LGTM.
Thanks, I've applied that, then.
--
Michael
signature.asc
Description: PGP signature
I wrote a script and test on branch REL_[10-16]_STABLE, and do see performance
drop in REL_13_STABLE, which is about 1~2%.
scale round 10 11 12 13 14 15 16
1 1 7922.2 8018.3 8102.8 7838.3 7829.2 7870.0 7846.1
2 7922.4 7923.5 8090
On Wed, Oct 18, 2023 at 7:31 AM Peter Smith wrote:
>
> ==
> src/bin/pg_upgrade/check.c
>
> 0.
> +check_old_cluster_for_valid_slots(bool live_check)
> +{
> + char output_path[MAXPGPATH];
> + FILE*script = NULL;
> +
> + prep_status("Checking for valid logical replication slots");
> +
> + snp
Thomas Munro writes:
> On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote:
>> Should we be testing against xlclang instead?
> I hesitated to suggest it because it's not my animal/time we're
> talking about but it seems to make more sense. It appears to be IBM's
> answer to the nothing-builds-with-
Dear hackers,
While discussing [1], I found that in tap tests, wal_level was set to logical
for
subscribers too. The setting is not needed for subscriber side, and it may cause
misunderstanding for newcomers. Therefore, I wanted to propose the patch which
removes unnecessary "allows_streaming =>
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Tue, 2023-10-17 at 16:20 -0400, Stephen Frost wrote:
> > Agreed that it's a bad idea to design to support 2 and only 2.
>
> I don't disagree, but it's difficult to come up with syntax that:
>
> (a) supports N passwords
> (b) makes the ord
Hello.
I've been unable to build PostgreSQL using Meson on Windows. As I'm
unsure of the cause, I'm providing this as a report.
In brief, the ninja command fails with the following error message on
my Windows environment.
>ninja -v
ninja: error: 'src/backend/postgres_lib.a.p/meson_pch-c.obj', ne
Hi.
based on v22.
I added some tests again json_value for the sake of coverager test.
A previous email thread mentioned needing to check *empty in ExecEvalJsonExpr.
since JSON_VALUE_OP, JSON_QUERY_OP, JSON_EXISTS_OP all need to have
*empty cases, So I refactored a little bit.
might be helpful. Ma
At Tue, 17 Oct 2023 16:16:42 -0400, David Steele wrote in
> Given that the above can't be back patched, I'm thinking we don't need
> backup_label at all going forward. We just write the values we need
> for recovery into pg_control and return *that* from pg_backup_stop()
> and tell the user to st
Here are some review comments for v51-0001
==
src/bin/pg_upgrade/check.c
0.
+check_old_cluster_for_valid_slots(bool live_check)
+{
+ char output_path[MAXPGPATH];
+ FILE*script = NULL;
+
+ prep_status("Checking for valid logical replication slots");
+
+ snprintf(output_path, sizeof(output_
On Tue, Oct 17, 2023 at 12:45:52PM -0400, Robert Haas wrote:
> On Fri, Oct 13, 2023 at 3:29 AM Michael Paquier wrote:
>> I've mentioned as well a test in pg_walinspect after one of the
>> checkpoints generated there, but what you do here is enough for the
>> online case.
>
> I don't quite underst
On Tue, Oct 17, 2023 at 12:45:28PM -0400, Tom Lane wrote:
> Whoops, no: for negative starting values we'd need truncate-towards-
> minus-infinity division whereas C99 specifies truncate-towards-zero.
> However, the attached does pass for me on cfarm111 as well as my
> usual dev machine.
I guess th
On Tue, 2023-10-17 at 16:20 -0400, Stephen Frost wrote:
> Agreed that it's a bad idea to design to support 2 and only 2.
I don't disagree, but it's difficult to come up with syntax that:
(a) supports N passwords
(b) makes the ordinary cases simple and documentable
(c) helps users avoid mistake
Thomas Munro writes:
> On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote:
>> Should we be testing against xlclang instead?
> I hesitated to suggest it because it's not my animal/time we're
> talking about but it seems to make more sense. It appears to be IBM's
> answer to the nothing-builds-with-
On Wed, Oct 18, 2023 at 11:54 AM Tom Lane wrote:
> Thomas Munro writes:
>
> > Given that IBM describes xlc as "legacy" (replaced by xlclang, but
> > still supported for some unspecified period of time for the benefit of
> > people who need C++ ABI compatibility with old code), I wonder how
> > lo
Thomas Munro writes:
> Given that IBM describes xlc as "legacy" (replaced by xlclang, but
> still supported for some unspecified period of time for the benefit of
> people who need C++ ABI compatibility with old code), I wonder how
> long we plan to support it...
Should we be testing against xlc
Hmm, I guess I must have missed some important flag or environment
variable when trying to reproduce it, sorry.
Given that IBM describes xlc as "legacy" (replaced by xlclang, but
still supported for some unspecified period of time for the benefit of
people who need C++ ABI compatibility with old c
On Tue, Oct 17, 2023 at 12:47:29PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> ... and it looks like some of the back-branches are failing for Windows.
>> I'm assuming this is because c290e79 was only back-patched to v15. My
>> first instinct is just to back-patch that one all the way to v
I wrote:
> Why are we marking extension member objects as being subject to SECLABEL
> or POLICY dumping? As the comment notes, that isn't really sensible
> unless what we are dumping is a delta from the extension's initial
> assignments. But we have no infrastructure for that, and none seems
> li
Magnus Hagander writes:
> If it doesn't know how to rebuild it, aren't we going to be stuck in a
> catch-22 if we need to change it in certain ways? Since an old version
> of pg_bsd_indent would reject the patch that might include updating
> it. (And when it does, one should expect the push to tak
On Tue, Oct 17, 2023 at 10:43 PM Jelte Fennema wrote:
>
> On Tue, 17 Oct 2023 at 18:53, Maciek Sakrejda wrote:
> > Git push does have an --atomic flag to treat the entire push as a single
> > operation.
>
> I decided to play around a bit with server hooks. Attached is a git
> "update" hook that
On Tue, 17 Oct 2023 at 18:53, Maciek Sakrejda wrote:
> Git push does have an --atomic flag to treat the entire push as a single
> operation.
I decided to play around a bit with server hooks. Attached is a git
"update" hook that rejects pushes to the master branch when the new
HEAD of master does
Hi,
Here's a couple cleaned-up patches fixing the various discussed here.
I've tried to always add a regression test demonstrating the issue
first, and then fix it in the next patch.
In particular, this deals with these issues:
1) overflows in distance calculation for large timestamp values (000
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> On Wed, Oct 04, 2023 at 10:41:15PM -0700, Gurjeet Singh wrote:
> > The patches posted in this thread so far attempt to add the ability to
> > allow the user to have an arbitrary number of passwords. I believe
> > that allowing arbitra
On 10/14/23 11:30, David Steele wrote:
On 10/12/23 10:19, David Steele wrote:
On 10/11/23 18:10, Thomas Munro wrote:
As Stephen mentioned[1], we could perhaps also complain if both backup
label and control file exist, and then hint that the user should
remove the *control file* (not the backup
Jacob Champion writes:
> v3 fixes a doc comment I forgot to fill in; there are no other code
> changes. To try to further reduce the activation energy, I've also
> attached an attempt at a backport to 11. The main difference is the
> absence of catalogIdHash, which showed up in 15, so we don't get
On Tue, Oct 17, 2023 at 3:17 PM Stephen Frost wrote:
> I'd also put out there that while people don't do restore testing
> nearly as much as they should, they tend to at _least_ try to do it once
> after taking their first backup and if that fails then they try to figure
> out why and what they're
On Tue, Oct 17, 2023 at 12:30 PM David Steele wrote:
> On 10/17/23 14:28, Robert Haas wrote:
> > On Mon, Oct 16, 2023 at 5:21 PM David G. Johnston
> > wrote:
> >> But no, by default, and probably so far as pg_basebackup is concerned,
> a server crash during backup results in requiring outside in
On Thu, Oct 12, 2023 at 4:13 AM Andres Freund wrote:
>
> On 2023-10-03 16:05:32 -0700, Jeff Davis wrote:
> >
> > Does this patch still look like a good fit for your (or someone else's)
> > plans for direct IO here? If so, would committing this soon make it
> > easier to make progress on that, or s
On 10/17/23 14:28, Robert Haas wrote:
On Mon, Oct 16, 2023 at 5:21 PM David G. Johnston
wrote:
But no, by default, and probably so far as pg_basebackup is concerned, a server
crash during backup results in requiring outside intervention in order to get
the server to restart.
Others may diff
Greetings,
* David Steele (da...@pgmasters.net) wrote:
> On 10/16/23 15:06, Robert Haas wrote:
> > On Mon, Oct 16, 2023 at 1:00 PM David Steele wrote:
> > > After some agonizing (we hope) they decide to delete backup_label and,
> > > wow, it just works! So now they merrily go on their way with a
On Mon, Jul 3, 2023 at 6:57 PM Heikki Linnakangas wrote:
>
Thanks a lot for responding. Sorry for being late.
> On 07/02/2023 16:00, Bharath Rupireddy wrote:
> > Hi,
> >
> > While working on [1], I was looking for a quick way to tell if a WAL
> > record is present in the WAL buffers array withou
On Mon, Oct 16, 2023 at 5:21 PM David G. Johnston
wrote:
> But no, by default, and probably so far as pg_basebackup is concerned, a
> server crash during backup results in requiring outside intervention in order
> to get the server to restart.
Others may differ, but I think such a proposal is d
Hi
> Isn't this code a little ugly?
>
> >
> > I propose syntax xxx.yyy%ELEMENTTYPE and xxx%ELEMENTTYPE
> >
> > What do you think about it?
> No other relational database can be found with such an implementation.
> But it seems like a good idea. It can bring more convenience to write
> stored proc
On Tue, Oct 17, 2023 at 10:50 AM Robert Haas wrote:
> Life would be a lot easier here if we could get rid of the low-level
> backup API and just have pg_basebackup DTWT, but that seems like a
> completely non-viable proposal.
>
Yeah, my contribution to this area [1] is focusing on the API becaus
On Mon, Oct 16, 2023 at 12:31 PM Michael Christofides
wrote:
> According to the docs[1]: "In a parallel bitmap heap scan, one process is
> chosen as the leader. That process performs a scan of one or more indexes and
> builds a bitmap indicating which table blocks need to be visited. These
> bl
On Mon, Oct 16, 2023 at 6:48 PM Thomas Munro wrote:
> I pushed the retry-loop-in-frontend-executables patch and the
> missing-locking-in-SQL-functions patch yesterday. That leaves the
> backup ones, which I've rebased and attached, no change. It sounds
> like we need some more healthy debate abo
On Tue, Oct 17, 2023, 09:22 Robert Haas wrote:
> On Tue, Oct 17, 2023 at 12:18 PM Tom Lane wrote:
> > Robert Haas writes:
> > Is that actually possible? I had the idea that "git push" is an
> > atomic operation, ie 100% or nothing. Is it only atomic per-branch?
>
> I believe so.
Git push do
Nathan Bossart writes:
> ... and it looks like some of the back-branches are failing for Windows.
> I'm assuming this is because c290e79 was only back-patched to v15. My
> first instinct is just to back-patch that one all the way to v11, but maybe
> there's an alternative involving #ifdef WIN32.
On Fri, Oct 13, 2023 at 3:29 AM Michael Paquier wrote:
> Now looking at 0002, where you should be careful about the code
> indentation or koel will complain.
Fixed in the attached version.
> This makes the new code call LocalSetXLogInsertAllowed() and what we
> set for checkPoint.PrevTimeLineID
I wrote:
> Yeah, the same thing occurred to me in the shower this morning, and it
> does seem to work! We can replace both loops with a %= operator, at
> least if we're willing to assume C99 division semantics, which seems
> pretty safe in 2023.
Whoops, no: for negative starting values we'd need
On Tue, Oct 17, 2023 at 10:46:47AM -0500, Nathan Bossart wrote:
> Committed and back-patched.
... and it looks like some of the back-branches are failing for Windows.
I'm assuming this is because c290e79 was only back-patched to v15. My
first instinct is just to back-patch that one all the way to
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
That looks correct for me
The new status of this patch is: Ready for Committ
On Tue, 2023-10-17 at 08:41 -0400, Robert Haas wrote:
> Sorry, I'm not sure I understand the question. Are you asking whether
> dirtying buffers unnecessarily might be slower than not doing that?
I meant: are those cleanup operations frequent enough that dirtying
those buffers in that case would m
Laurenz Albe writes:
> On Mon, 2023-10-16 at 19:05 -0700, David G. Johnston wrote:
>> Reading both threads I'm not seeing any specific rejection of the
>> solution that we simply represent empty privileges as "(none)".
> Thanks for that summary. I prefer my version (simply display NULLs
> as NUL
On Tue, 2023-10-17 at 17:07 +0200, Daniel Verite wrote:
> There's a problem in the fact that the set of assigned code points is
> expanding with every Unicode release, which happens about every year.
>
> If we had this option in Postgres 11 released in 2018 it would use
> Unicode 11, and in 2023 t
On Tue, Oct 17, 2023 at 12:18 PM Tom Lane wrote:
> Robert Haas writes:
> > One potential problem with a server-side hook is that if you back-port
> > a commit to older branches and then push the commits all together
> > (which is my workflow) then you might get failure to push on some
> > branche
On Tue, Oct 17, 2023 at 12:17 PM Tom Lane wrote:
> Hmm, I've not found it that hard to manage the typedefs list.
> If I run pgindent and it adds weird spacing around uses of a new
> typedef name, I go "oh, I better add that to the list" and do so.
> End of problem. There's not a requirement that
On Fri, Oct 6, 2023 at 1:29 PM Laurenz Albe
wrote:
> On Fri, 2023-10-06 at 22:18 +0200, Laurenz Albe wrote:
> > On Fri, 2023-10-06 at 22:16 +0200, Laurenz Albe wrote:
> > > Here is a patch that does away with the special handling of NULL values
> > > in psql backslash commands.
> >
> > Erm, I for
Robert Haas writes:
> One potential problem with a server-side hook is that if you back-port
> a commit to older branches and then push the commits all together
> (which is my workflow) then you might get failure to push on some
> branches but not others. I don't know if there's any way to avoid
>
Peter Geoghegan writes:
> That's beside the point. The point is that I'm obligated to keep
> typedef.list up to date in general, a task that is made significantly
> harder by random objdump implementation details. And I probably need
> to do this not just once per commit, but several times, since
On Tue, Oct 17, 2023 at 9:03 AM Jelte Fennema wrote:
> To make koel pass you don't need to worry about hand-polishing
> typedefs.list. koel uses the typedefs.list that's committed into the
> repo, just like when you run pgindent yourself. If you forget to
> update the typedefs.list with new types,
On Tue, 17 Oct 2023 at 17:47, Peter Geoghegan wrote:
> Once you figure all that out, you're still obligated to hand-polish
> typedefs.list to be consistent with whatever Bruce's machine's copy of
> objdump does (or is it Tom's?). You need to sort the entries so they
> kinda look like they originat
On Tue, Oct 17, 2023 at 8:24 AM Robert Haas wrote:
> I also just discovered that my pre-commit hook doesn't work if I pull
> commits into master by cherry-picking. I had thought that I could have
> my hook just check my commits to master and not all of my local dev
> branches where I really don't
Committed and back-patched.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Oct 17, 2023 at 11:38 AM Isaac Morland wrote:
> On Tue, 17 Oct 2023 at 11:15, Robert Haas wrote:
>> Are code points assigned from a gapless sequence? That is, is the
>> implementation of codepoint_is_assigned(char) just 'codepoint <
>> SOME_VALUE' and SOME_VALUE increases over time?
>
> N
On Tue, Oct 17, 2023 at 11:23 AM Jelte Fennema wrote:
> To clarify, I did not intend to imply people that commit unindented
> code are lazy. It's expected that humans forget to run pgindent before
> committing from time to time (I do too). That's why I proposed a
> server side git hook to reject b
On Tue, 17 Oct 2023 at 11:15, Robert Haas wrote:
> Are code points assigned from a gapless sequence? That is, is the
> implementation of codepoint_is_assigned(char) just 'codepoint <
> SOME_VALUE' and SOME_VALUE increases over time?
>
Not even close. Code points are organized in blocks, e.g. fo
Hi,
On 10/13/23 10:35 AM, shveta malik wrote:
On Thu, Oct 12, 2023 at 9:18 AM shveta malik wrote:
PFA v24 patch set which has below changes:
1) 'enable_failover' displayed in pg_replication_slots.
2) Support for 'enable_failover' in
pg_create_logical_replication_slot(). It is an optional a
Michael Paquier writes:
> On Tue, Oct 17, 2023 at 01:40:18AM -0400, Tom Lane wrote:
>> makes the failure go away. Unfortunately, I've not yet found another
>> way to make it go away :-(. My upthread idea of using a local variable
>> instead of result->time is no help, and some other random code
On Tue, Oct 17, 2023 at 11:16 AM Peter Geoghegan wrote:
> Yep. Enforcing perfect indentation on koel necessitates rechecking
> indentation after each and every last-minute fixup affecting C code --
> the interactions makes it quite a bit harder to get everything right
> on the first push. For exam
On Tue, 17 Oct 2023 at 16:04, Robert Haas wrote:
> What I really dislike about the current situation is that
> it's doubling down on the idea that committers have to be perfect and
> get everything right every time. Turns out, that's hard to do. If not,
> why do people keep screwing things up? Som
On Tue, Oct 17, 2023 at 8:01 AM Robert Haas wrote:
> In fact, that particular experience is one of the worst things about
> being a committer. It actively discourages me, at least, from trying
> to get other people's patches committed. This particular problem is
> minor, but the overall experience
On Tue, Oct 17, 2023 at 11:07 AM Daniel Verite wrote:
> There's a problem in the fact that the set of assigned code points is
> expanding with every Unicode release, which happens about every year.
>
> If we had this option in Postgres 11 released in 2018 it would use
> Unicode 11, and in 2023 thi
Jeff Davis wrote:
> I believe the patch has utility as-is, but I've been brainstorming a
> few more ideas that could build on it:
>
> * Add a per-database option to enforce only storing assigned unicode
> code points.
There's a problem in the fact that the set of assigned code points is
On Tue, Oct 17, 2023 at 10:23 AM Tom Lane wrote:
> An alternative I was thinking about after reading your earlier email
> was going back to the status quo ante, but doing the manual tree-wide
> reindents significantly more often than once a year. Adding one at
> the conclusion of each commitfest
On Tue, 17 Oct 2023 at 16:23, Tom Lane wrote:
> > Or we could have a server-side hook that will refuse
> > the misindented commit, with some kind of override for emergency
> > situations.
>
> Even though I'm in the camp that would like the tree correctly
> indented at all times, I remain very much
On Tue, Oct 17, 2023 at 7:23 AM Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Oct 17, 2023 at 8:45 AM Robert Haas wrote:
> >> +1. I think this is more annoying than the status quo ante.
>
> > Although ... I do think it's spared me some rebasing pain, and that
> > does have some real value. I
Hi, hackers!
I've stumbled into an interesting problem. Currently, if Postgres has nothing
to write, it would skip the checkpoint creation defined by the checkpoint
timeout setting. However, we might face a temporary archiving problem (for
example, some network issues) that might lead to a pi
On Tue, 17 Oct 2023 at 14:17, Amit Kapila wrote:
>
> On Fri, Oct 13, 2023 at 11:08 AM Amit Kapila wrote:
> >
> > On Fri, Oct 13, 2023 at 10:04 AM vignesh C wrote:
> > >
> > > On Thu, 12 Oct 2023 at 11:10, Amit Kapila wrote:
> > > >
> > > > On Sun, Oct 8, 2023 at 8:22 AM vignesh C wrote:
> > >
On Tue, Oct 17, 2023 at 4:57 AM Aleksander Alekseev
wrote:
> v11-0001 and v11-0002 LGTM too.
Cool. Seems we are all in agreement, so committed these. Thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas writes:
> On Tue, Oct 17, 2023 at 8:45 AM Robert Haas wrote:
>> +1. I think this is more annoying than the status quo ante.
> Although ... I do think it's spared me some rebasing pain, and that
> does have some real value. I wonder if we could think of other
> alternatives.
An alter
On Tue, Oct 17, 2023 at 8:45 AM Robert Haas wrote:
> > This policy isn't working.
>
> +1. I think this is more annoying than the status quo ante.
Although ... I do think it's spared me some rebasing pain, and that
does have some real value. I wonder if we could think of other
alternatives. For ex
On Tue, Oct 17, 2023 at 6:34 AM Jelte Fennema wrote:
> I think *it is* dead easy to comply. If you run the following commands
> before committing/after rebasing, then koel should always be happy:
>
> src/tools/pgindent/pgindent src # works always but a bit slow
> src/tools/pgindent/pgindent $(git
Hi,
Thanks for the review!
On Tue, 17 Oct 2023 at 11:40, Michael Paquier wrote:
>
> On Mon, Oct 16, 2023 at 01:07:07PM +0300, Nazir Bilal Yavuz wrote:
> > Yes, that could be a better solution. Also, having more detailed stats
> > for shared and local buffers is helpful. I updated patches in line
> So, I've spent more time on that and applied the simplification today,
> doing as you have suggested to use the head page rather than the tail
> page when the tail XID is ahead of the head XID, but without disabling
> the whole. I've simplified a bit the code and the comments, though,
> while on
Hello,
On 2023-Oct-17, Ashutosh Bapat wrote:
> Problem 1
>
> #create table tpart (a serial primary key, src varchar) partition by range(a);
> CREATE TABLE
> #create table t_p4 (a int primary key, src varchar);
> CREATE TABLE
> But tparts NOT NULL constraint is recorded in pg_constraint
On Mon, 2023-10-16 at 19:05 -0700, David G. Johnston wrote:
> Reading both threads I'm not seeing any specific rejection of the
> solution that we simply represent empty privileges as "(none)".
>
> I see an apparent consensus that if we do continue to represent it
> as NULL that the printout shoul
On Sun, Oct 15, 2023 at 8:52 PM Peter Geoghegan wrote:
> On Sat, Aug 12, 2023 at 5:53 PM Peter Geoghegan wrote:
> > Maybe I'm wrong -- maybe the new policy is practicable. It might even
> > turn out to be worth the bother. Time will tell.
>
> (Two months pass.)
>
> There were two independent fixu
On Mon, Oct 16, 2023 at 7:31 PM Jeff Davis wrote:
> Another option might be to just change the hash indexing code to follow
> the correct protocol, locking and calling MarkBufferDirty() in those 3
> call sites. Marking the buffer dirty is easy, but making sure that it's
> locked might require some
Dear Vignesh,
Thank you for reviewing! New version can be available in [1].
> 1) Should this:
> +# Copyright (c) 2023, PostgreSQL Global Development Group
> +
> +# Tests for upgrading replication slots
> +
> be:
> "Tests for upgrading logical replication slots"
Fixed.
> 2) This statement is no
Dear Amit,
Thanks for reviewing! PSA new version.
>
> Yeah, I think introducing additional complexity unless it is really
> required sounds a bit scary to me as well. BTW, please find attached
> some cosmetic changes.
Basically LGTM, but below part was conflicted with Bharath's comment [1].
``
On Mon, Oct 16, 2023 at 5:21 PM Nikita Malakhov wrote:
>
> Hi!
>
> With the latest set of patches we encountered failure with the following
> query:
>
> postgres@postgres=# SELECT JSON_QUERY(jsonpath '"aaa"', '$' RETURNING text);
> server closed the connection unexpectedly
> This probably
1 - 100 of 116 matches
Mail list logo
