On Thu, Jan 19, 2023 at 6:20 AM Nathan Bossart wrote:
>
> On Tue, Jan 17, 2023 at 07:44:52PM +0530, Bharath Rupireddy wrote:
> > On Thu, Jan 12, 2023 at 6:21 AM Nathan Bossart
> > wrote:
> >> With your patch, we might replay one of these "old" files in pg_wal instead
> >> of the complete
Hi,
On 1/20/23 9:01 PM, Nathan Bossart wrote:
On Tue, Jan 10, 2023 at 11:08:33AM +0100, Drouvot, Bertrand wrote:
While working on [1], I noticed that xl_hash_vacuum_one_page.ntuples is an int.
Unless I'm missing something, It seems to me that it would make more sense to
use an uint16 (like
Hi,
On 2023-01-20 20:16:13 -0800, Andres Freund wrote:
> On 2023-01-18 14:05:35 +0100, David Geier wrote:
> > @Andres: will you take care of these changes and provide me with an updated
> > patch set so I can rebase the RDTSC changes?
> > Otherwise, I can also apply Tom suggestions to your patch
On 2023-01-20 22:50:37 -0600, Justin Pryzby wrote:
> On Fri, Jan 20, 2023 at 04:40:32PM -0800, Andres Freund wrote:
> > From 5a458d4584961dedd3f80a07d8faea66e57c5d94 Mon Sep 17 00:00:00 2001
> > From: Andres Freund
> > Date: Mon, 16 Jan 2023 11:19:11 -0800
> > Subject: [PATCH v8 4/5] wip: report
On Fri, Jan 20, 2023 at 04:40:32PM -0800, Andres Freund wrote:
> From 5a458d4584961dedd3f80a07d8faea66e57c5d94 Mon Sep 17 00:00:00 2001
> From: Andres Freund
> Date: Mon, 16 Jan 2023 11:19:11 -0800
> Subject: [PATCH v8 4/5] wip: report nanoseconds in pg_test_timing
>
> - The i7-860 system
Hi,
On 2023-01-18 14:02:48 +0100, David Geier wrote:
> On 1/16/23 18:37, Andres Freund wrote:
> > I'm doubtful this is worth the complexity it incurs. By the time we convert
> > out of the instr_time format, the times shouldn't be small enough that the
> > accuracy is affected much.
>
> I don't
Hi,
On 2023-01-18 14:05:35 +0100, David Geier wrote:
> @Andres: will you take care of these changes and provide me with an updated
> patch set so I can rebase the RDTSC changes?
> Otherwise, I can also apply Tom suggestions to your patch set and send out
> the complete patch set.
I'm planning to
Hi,
On 2023-01-20 07:43:00 +0100, David Geier wrote:
> On 1/18/23 13:52, David Geier wrote:
> > On 1/16/23 21:39, Pavel Stehule wrote:
> > >
> > > po 16. 1. 2023 v 21:34 odesílatel Tomas Vondra
> > > napsal:
> > >
> > > Hi,
> > >
> > > there's minor bitrot in the Mkvcbuild.pm change,
Hi,
On 2023-01-19 11:47:49 +0100, David Geier wrote:
> > I also couldn't help and hacked a bit on the rdtsc pieces. I did figure out
> > how to do the cycles->nanosecond conversion with integer shift and multiply
> > in
> > the common case, which does show a noticable speedup. But that's for
Hi,
On 2023-01-20 22:27:07 -0500, Tom Lane wrote:
> Andres Freund writes:
> >> Perhaps an INSTR_TIME_ZERO() that could be assigned in variable definitions
> >> could give us the best of both worlds?
>
> > I tried that in the attached 0005. I found that it reads better if I also
> > add
> >
On Fri, Jan 20, 2023 at 11:56:00AM +0100, Peter Eisentraut wrote:
> In your 0001 patch, most of the comment reformattings for location fields
> are no longer needed, so you should undo those.
>
> The 0002 patch looks good.
Okay, I have gone through these two again and applied what I had.
0001
Andres Freund writes:
>> Perhaps an INSTR_TIME_ZERO() that could be assigned in variable definitions
>> could give us the best of both worlds?
> I tried that in the attached 0005. I found that it reads better if I also add
> INSTR_TIME_CURRENT(). If we decide to go for this, I'd roll it into
Hi,
On 2023-01-14 14:45:06 +1300, Thomas Munro wrote:
> On Tue, Jan 10, 2023 at 3:05 PM Andres Freund wrote:
> > On 2023-01-03 12:05:20 -0800, Andres Freund wrote:
> > > The attached patch adds libpq-be-fe-helpers.h and uses it in
> > > libpqwalreceiver,
> > > dblink, postgres_fdw.
> >
> > > As
Hi,
On 2023-01-20 17:12:37 -0800, Andres Freund wrote:
> We have code like this in libpqrcv_connect():
>
> conn = palloc0(sizeof(WalReceiverConn));
> conn->streamConn = PQconnectStartParams(keys, vals,
>
>
On Sat, 21 Jan 2023 at 02:28, Justin Pryzby wrote:
>
> On Sat, Jan 21, 2023 at 01:51:28AM +0100, Matthias van de Meent wrote:
> > On Thu, 19 Jan 2023 at 06:47, Justin Pryzby wrote:
> > >
> > > pg_stat_progress_copy was added in v14 (8a4f618e7, 9d2d45700).
> > >
> > > But if a command JOINs
On Sat, Jan 21, 2023 at 01:51:28AM +0100, Matthias van de Meent wrote:
> On Thu, 19 Jan 2023 at 06:47, Justin Pryzby wrote:
> >
> > pg_stat_progress_copy was added in v14 (8a4f618e7, 9d2d45700).
> >
> > But if a command JOINs file_fdw tables, the progress report gets bungled
> > up. This will
On Sat, 21 Jan 2023 at 02:04, Ted Yu wrote:
>
>
>
> On Fri, Jan 20, 2023 at 4:51 PM Matthias van de Meent
> wrote:
>>
>> Attached a patch that solves this specific issue in a
>> binary-compatible way. I'm not super happy about relying on behavior
>> of callers of BeginCopyFrom (assuming that
On Mon, Jan 16, 2023 at 11:18:08AM +0300, Alexander Pyhalov wrote:
> Is it intended? Why don't we perform vacuum_is_permitted_for_relation()
> check for inheritors in expand_vacuum_rel()?
Since no lock is held on the partition, the calls to functions like
object_ownercheck() and
Hi,
We have code like this in libpqrcv_connect():
conn = palloc0(sizeof(WalReceiverConn));
conn->streamConn = PQconnectStartParams(keys, vals,
/* expand_dbname = */ true);
if
On Fri, Jan 20, 2023 at 4:51 PM Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
> On Thu, 19 Jan 2023 at 06:47, Justin Pryzby wrote:
> >
> > pg_stat_progress_copy was added in v14 (8a4f618e7, 9d2d45700).
> >
> > But if a command JOINs file_fdw tables, the progress report gets
On Thu, 19 Jan 2023 at 06:47, Justin Pryzby wrote:
>
> pg_stat_progress_copy was added in v14 (8a4f618e7, 9d2d45700).
>
> But if a command JOINs file_fdw tables, the progress report gets bungled
> up. This will warn/assert during file_fdw tests.
I don't know what to do with that other than
Hi,
On 2023-01-17 10:50:53 -0800, Andres Freund wrote:
> On 2023-01-17 12:26:57 -0500, Tom Lane wrote:
> > > 0001) Add INSTR_TIME_SET_ZERO() calls where otherwise 0002 causes gcc to
> > > warn
> > > Alternatively we can decide to deprecate INSTR_TIME_SET_ZERO() and
> > > just
On Fri, 2023-01-20 at 12:54 -0800, Jeff Davis wrote:
> Both of these are surprising, and I haven't investigated deeply yet.
It's just because autoconf defaults to -O2 and meson to -O3, at least
on my machine. It turns out that, at -O2, master and the refactoring
branch are even; but at -O3, both
On Fri, Dec 2, 2022 at 1:07 PM Drouvot, Bertrand
wrote:
>
> Patch LGTM, marking it as Ready for Committer.
Had to rebase, attached v5 patch for further consideration.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From
On Fri, Dec 02, 2022 at 08:36:38AM +0100, Drouvot, Bertrand wrote:
> Patch LGTM, marking it as Ready for Committer.
Unfortunately, this patch no longer applies. Bharath, would you mind
posting a rebased version?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Jan 19, 2023 at 8:31 PM Andres Freund wrote:
> I know I can leave the variable initially uninitialized and then do a separate
> assignment, but that's not a great fix.
That's what I do.
If you pick names for all of your data types that are very very long
and wordy then you don't feel as
Hi,
On 2023-01-19 17:59:49 -0800, Andres Freund wrote:
> On 2023-01-19 20:43:44 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > There's a few places in the code that try to format a variable definition
> > > like this
> >
> > > ReorderBufferChange *next_change =
> > >
In the script below, the presence of an IN clause forces the internal
components of the UNION ALL clause to fully compute even though they are
fully optimizable. = ANY doesn't have this issue, so I wonder if there is
any opportunity to convert the 'slow' variant (see below) to the 'fast'
variant.
Hi Egor,
While reviewing a patch improving join estimates for ranges [1] I
realized we don't show stats for ranges in pg_stats, and I recalled we
had this patch.
I rebased the v2, and I decided to took a stab at showing separate
histograms for lower/upper histogram bounds. I believe it makes it
On Fri, Jan 20, 2023 at 4:02 PM Nathan Bossart wrote:
> On Fri, Jan 20, 2023 at 03:42:03PM -0500, Robert Haas wrote:
> > Thanks to you both. I have committed these patches.
>
> Thanks! Does this need a catversion bump?
I was surprised by this question because I thought I'd included one.
But it
On Fri, Jan 20, 2023 at 12:57 PM Robert Haas wrote:
> It doesn't seem that way to me. What am I missing? In that case, the
> problem was a DROP TRIGGER command waiting behind autovacuum's lock
> and thus causing all new table locks to wait behind DROP TRIGGER's
> lock request. But it does not
On Fri, Jan 20, 2023 at 03:42:03PM -0500, Robert Haas wrote:
> Thanks to you both. I have committed these patches.
Thanks! Does this need a catversion bump?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Jan 20, 2023 at 3:43 PM Peter Geoghegan wrote:
> The only reason why I'm using table age at all is because that's how
> it works already, rightly or wrongly. If nothing else, t's pretty
> clear that there is no theoretical or practical reason why it has to
> be exactly the same table age
On Fri, 20 Jan 2023 14:22:25 -0600
"Karl O. Pinc" wrote:
> v8-0001-List-trusted-and-obsolete-extensions.patch
>
> Instead of putting [trusted] and [obsolete] in the titles
> of the modules, like v7 does, add a list of them into the text.
The list is inline. It might be worthwhile
On Tue, 2023-01-17 at 14:18 -0800, Peter Geoghegan wrote:
> The second goal is a perfectly good enough goal on its own, and one
> that I am totally supportive of. Making the code clearer is icing on
> the cake.
Attached v8, which is just a rebase.
To reiterate: commitfest entry
On Fri, Jan 20, 2023 at 5:47 AM Robert Haas wrote:
> Yeah, this is a major reason why I'm very leery about changes in this
> area. A lot of autovacuum behavior is emergent, in the sense that it
> wasn't directly intended by whoever wrote the code. It's just a
> consequence of other decisions that
On Fri, Jan 20, 2023 at 1:10 PM Nathan Bossart wrote:
> > Thanks, this is fixed now with the latest patches.
>
> Thank you for reviewing.
Thanks to you both. I have committed these patches.
--
Robert Haas
EDB: http://www.enterprisedb.com
I've accumulated another collection of various questions and comments. As a
side note I'm getting a good feeling about this patch, those part I've read so
far looks good to me.
* I've suddenly realized one could use pseudo types for variables, and
it not always works. E.g.:
=# create
On Fri, 20 Jan 2023 20:12:38 +0100
Alvaro Herrera wrote:
> Ah, I wanted to attach the two remaining patches and forgot.
Attached are 2 alternatives:
(They touch separate files so the ordering is meaningless.)
v8-0001-List-trusted-and-obsolete-extensions.patch
Instead of putting [trusted]
On Tue, Jan 10, 2023 at 11:08:33AM +0100, Drouvot, Bertrand wrote:
> While working on [1], I noticed that xl_hash_vacuum_one_page.ntuples is an
> int.
>
> Unless I'm missing something, It seems to me that it would make more sense to
> use an uint16 (like this is done for
>
On Wed, Jan 04, 2023 at 11:35:33AM +0530, Sravan Kumar wrote:
> I have added the thread to the commitfest:
> https://commitfest.postgresql.org/42/
> Did you get a chance to review the patch? Please let me know if you
> need anything from my end.
This seems like worthwhile simplification to me.
On Fri, 20 Jan 2023 20:12:03 +0100
Alvaro Herrera wrote:
> On 2023-Jan-20, Karl O. Pinc wrote:
>
> > On Fri, 20 Jan 2023 12:42:31 +0100
> > Alvaro Herrera wrote:
>
> > > Hmm, I didn't know that. I guess I can put it back. My own
> > > instinct is to put the most important stuff first, not
On Fri, Jan 20, 2023 at 11:09 AM Jim Jones wrote:
> Well, I am not suggesting to change the current behavior of PostgreSQL in
> that matter. Quite the contrary, I find this feature very convenient,
> specially when you need to deal with many different clusters. What I am
> proposing is rather the
Ah, I wanted to attach the two remaining patches and forgot. Here they
are.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
>From ba972984da37b5a315bd7a4face064d24ca41436 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Fri, 20 Jan 2023 12:32:22 +0100
On 2023-Jan-20, Karl O. Pinc wrote:
> On Fri, 20 Jan 2023 12:42:31 +0100
> Alvaro Herrera wrote:
> > Hmm, I didn't know that. I guess I can put it back. My own instinct
> > is to put the most important stuff first, not last, but if research
> > says to do otherwise, fine, let's do that.
>
>
Hello Israel,
Thanks a lot for the suggestion!
> I do not think it is worth it to change the current behavior of
PostgreSQL
> in that sense.
Well, I am not suggesting to change the current behavior of PostgreSQL in
that matter. Quite the contrary, I find this feature very convenient,
Hi,
On Thursday, January 19, 2023 7:55 PM vignesh C wrote:
> On Thu, 19 Jan 2023 at 12:06, Takamichi Osumi (Fujitsu)
> wrote:
> >
> > Updated the comment and the function call.
> >
> > Kindly have a look at the updated patch v17.
>
> Thanks for the updated patch, few comments:
> 1)
On Thu, Jan 19, 2023 at 05:07:11PM -0800, Andres Freund wrote:
> I'm somewhat dubious about allowing to return inside PG_CATCH, even if it's
> safe today.
+1. Unless there are known use-cases, IMHO it'd be better to restrict it
to prevent future compatibility breaks as PG_TRY evolves.
--
Hi,
On Thursday, January 19, 2023 10:17 PM Amit Kapila
wrote:
> On Thu, Jan 19, 2023 at 12:06 PM Takamichi Osumi (Fujitsu)
> wrote:
> >
> > Kindly have a look at the updated patch v17.
> >
>
> Can we try to optimize the test time for this test? On my machine, it is the
> second highest
On Fri, Jan 20, 2023 at 9:32 AM Ted Yu wrote:
>
> Since `validIdentifier` doesn't modify the contents of `name` string, it
> seems that there is no need to create `tmp` string in `validNamedOperator`.
> You can pass the start and end offsets into the string (name) as second and
> third
On Friday, January 20, 2023 12:47 PM shveta malik
wrote:
> 1)
> Tried different variations of altering 'min_apply_delay'. All passed except
> one
> below:
>
> postgres=# alter subscription mysubnew set (min_apply_delay = '10.9min
> 1ms'); ALTER SUBSCRIPTION postgres=# alter subscription
On Fri, Jan 13, 2023 at 02:00:05PM +1300, Thomas Munro wrote:
> The reason we introduced PG_SETMASK() in the first place was to
> support one particular system that was very slow to adopt the POSIX
> signals stuff: NeXTSTEP 3.x.
>
> From some time in the dark age before our current repo begins
On Friday, January 20, 2023 5:54 PM shveta malik wrote:
> On Fri, Jan 20, 2023 at 1:08 PM Peter Smith wrote:
>
> > a) the message should say that this is the *remaining* time to left to wait.
> >
> > b) it might be convenient to know from the log what was the original
> > min_apply_delay value
Hi Pavel,
On Mon, Jan 16, 2023 at 9:10 AM Pavel Stehule
wrote:
>
>
> ne 15. 1. 2023 v 7:32 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>>
>>> On Thu, Jan 12, 2023 at 9:51 AM Pavel Stehule
>>> wrote:
>>>
Hi
I checked this patch and it looks well. All tests passed. Together
Hi,
On Friday, January 20, 2023 6:13 PM shveta malik wrote:
> On Fri, Jan 20, 2023 at 2:23 PM shveta malik wrote:
> >
> > On Fri, Jan 20, 2023 at 1:08 PM Peter Smith
> wrote:
> >
> > > a) the message should say that this is the *remaining* time to left to
> > > wait.
> > >
> > > b) it might
On Friday, January 20, 2023 3:56 PM Peter Smith wrote:
> Hi Osumi-san, here are my review comments for the latest patch v17-0001.
Thanks for your review !
> ==
> Commit Message
>
> 1.
> Prohibit the combination of this feature and parallel streaming mode.
>
> SUGGESTION (using the same
On Thu, Jan 19, 2023 at 9:58 PM Andres Freund wrote:
> Finally pushed, with some fairly minor additional cleanup. No more SHM_QUEUE,
> yay!
Nice. I won't miss it one bit.
--
Robert Haas
EDB: http://www.enterprisedb.com
Andres Freund writes:
> On 2023-01-20 12:09:05 -0500, Tom Lane wrote:
>> The core problem here is that requiring that would translate to
>> requiring every code contributor to have a working copy of pg_bsd_indent.
> Wouldn't just every committer suffice?
Not if we have cfbot complaining about
On Fri, Jan 20, 2023 at 12:58 PM Tom Lane wrote:
> I don't mind if you write something like
>
> A float4 value is a 4-byte IEEE single-precision floating point
> number. It is transmitted in network byte order, so you must
> convert to local byte order. (C users can do this portably
>
On Fri, Jan 20, 2023 at 07:04:58PM +0530, tushar wrote:
> On 1/19/23 6:28 PM, tushar wrote:
>> There is one typo , for the doc changes, it is mentioned
>> "pg_use_reserved_backends" but i think it supposed to be
>> "pg_use_reserved_connections"
>> under Table 22.1. Predefined Roles.
>
> Thanks,
Mark Wong writes:
> On Thu, Nov 03, 2022 at 09:55:22AM -0400, Tom Lane wrote:
>> Perhaps a new chapter under "IV. Client Interfaces" is the right
>> place?
>>
>> If we wanted to get aggressive, we could move most of the nitpicky details
>> about datatype text formatting (e.g., the array quoting
Hi,
On 2023-01-20 12:09:05 -0500, Tom Lane wrote:
> Jelte Fennema writes:
> > To me a master branch that pgindent never complains about sounds
> > amazing! And I personally think rejection of unindented pushes and
> > cfbot complaining about unindented patches would be a very good thing,
> >
On 1/10/23 11:36, Jacob Champion wrote:
> 1) I'm playing around with a marker in pg_inherits, where the inhseqno
> is set to a sentinel value (0) for an inheritance relationship that
> has been marked for logical publication. The intent is that the
> pg_inherits helpers will prevent further
On Fri, Jan 20, 2023 at 9:17 AM Gurjeet Singh wrote:
> On Sat, Jan 14, 2023 at 6:14 AM Gurjeet Singh wrote:
> >
> > I agree that an identifier _surrounded_ by the same token (e.g. #foo#)
> > or the pairing token (e.g. {foo}) looks better aesthetically, so I am
> > okay with any of the following
On 20/01/23 06:07, David Rowley wrote:
Looking at the patch, you've not added any additional tests. If the
existing tests are all passing then that just tells me that either the
code is not functioning as intended or we have no tests that look at
the EXPLAIN output which can make use of
On Sat, Jan 14, 2023 at 6:14 AM Gurjeet Singh wrote:
>
> I agree that an identifier _surrounded_ by the same token (e.g. #foo#)
> or the pairing token (e.g. {foo}) looks better aesthetically, so I am
> okay with any of the following variations of the scheme, as well:
>
> \#foo\# (tested; works)
>You could just hard code that servers newer than a
> specific version would have this support
Suppose PostgreSQL 21 implements "fast TLS"
Suppose pgjdbc 43 supports "fast TLS"
Suppose PgBouncer 1.17.0 does not support "fast TLS" yet
If pgjdbc connects to the DB via balancer, then the server
Jelte Fennema writes:
> To me a master branch that pgindent never complains about sounds
> amazing! And I personally think rejection of unindented pushes and
> cfbot complaining about unindented patches would be a very good thing,
> because that seems to be the only solution that could achieve
On Mon, Jul 25, 2022 at 11:54:36AM +0300, Heikki Linnakangas wrote:
> Oh I just saw that you had a comment about that in the patch and had hacked
> around it. Anyway, calling ResourceOwnerEnlargeBuffers() might be a
> solution. Or switch to a separate "CriticalResourceOwner" that's guaranteed
>
On Fri, Jan 20, 2023 at 10:43:50AM +0100, Jelte Fennema wrote:
> Side-question: What's the reason why pgindent is used instead of some
> more "modern" code formatter that doesn't require keeping
> typedefs.list up to date for good looking output? (e.g. uncrustify or
> clang-format) Because that
On Fri, Jan 20, 2023 at 8:25 AM Robert Haas wrote:
> I still think you're talking about a different problem here. I'm
> talking about the problem of knowing whether local files are going to
> be accessed by the connection string.
So here's a dumb patch for this. At least in my mind, the
On Fri, 20 Jan 2023 at 01:41, Vladimir Sitnikov
wrote:
>
> Do you think the server can de-support the old code path soon?
I don't have any intention to de-support anything. I really only
picture it being an option in environments where the client and server
are all part of a stack controlled by
On Fri, Jan 20, 2023 at 10:33:57AM +0100, Laurenz Albe wrote:
> On Thu, 2023-01-19 at 15:56 -0500, Bruce Momjian wrote:
> > On Thu, Jan 19, 2023 at 01:50:05PM +0100, Laurenz Albe wrote:
> > > On Wed, 2023-01-18 at 16:23 -0500, Bruce Momjian wrote:
> > > > Is it possible to document when partition
--- Original Message ---
On Friday, January 20th, 2023 at 12:34 AM, Tomas Vondra
wrote:
>
>
> On 1/19/23 18:55, Tomas Vondra wrote:
>
> > Hi,
> >
> > On 1/19/23 17:42, gkokola...@pm.me wrote:
> >
> > > ...
> > >
> > > Agreed. It was initially submitted as one patch. Then it
>Number of indexes that will be vacuumed or cleaned up. This counter only
>advances when the phase is vacuuming indexes or cleaning up indexes.
I agree, this reads better.
---
-/* Report that we are now vacuuming indexes */
-
On 1/18/23 20:23, Mahmoud Sakr wrote:
> Hi Tomas,
> Thanks for picking up the patch and for the interesting discussions that
> you bring !
>
>> Interesting. Are there any particular differences compared to how we
>> estimate for example range clauses on regular columns?
>
> The theory is the same
On Wed, Jan 4, 2023 at 2:09 AM Corey Huinker wrote:
> 2. There are now two psql variables, SHELL_EXIT_CODE, which has the return
> code, and SHELL_ERROR, which is a true/false flag based on whether the exit
> code was nonzero. These variables are the shell result analogues of SQLSTATE
> and
On Thu, Jan 19, 2023 at 5:51 PM Andres Freund wrote:
> I don't agree. But mainly my issue is that the devil you know (how this has
> worked for a while) is preferrable to introducing an unknown quantity (your
> patch that hasn't yet seen real world exposure).
Yeah, this is a major reason why I'm
Alvaro Herrera writes:
> On 2023-Jan-05, Dag Lem wrote:
>
>> Is there anything else I should do here, to avoid the status being
>> incorrectly stuck at "Waiting for Author" again.
>
> Just mark it Needs Review for now. I'll be back from vacation on Jan
> 11th and can have a look then (or
On 1/19/23 6:28 PM, tushar wrote:
There is one typo , for the doc changes, it is mentioned
"pg_use_reserved_backends" but i think it supposed to be
"pg_use_reserved_connections"
under Table 22.1. Predefined Roles.
Thanks, this is fixed now with the latest patches.
--
regards,tushar
On Thu, Jan 19, 2023 at 8:46 PM Andres Freund wrote:
> > I wouldn't be OK with writing our own connection string parser for
> > this purpose, but using PQconninfoParse seems OK. We still have to
> > embed knowledge of which connection string parameters can trigger
> > local file access, but that
On Fri, Jan 20, 2023 at 1:19 AM Dmitry Koval wrote:
> Thanks, Ted Yu!
>
> > Please update year for the license in pg_controllog.c
>
> License updated for files pg_controllog.c, controllog_utils.c,
> pg_controllog.h, controllog_utils.h.
>
> > +check_file_exists(const char *datadir, const char
On Fri, 2023-01-20 at 09:59 +, Abhishek Prakash wrote:
> We had set max_standby_streaming_delay = -1, but faced storage issues
> nearly 3.5 TB of storage was consumed.
Then either don't run queries that take that long or run fewer data
modifications on the primary.
Or invest in a few more TB
Hi Laurenz,
Thanks for your reply.
We had set max_standby_streaming_delay = -1, but faced storage issues nearly
3.5 TB of storage was consumed.
Regards,
Abhishek P
-Original Message-
From: Laurenz Albe
Sent: Friday, January 20, 2023 3:26 PM
To: Abhishek Prakash ;
On Fri, 2023-01-20 at 08:56 +, Abhishek Prakash wrote:
> We are facing below issue with read replica we did work arounds by setting
> hot_standby_feedback, max_standby_streaming_delay and
> max_standby_archive_delay,
> which indeed caused adverse effects on primary DB and storage. As our DB
On Mon, Jan 9, 2023 at 11:37 PM Tom Lane wrote:
> Anyway, to get back to the point at hand: if we do have a REPLICA IDENTITY
> FULL situation then we can make use of any unique index over a subset of
> the transmitted columns, and if there's more than one candidate index
> it's unlikely to matter
On Fri, 20 Jan 2023 12:42:31 +0100
Alvaro Herrera wrote:
> On 2023-Jan-19, Karl O. Pinc wrote:
>
> > On Thu, 19 Jan 2023 11:03:53 -0600
> > "Karl O. Pinc" wrote:
> >
> > > Attached are 2 patches, a regular and a delta from your v4 review:
> > >
> > > contrib_v5-delta.patch.txt
> > >
On 2023-Jan-19, Karl O. Pinc wrote:
> On Thu, 19 Jan 2023 11:03:53 -0600
> "Karl O. Pinc" wrote:
>
> > Attached are 2 patches, a regular and a delta from your v4 review:
> >
> > contrib_v5-delta.patch.txt
> > contrib_v5.patch.txt
>
> I left your appendix title unchanged: "Additional Supplied
On 1/20/23 07:43, David Geier wrote:
> On 1/18/23 13:52, David Geier wrote:
>> On 1/16/23 21:39, Pavel Stehule wrote:
>>>
>>> po 16. 1. 2023 v 21:34 odesílatel Tomas Vondra
>>> napsal:
>>>
>>> Hi,
>>>
>>> there's minor bitrot in the Mkvcbuild.pm change, making cfbot
>>> unhappy.
>>>
On 20.01.23 05:35, Michael Paquier wrote:
On Thu, Jan 19, 2023 at 09:42:03AM +0100, Peter Eisentraut wrote:
I see that in the 0003 patch, most location fields now have an explicit
markup with query_jumble_ignore. I thought we had previously resolved to
consider location fields to be
On Tue, Jan 17, 2023 at 2:41 PM Amit Kapila wrote:
>
> Let me try to summarize the discussion till now. The problem we are
> trying to solve here is to allow a shutdown to complete when walsender
> is not able to send the entire WAL. Currently, in such cases, the
> shutdown fails. As per our
On 2023-01-11 19:04, Hayato Kuroda (Fujitsu) wrote:
Dear hackers,
I was not sure, but the cfbot could not be accepted the previous
version.
I made the patch again from HEAD(5f6401) without any changes,
so I did not count up the version number.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
On Fri, Jan 20, 2023 at 11:44 AM Tom Lane wrote:
> Thomas Munro writes:
> > Thanks for the report, and for working on the fix. Can you please
> > create a commitfest entry (if you haven't already)? I plan to look at
> > this soon, after the code freeze.
>
> Hi Thomas, are you still intending
On Wed, 16 Nov 2022 at 15:35, vignesh C wrote:
>
> On Wed, 16 Nov 2022 at 09:34, Ian Lawrence Barwick wrote:
> >
> > 2022年11月7日(月) 22:39 vignesh C :
> > >
> > > On Fri, 4 Nov 2022 at 08:19, Ian Lawrence Barwick
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > > cfbot reports the patch no longer
As a not very frequent submitter, on all the patches that I submit I
keep running into this problem. I have two open patchsets for
libpq[1][2] both of which currently include the same initial "run
pgindent" patch in addition to the actual patch, just so I can
actually run it on my own patch
On Thu, 2023-01-19 at 15:56 -0500, Bruce Momjian wrote:
> On Thu, Jan 19, 2023 at 01:50:05PM +0100, Laurenz Albe wrote:
> > On Wed, 2023-01-18 at 16:23 -0500, Bruce Momjian wrote:
> > > Is it possible to document when partition table statistics helps?
> >
> > I think it would be difficult to come
On Fri, 13 Jan 2023 at 07:50, Corey Huinker wrote:
>
> I named it wait_result_to_exit_code(), but I welcome suggestions of a
> better name.
>
Thanks! But CF bot still not happy. I think, we should address issues from
here https://cirrus-ci.com/task/5391002618298368
--
Best regards,
Maxim
Thanks, Ted Yu!
> Please update year for the license in pg_controllog.c
License updated for files pg_controllog.c, controllog_utils.c,
pg_controllog.h, controllog_utils.h.
> +check_file_exists(const char *datadir, const char *path)
> There is existing helper function such as:
>
On Fri, Jan 20, 2023 at 2:23 PM shveta malik wrote:
>
> On Fri, Jan 20, 2023 at 1:08 PM Peter Smith wrote:
>
> > a) the message should say that this is the *remaining* time to left to wait.
> >
> > b) it might be convenient to know from the log what was the original
> > min_apply_delay value in
Hi.
Tomas Vondra писал 2023-01-19 20:49:
I took a quick look at the patch. It needs a rebase, although it
applies
fine using patch.
A couple minor comments:
1) addl_conds seems a bit hard to understand, I'd use either the full
wording (additional_conds) or maybe extra_conds
Renamed to
1 - 100 of 103 matches
Mail list logo
