Dear Vignesh,
Thank you for reviewing! PSA new patchset.
> > Additionally, I added a checking functions in 0003
> > According to pg_resetwal and other functions, the length of
> CHECKPOINT_SHUTDOWN
> > record seems (SizeOfXLogRecord + SizeOfXLogRecordDataHeaderShort +
> sizeof(CheckPoint)).
> >
Dear Vignesh,
Thanks for giving a comment! New patch will be available soon.
> Thanks for the patches.
> Currently the two_phase enabled slots are not getting restored from
> the dumped contents, this is because we are passing the twophase value
> as the second parameter which indicates if it is
On Thu, Apr 13, 2023 at 8:02 AM Amit Kapila wrote:
>
> On Wed, Apr 12, 2023 at 5:50 PM Robert Haas wrote:
> >
> > On Tue, Apr 11, 2023 at 10:56 PM Amit Kapila
> > wrote:
> > > Anyway, I don't think as such there is any problem
> > > with restarting the worker even when the subscription owner
Alexander,
On Wed, Apr 19, 2023 at 11:44 PM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi,
>
> Here are my two cents.
>
> > > I would like to suggest a patch against master (although it may be
> worth
> > > backporting it) that makes it possible to listen on any unused port.
> >
>
At Thu, 20 Apr 2023 13:00:52 +0900, Michael Paquier wrote
in
> On Thu, Apr 20, 2023 at 12:56:32PM +0900, Kyotaro Horiguchi wrote:
> > Oh, I didn't realize there were differences in the
> > configurations. Good to know.
>
> C99 declarations are OK in v12~, so with v11 going out of sight in
>
At Thu, 20 Apr 2023 10:13:04 +0900, Michael Paquier wrote
in
> On Wed, Apr 19, 2023 at 08:50:13PM -0400, Melanie Plageman wrote:
> > I thought about changing parameter and local variable names to remove
> > the prefix, but in the original discussion folks seemed to think it made
> > sense to
On Thu, Apr 20, 2023 at 12:56:32PM +0900, Kyotaro Horiguchi wrote:
> Oh, I didn't realize there were differences in the
> configurations. Good to know.
C99 declarations are OK in v12~, so with v11 going out of sight in
approximately 6 month, it won't matter soon ;)
--
Michael
signature.asc
At Tue, 18 Apr 2023 11:35:16 +0900, Michael Paquier wrote
in
> On Mon, Apr 17, 2023 at 05:00:59PM +0900, Michael Paquier wrote:
> > This thinko has been introduced by 3b7ab43, so this needs to go down
> > to v11. I'll see to that.
>
> So done. mylodon is feeling unhappy about that, because
On Mon, Apr 17, 2023 at 5:32 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, April 10, 2023 7:20 PM Amit Kapila wrote:
> >
> > On Fri, Apr 7, 2023 at 8:52 AM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > Sorry, there was a miss when rebasing the patch which could cause the
> > > CFbot to fail and
On Wed, Apr 19, 2023 at 09:45:32PM -0400, Melanie Plageman wrote:
> Great, thanks! Once you feel an appropriate amount of time has passed,
> it would be great if you could apply it.
Sure. Probably on tomorrow morning, or Monday in the worst-case
scenario, I think..
> I forgot to add a note
On Wed, Apr 19, 2023 at 9:40 PM jack...@gmail.com wrote:
> As far as I know, when a index page is full, if you insert a new tuple
> here, you will split it into two pages.
> But pg won't delete the half tuples in the old page in real. So if there
> is another tuple inserted into this old
> page,
On Thu, Apr 20, 2023 at 10:13:04AM +0900, Michael Paquier wrote:
> On Wed, Apr 19, 2023 at 08:50:13PM -0400, Melanie Plageman wrote:
> > I thought about changing parameter and local variable names to remove
> > the prefix, but in the original discussion folks seemed to think it made
> > sense to
As far as I know, when a index page is full, if you insert a new tuple here,
you will split it into two pages.
But pg won't delete the half tuples in the old page in real. So if there is
another tuple inserted into this old
page, will pg split it again? I think that's not true, so how it solve
As far as I know, when a index page is full, if you insert a new tuple here,
you will split it into two pages.
But pg won't delete the half tuples in the old page in real. So if there is
another tuple inserted into this old
page, will pg split it again? I think that's not true, so how it solve
On Wed, Apr 19, 2023 at 2:31 PM Jonathan S. Katz wrote:
> To be clear, is the proposal to remove both "check_strxfrm_bug" and
> "TRUST_STRXFRM"?
>
> Given a bunch of folks who have expertise in this area of code all agree
> with removing the above as part of the collation cleanups targeted for
>
On Wed, Apr 19, 2023 at 08:50:13PM -0400, Melanie Plageman wrote:
> I thought about changing parameter and local variable names to remove
> the prefix, but in the original discussion folks seemed to think it made
> sense to leave the "C level" references with an "io" prefix. I think we
> could
On Wed, Mar 29, 2023 at 02:51:27PM +0200, Drouvot, Bertrand wrote:
> Just realized that more polishing was needed.
>
> Done in V2 attached.
That would be pretty cool to get that done in an automated way, I've
wanted that for a few years now. And I guess that a few others have
the same feeling
On Wed, Apr 19, 2023 at 8:42 PM Michael Paquier wrote:
>
> On Wed, Apr 19, 2023 at 01:54:21PM -0300, Fabrízio de Royes Mello wrote:
> > On Wed, Apr 19, 2023 at 1:27 PM Melanie Plageman
> > wrote:
> >> Over in [1], we discussed removing the "io" prefix from the columns
> >> "io_context" and
On Thu, Mar 30, 2023 at 12:41:27PM -0400, Corey Huinker wrote:
> I think this is good work, but I can't help thinking it would be easier to
> understand and maintain if we used a template engine like Text::Template,
> and filled out the template with the variant bits. I'll ask that question
> in
On Wed, Apr 19, 2023 at 8:41 PM Justin Pryzby wrote:
>
> On Wed, Apr 19, 2023 at 12:20:51PM -0700, Andres Freund wrote:
> > On 2023-04-19 12:16:24 -0500, Justin Pryzby wrote:
> > > On Wed, Apr 19, 2023 at 11:17:04AM -0400, Melanie Plageman wrote:
> > > > Ultimately this is probably fine. If we
On Wed, Apr 19, 2023 at 3:20 PM Andres Freund wrote:
> Hi,
>
> On 2023-04-19 12:16:24 -0500, Justin Pryzby wrote:
> > On Wed, Apr 19, 2023 at 11:17:04AM -0400, Melanie Plageman wrote:
> > > Ultimately this is probably fine. If we wanted to modify one of the
> > > existing tests to cover the
On Wed, Apr 19, 2023 at 01:54:21PM -0300, Fabrízio de Royes Mello wrote:
> On Wed, Apr 19, 2023 at 1:27 PM Melanie Plageman
> wrote:
>> Over in [1], we discussed removing the "io" prefix from the columns
>> "io_context" and "io_object" in pg_stat_io since they seem redundant
>> given the view
On Wed, Apr 19, 2023 at 12:20:51PM -0700, Andres Freund wrote:
> On 2023-04-19 12:16:24 -0500, Justin Pryzby wrote:
> > On Wed, Apr 19, 2023 at 11:17:04AM -0400, Melanie Plageman wrote:
> > > Ultimately this is probably fine. If we wanted to modify one of the
> > > existing tests to cover the
The revised patch is good. Please go ahead and commit whatever
phrasing you or the other committers find acceptable. I don't really
have any preferences in how this is exactly phrased, I just think it
should be mentioned in the docs.
On Mon, Apr 17, 2023 at 11:15 PM David Rowley wrote:
>
> On
On Wed, Apr 19, 2023 at 2:33 PM Melanie Plageman
wrote:
> As for alphabetical ordering vs importance ordering: while I do think
> that if a user does not know what parameter they are looking for, an
> alphabetical ordering is unhelpful, I also think the primary issue with
> grouping them by
Thank you! I just tried our benchmark and got a performance degration of around
28 %, which is way better than the last patch.
The simple query select * from generate_series(0, 1000) shows roughly 18.9
% degradation on my test server.
By raising initial_allocation_allowance and
On Wed, 19 Apr 2023 at 16:53, Miroslav Bendik wrote:
> > 2. You can use list_copy_head(root->query_pathkeys,
> > list_length(orderbyclauses)); instead of:
> >
> > + useful_pathkeys = list_truncate(list_copy(root->query_pathkeys),
> > + list_length(orderbyclauses));
>
> This code will crash if
Melanie Plageman writes:
> I do think we should consider deprecating and dropping documentation of
> the options that are supported without parentheses (relevant to commands
> like ANALYZE, CLUSTER, VACUUM, and others). It is fine if we keep the
> code to make ANALYZE VERBOSE work, but I don't
Hi,
Here are my two cents.
> > I would like to suggest a patch against master (although it may be worth
> > backporting it) that makes it possible to listen on any unused port.
>
> I think this is a bad idea, mainly because this:
>
> > Instead, with this patch, one can specify `port` as `0` (the
On Wed, Apr 19, 2023 at 2:39 PM Peter Geoghegan wrote:
>
> On Wed, Apr 19, 2023 at 3:04 AM Alvaro Herrera
> wrote:
> > > While I'm certain that nobody will agree with me on every little
> > > detail, I have to imagine that most would find my preferred ordering
> > > quite understandable and
Hi,
On 2023-04-19 12:16:24 -0500, Justin Pryzby wrote:
> On Wed, Apr 19, 2023 at 11:17:04AM -0400, Melanie Plageman wrote:
> > Ultimately this is probably fine. If we wanted to modify one of the
> > existing tests to cover the multi-batch case, changing the select
> > count(*) to a select * would
I wondered at [1] why ExecAggTransReparent doesn't do what you'd
guess from the name, that is reparent a supplied R/W expanded object
under the aggcontext even if it's not there already. I tried to
make it do that, and after I'd finished bandaging my wounds,
I wrote some commentary explaining why
On Wed, Apr 19, 2023 at 3:04 AM Alvaro Herrera wrote:
> > While I'm certain that nobody will agree with me on every little
> > detail, I have to imagine that most would find my preferred ordering
> > quite understandable and unsurprising, at a high level -- this is not
> > a hopelessly
On Tue, Apr 18, 2023 at 11:10 PM Michael Paquier wrote:
> Yeah, I agree that your suggestion is more useful for debugging when a
> record includes both a block image and some data associated to it.
> So, +1.
Okay, pushed that fix just now.
--
Peter Geoghegan
Hi,
On 2023-04-19 13:16:54 -0400, Robert Haas wrote:
> On Wed, Apr 19, 2023 at 12:54 PM Andres Freund wrote:
> > Interestingly, I haven't seen that as much in more recent benchmarks as it
> > used to. Partially I think because common s_b settings have gotten bigger, I
> > guess. But I wonder if
Hi,
I noticed that the numbers in pg_stat_io dont't quite add up to what I
expected in write heavy workloads. Particularly for checkpointer, the numbers
for "write" in log_checkpoints output are larger than what is visible in
pg_stat_io.
That partially is because log_checkpoints' "write" covers
On Wed, Apr 19, 2023 at 12:54 PM Andres Freund wrote:
> Interestingly, I haven't seen that as much in more recent benchmarks as it
> used to. Partially I think because common s_b settings have gotten bigger, I
> guess. But I wonder if we also accidentally improved something else, e.g. by
>
On Wed, Apr 19, 2023 at 11:17:04AM -0400, Melanie Plageman wrote:
> Ultimately this is probably fine. If we wanted to modify one of the
> existing tests to cover the multi-batch case, changing the select
> count(*) to a select * would do the trick. I imagine we wouldn't want to
> do this because
Hi,
On 2023-04-18 15:35:09 -0400, Greg Stark wrote:
> On Mon, 17 Apr 2023 at 17:45, Thomas Munro wrote:
> > It's something you'd
> > opt into for a dedicated database server along with other carefully
> > considered settings. It seems acceptable to me that if you set
> > io_direct to a
Hi,
On 2023-04-18 09:44:10 +1200, Thomas Munro wrote:
> * We have no plans to turn this on by default even when the later
> asynchronous machinery is proposed, and direct I/O starts to make more
> economic sense (think: your stream of small reads and writes will be
> converted to larger
Hi,
On 2023-04-19 10:11:32 -0400, Robert Haas wrote:
> On this point specifically, one fairly large problem that we have
> currently is that our buffer replacement algorithm is terrible. In
> workloads I've examined, either almost all buffers end up with a usage
> count of 5 or almost all buffers
On Wed, Apr 19, 2023 at 1:27 PM Melanie Plageman
wrote:
>
> Hi,
>
> Over in [1], we discussed removing the "io" prefix from the columns
> "io_context" and "io_object" in pg_stat_io since they seem redundant
> given the view name
>
LGTM. All tests passed and were built without warnings.
Regards
Ajit Awekar writes:
> Please find below simple repro for CacheMemoryContext memory leak
Hm, yeah, reproduced here.
> During anonymous block execution in the function "plpgsql_estate_setup", a
> local casting hash table gets created in SPI memory context. When hash
> table look up is performed
On Sat, Apr 15, 2023 at 5:15 PM Peter Geoghegan wrote:
> ISTM that b6a0d469ca has created an unmet need for a "--suite
> setup-running", which is analogous to "--suite setup" but works with
> "--setup running". That way there'd at least be a
> "postgresql:setup-running / install_test_files" test
Hi,
Over in [1], we discussed removing the "io" prefix from the columns
"io_context" and "io_object" in pg_stat_io since they seem redundant
given the view name
Attached patch does that.
- Melanie
[1]
On Wed, Apr 12, 2023 at 08:31:26PM -0400, Melanie Plageman wrote:
> On Wed, Apr 12, 2023 at 6:50 PM Thomas Munro wrote:
> > And if we're going to
> > exercise/test that case, should we do the non-parallel version too?
>
> I've added this. I thought if we were adding the serial case, we might
>
Joe Conway writes:
> I have wondered a few times, given the known issues with strxfrm, how is
> the use in selfuncs.c still ok. Has anyone taken a hard look at that?
On the one hand, we only need approximately-correct results in that
code. On the other, the result is fed to
Jim Jones writes:
> On 18.04.23 11:08, Ken Kato wrote:
>> I found that GRANT MAINTAIN is not tab-completed with ON, so here is a
>> patch.
> I've marked the CF entry as "ready for committer"
Yup, clearly an oversight. Pushed.
(One could wish that it didn't take touching three or so places in
On 4/18/23 21:19, Thomas Munro wrote:
On Tue, Apr 18, 2023 at 11:52 AM Michael Paquier wrote:
On Mon, Apr 17, 2023 at 03:40:14PM -0700, Peter Geoghegan wrote:
> +1 for getting rid of TRUST_STRXFRM.
+1
The situation is not improving fast, and requires hard work to follow
on each OS.
On 4/19/23 10:11, Robert Haas wrote:
On Tue, Apr 18, 2023 at 3:35 PM Greg Stark wrote:
Well I'm more optimistic... That may not always be impossible.
We've already added the ability to add more shared memory after
startup. We could implement the ability to add or remove shared buffer
On Tue, Apr 18, 2023 at 3:35 PM Greg Stark wrote:
> Well I'm more optimistic... That may not always be impossible.
> We've already added the ability to add more shared memory after
> startup. We could implement the ability to add or remove shared buffer
> segments after startup. And it
Thom Brown writes:
> I've attached a patch that removes some now redundant messaging about
> unsupported versions.
If we want to make that a policy, I think a lot more could be done
--- I remember noticing a documentation comment about some 8.x
version just recently.
However, "out of support"
On Tue, Apr 18, 2023 at 3:54 PM Greg Stark wrote:
> Well the way I understood Robert's proposal would be that you would
> set a protocol option which could be some name like
> SuperDuperExtension and then later send an extended message like X
> SuperDuper Extension ...
>
> The point being not so
On Tue, Apr 18, 2023 at 12:56 PM Dagfinn Ilmari Mannsåker
wrote:
> It still has magic numbers for the sizes of the fields, should those
> also be named constants?
I thought about that. It's arguable, but personally, I don't think
it's worth it. If the concern is greppability, having constants
Hi,
I've attached a patch that removes some now redundant messaging about
unsupported versions.
Regards
Thom
old_version_removal.patch
Description: Binary data
Hi all,
reading this blog post
https://www.depesz.com/2023/04/18/waiting-for-postgresql-16-add-array_sample-and-array_shuffle-functions/
I became aware of the new feature and had a look at it and the commit
Hi Team,
Could you please help me with this, It's urgent for the production
environment.
On Wed, Apr 19, 2023 at 3:44 PM shaurya jain <12345shau...@gmail.com> wrote:
> Hi Team,
>
> Could you please help, It's urgent for the production env?
>
> On Sun, Apr 16, 2023 at 2:40 AM shaurya jain
Please find below simple repro for CacheMemoryContext memory leak
create type two_int4s as (f1 int4, f2 int4);
create type two_int8s as (q1 int8, q2 int8);
PLpgSQL example:
do $$ declare c4 two_int4s; c8 two_int8s;
begin
c8 := row(1,2);
c4 := c8;
end$$;
Executing above plpgsql in same
On 18.04.23 11:08, Ken Kato wrote:
Hi hackers,
I found that GRANT MAINTAIN is not tab-completed with ON, so here is a
patch.
Hi,
the patch applies cleanly and now GRANT MAINTAIN tab-completes with ON.
For the sake of completeness I tested a whole statement:
postgres=# GRANT M
=>
On Fri, 14 Apr 2023 at 16:00, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Julien,
>
> > Sorry for the delay, I didn't had time to come back to it until this
> > afternoon.
>
> No issues, everyone is busy:-).
>
> > I don't think that your analysis is correct. Slots are guaranteed to be
> > stopped
On 2023-Apr-18, Peter Geoghegan wrote:
> While I'm certain that nobody will agree with me on every little
> detail, I have to imagine that most would find my preferred ordering
> quite understandable and unsurprising, at a high level -- this is not
> a hopelessly idiosyncratic ranking, that could
On Fri, 14 Apr 2023 at 16:00, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Julien,
>
> > Sorry for the delay, I didn't had time to come back to it until this
> > afternoon.
>
> No issues, everyone is busy:-).
>
> > I don't think that your analysis is correct. Slots are guaranteed to be
> > stopped
> On 19 Apr 2023, at 10:52, Peter Eisentraut
> wrote:
> For reference material, easy lookup should be a priority.
+1. Alphabetical ordering is consistent with POLA.
> For a narrative chapter on VACUUM, you can introduce the options in any other
> suitable order.
I would even phrase it such
On 19.04.23 01:30, Peter Geoghegan wrote:
I'd be interested to know if you could tell me if SKIP_LOCKED has more
importance than INDEX_CLEANUP, for example. If you can, it would seem
like trying to say apples are more important than oranges, or
vice-versa.
I don't accept your premise that the
Here are some more WIP review comments for the patch 0002-2023_04_07-2
This is a WIP review in parts because the patch was quite large, so it
is taking a while...
WIP part 1 [1] was posted 17/4.
WIP part 2 [2] was posted 17/4.
This is WIP part 3
==
doc/src/sgml/logical-replication.sgml
Sorry for spamming, but I found a more elegant way to check if
query_paths is NIL without modified list_copy_head.
Here is a third iteration of this patch.
--
Miroslav
diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c
index b8000da56d..735b41552a 100644
Thanks for feedback
> 2. You can use list_copy_head(root->query_pathkeys,
> list_length(orderbyclauses)); instead of:
>
> + useful_pathkeys = list_truncate(list_copy(root->query_pathkeys),
> + list_length(orderbyclauses));
This code will crash if query_pathkeys is NIL. I need either modify
On Mon, Apr 17, 2023 at 8:49 PM Masahiko Sawada
wrote:
> > - With lazy expansion and single-value leaves, the root of a radix tree
can point to a single leaf. That might get rid of the need to track
TBMStatus, since setting a single-leaf tree should be cheap.
> >
>
> Instead of introducing
> From: Masahiko Sawada
> > > While writing a PoC patch, I found some difficulties in this idea.
> > > First, I tried to add schemaname+relname to pg_subscription_rel but
> > > I could not define the primary key of pg_subscription_rel. The
> > > primary key on (srsubid, srrelid) doesn't work
On Tue, Apr 18, 2023 at 02:36:40PM -0700, Peter Geoghegan wrote:
> This isn't just a theoretical issue. Currently, we won't display
> detailed descriptions of block data whenever wal_consistency_checking
> happens to be in use. At least for those records with relevant block
> data available to
70 matches
Mail list logo
