Sorry for missing this.
At Thu, 27 Jan 2022 19:26:39 +0900, Fujii Masao
wrote in
>
> On 2022/01/27 17:10, Kyotaro Horiguchi wrote:
> > I don't object to adding more meaningful replacements, but more escape
> > sequence makes me anxious about the increased easiness of exceeding
> > the size
Hi, Ashutosh.
At Tue, 8 Feb 2022 18:35:34 +0530, Ashutosh Sharma
wrote in
> Here are some of my review comments on the v11 patch:
Thank you for taking a look on this.
> - (errmsg_internal("reached end of WAL in
> pg_wal, entering archive recovery")));
> +
On Wed, Feb 9, 2022 at 1:21 AM Peter Geoghegan wrote:
>
> The btree side of this shouldn't care at all about dead tuples (in
> general we focus way too much on dead tuples, and way too little on
> pages). With bottom-up index deletion the number of dead tuples in the
> index is just about
On Tue, Feb 8, 2022 at 10:42 PM Peter Geoghegan wrote:
>
> On Sun, Feb 6, 2022 at 11:25 PM Dilip Kumar wrote:
> > > One thing we could try doing in order to make that easier would be:
> > > tweak things so that when autovacuum vacuums the table, it only
> > > vacuums the indexes if they meet
On Tue, Feb 8, 2022 3:18 AM Andres Freund wrote:
>
> On 2022-02-07 08:44:00 +0530, Amit Kapila wrote:
> > Right, and it is getting changed. We are just printing the first 200
> > characters (by using SQL [1]) from the decoded tuple so what is shown
> > in the results is the initial 200 bytes.
>
On Tue, Feb 08, 2022 at 10:57:37PM -0500, Robert Haas wrote:
> Well I didn't do anything myself except review and commit Nathan's
> patch, so I suppose you mean he could have done that, but fair enough.
> I don't mind if you want to change it around.
Okay, I'd rather apply the same rule
On Wed, Feb 9, 2022 at 8:26 AM Michael Paquier wrote:
>
> On Wed, Feb 02, 2022 at 10:06:13AM +0100, Daniel Gustafsson wrote:
> > The leak itself is clearly not something to worry about wrt memory pressure.
> > We do read into tmp and free it in other places in the same function though
> > (as
>
On Tue, Feb 8, 2022 at 10:39 PM Robert Haas wrote:
>
> I have been tied up with other things for a bit now and have not had
> time to look at this thread; sorry about that. I have a little more
> time available now so I thought I would take a look at this again and
> see where things stand.
At Wed, 09 Feb 2022 12:04:51 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 9 Feb 2022 11:01:57 +0900, Fujii Masao
> wrote in
> > Agreed. So barring any objection, I will commit that patch.
>
> Sorry for being late, but I don't like the function names.
>
> +xid8_larger(PG_FUNCTION_ARGS)
On Tue, Feb 8, 2022 at 9:38 PM Michael Paquier wrote:
> On Tue, Feb 08, 2022 at 04:12:26PM -0500, Robert Haas wrote:
> > After some investigation I've determined that it's no longer Friday
> > afternoon. I also spent time investigating whether the patch had
> > problems that would make me
On Tue, Feb 8, 2022 at 7:38 PM Joe Conway wrote:
> If we were to start all over again with this feature my vote would be to
> do things differently than we have done. I would not have called them
> predefined roles, and I would have used attributes of roles (e.g. make
> rolsuper into a bitmap
At Wed, 9 Feb 2022 11:01:57 +0900, Fujii Masao
wrote in
> Agreed. So barring any objection, I will commit that patch.
Sorry for being late, but I don't like the function names.
+xid8_larger(PG_FUNCTION_ARGS)
+xid8_smaller(PG_FUNCTION_ARGS)
Aren't they named like xid8gt and xid8lt
On Wed, Feb 02, 2022 at 10:06:13AM +0100, Daniel Gustafsson wrote:
> The leak itself is clearly not something to worry about wrt memory pressure.
> We do read into tmp and free it in other places in the same function though
> (as
> you note above), so for code consistency alone this is worth
Hi, Bharath.
At Tue, 8 Feb 2022 14:33:01 +0530, Bharath Rupireddy
wrote in
> On Tue, Feb 8, 2022 at 2:10 PM Kyotaro Horiguchi
> wrote:
> > > Thus.. the attached removes the ambiguity of of the proposed patch
> > > about the LSNs in the restartpoint-ending log message.
> >
> > Thoughts?
>
>
Hi,
I just noticed that e2c52beecd (adding PeterE in Cc) added a resetPQExpBuffer()
which seems unnecessary since the variable is untouched since the initial
createPQExpBuffer().
Simple patch attached.
>From 1ebddb696af3b77f7d373034b938a358529a9ea1 Mon Sep 17 00:00:00 2001
From: Julien Rouhaud
2022年2月9日(水) 11:21 Michael Paquier :
>
> On Tue, Feb 08, 2022 at 11:26:41AM -0500, Robert Haas wrote:
> > From that point of view, there's no downside to removing from the
> > server the old syntax for BASE_BACKUP and the old protocol for taking
> > backups. We can't remove anything from
On Tue, Feb 08, 2022 at 04:12:26PM -0500, Robert Haas wrote:
> After some investigation I've determined that it's no longer Friday
> afternoon. I also spent time investigating whether the patch had
> problems that would make me uncomfortable with the idea of committing
> it, and I did not find
On Wed, Feb 9, 2022 at 7:16 AM Euler Taveira wrote:
>
> On Tue, Feb 8, 2022, at 10:18 PM, tanghy.f...@fujitsu.com wrote:
>
> 2)
> + /*
> + * Check if the old tuple's attribute is stored externally and is a
> + * member of external_cols.
> + */
> + if (VARATT_IS_EXTERNAL((struct varlena *)
On Tue, Feb 08, 2022 at 11:26:41AM -0500, Robert Haas wrote:
> From that point of view, there's no downside to removing from the
> server the old syntax for BASE_BACKUP and the old protocol for taking
> backups. We can't remove anything from pg_basebackup, because it is
> our practice to make new
On Wed, Feb 9, 2022 at 7:07 AM Peter Smith wrote:
>
> 2. src/backend/commands/publicationcmds.c -
> contain_mutable_or_ud_functions_checker
>
> +/* check_functions_in_node callback */
> +static bool
> +contain_mutable_or_user_functions_checker(Oid func_id, void *context)
> +{
> + return
On 2022/02/09 8:49, Ken Kato wrote:
On 2022-02-08 23:16, Fujii Masao wrote:
If you want to avoid the line longer than 80 columns, you should break
it into two or more rather than remove the test code, I think. What to
test is more important than formatting.
Also the following descriptions
On Tue, Feb 8, 2022, at 10:18 PM, tanghy.f...@fujitsu.com wrote:
> 2)
> + /*
> + * Check if the old tuple's attribute is stored externally and is a
> + * member of external_cols.
> + */
> + if (VARATT_IS_EXTERNAL((struct varlena *) DatumGetPointer(value1)) &&
> + bms_is_member(attrnum -
I did a review of the v79 patch. Below are my review comments:
==
1. doc/src/sgml/ref/create_publication.sgml - CREATE PUBLICATION
The commit message for v79-0001 says:
If your publication contains a partitioned table, the publication parameter
publish_via_partition_root determines if it
On Tue, Feb 08, 2022 at 01:06:29PM +0900, Michael Paquier wrote:
> Makes sense. check_guc also checks after this pattern.
Okay, I have done all the adjustments you mentioned, added a couple of
comments and applied the patch. If the buildfarm is happy, I'll
go retire check_guc.
--
Michael
On Mon, Feb 7, 2022 2:55 PM Amit Kapila wrote:
>
> On Sat, Feb 5, 2022 at 6:10 AM Amit Kapila wrote:
> >
> > On Fri, Feb 4, 2022 at 9:06 PM Alvaro Herrera
> > wrote:
> > >
> > >
> > > I have some suggestions
> > > on the comments and docs though.
> > >
> >
> > Thanks, your suggestions look
On Mon, 2022-02-07 at 17:29 +0900, Kyotaro Horiguchi wrote:
> At Fri, 4 Feb 2022 17:06:53 +, Jacob Champion
> wrote in
> > That works a lot better than what I had in my head. Done that way in
> > v4. Thanks!
>
> Thanks!
>
> 0002:
>
> +#define PGSQL_AF_INET (AF_INET + 0)
> +#define
On 2/8/22 10:07, Robert Haas wrote:
On Tue, Feb 8, 2022 at 10:00 AM Joshua Brindle
wrote:
4 predefined roles currently use has_privs_of_role in master.
Further, pg_monitor, as an SQL-only predefined role, also behaves
consistently with the INHERIT rules that other roles do.
In order for
Hi,
Thank you for updating the patch.
I agree with the documentation and program.
How about adding the test for %c (Session ID)?
(Adding the test for %C (cluster_name) seems difficult.)
Regards,
Ryohei Takahashi
On 2022-02-08 23:16, Fujii Masao wrote:
If you want to avoid the line longer than 80 columns, you should break
it into two or more rather than remove the test code, I think. What to
test is more important than formatting.
Also the following descriptions about formatting would be helpful.
Andres Freund writes:
> On 2022-02-07 20:42:09 -0500, Tom Lane wrote:
>> ... Peter just copied the logic in 7662419f1. Considering that
>> the point of 7662419f1 was to get rid of MakeMaker, maybe we no
>> longer needed that at that point.
> Yea. And maybe what was broken in 2001 isn't broken
On 1/24/22 00:16, Corey Huinker wrote:
- Table schemas change, and all (SV active) AV items would logically
need to fit the active schema or be updated to do so. Different story
for SV, nothing there should ever need to be changed.
Yeah, there's a mess (which you state below) about what
On Tue, Feb 8, 2022 at 4:11 PM David Rowley wrote:
> I still feel this is quite a bit of code for what we're getting here.
> I'd be more for it if the path traversal function existed for some
> other reason and I was just adding the callback functions and Asserts.
>
> I'm keen to hear what others
On Tue, Feb 8, 2022 at 1:11 PM David Rowley wrote:
> Thanks for having a look at this.
>
> On Fri, 4 Feb 2022 at 13:48, Robert Haas wrote:
> > I think the actual rule is: every path under a Gather or GatherMerge
> > must be parallel-safe.
>
> I've adjusted the patch so that it counts
On Fri, Feb 4, 2022 at 3:27 PM Robert Haas wrote:
> Great. I'll take a look at this next week, but not right now, mostly
> because it's Friday afternoon and if I commit it and anything breaks I
> don't want to end up having to fix it on the weekend if I can avoid
> it.
After some investigation
Thanks for having a look at this.
On Fri, 4 Feb 2022 at 13:48, Robert Haas wrote:
> I think the actual rule is: every path under a Gather or GatherMerge
> must be parallel-safe.
I've adjusted the patch so that it counts parallel_aware and
parallel_safe Paths independently and verifies
On Mon, Feb 7, 2022 at 4:22 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> While working on pg_replslotdata tool [1], it was observed that some
> of the replication slot structures/enums/macros such as
> ReplicationSlotPersistentData, ReplicationSlotPersistency,
> ReplicationSlotOnDisk,
Julien Rouhaud writes:
> On Mon, Feb 07, 2022 at 02:00:25PM -0500, Tom Lane wrote:
>> Not too surprisingly, these patches broke during the commitfest.
>> Here's a rebased version.
>> I'm not sure that anyone wants to review these in detail ...
>> should I just go ahead and push them?
> I don't
On Sun, Dec 12, 2021 at 3:09 AM Dilip Kumar wrote:
> Correct, I have done this cleanup, apart from this we have dropped the
> fsyc request in create database failure case as well and also need to
> drop buffer in error case of creatdb as well as movedb. I have also
> fixed the other issue for
On Tue, Feb 8, 2022 at 10:58 AM Robert Haas wrote:
> Right, that's why I asked the question. If we're going to ask the
> index AM whether it would like to be vacuumed right now, we're going
> to have to put some logic into the index AM that knows how to answer
> that question. But if we don't
Peter Eisentraut writes:
> I had to do some analysis on the "sanity" tests in the regression test
> suite (opr_sanity, type_sanity) recently, and I found some of the
> queries very confusing. One main stumbling block is that for some
> probably ancient reason many of the older queries are
On 02/07/22 15:14, Chapman Flack wrote:
> It has since occurred to me that another benefit of having a
> transform_validator per PL would be immediate error reporting
> if someone, for whatever reason, tries out CREATE TRANSFORM
> for a PL that doesn't grok transforms.
The same could be achieved,
On Tue, Feb 8, 2022 at 1:52 PM David Steele wrote:
> I'm aware of several tools that use pg_basebackup but they are using the
> command-line tool, not the server protocol directly.
Good to know.
> Personally, I'm in favor of simplifying the code on the server side. If
> anyone is using the
On Tue, Feb 8, 2022 at 12:50 PM Peter Geoghegan wrote:
> > It's not clear to me that we have enough information to make good
> > decisions about which indexes to vacuum and which indexes to skip.
>
> What if "extra vacuuming, not skipping vacuuming" was not just an
> abstract goal, but an actual
On 2/8/22 12:39, Robert Haas wrote:
On Tue, Feb 8, 2022 at 1:03 PM Justin Pryzby wrote:
I created this and added that for visibility and so it's not forgotten.
ISTM that could be done post-freeze, although I don't know if that's useful or
important.
On Tue, Feb 8, 2022 at 1:03 PM Justin Pryzby wrote:
> I created this and added that for visibility and so it's not forgotten.
> ISTM that could be done post-freeze, although I don't know if that's useful or
> important.
>
> https://wiki.postgresql.org/wiki/PostgreSQL_15_Open_Items
Thanks. I feel
On Tue, Feb 08, 2022 at 11:26:41AM -0500, Robert Haas wrote:
> Patches for the nuking are attached. If nobody writes back, I'm going
> to assume that means nobody cares, and commit these some time before
> feature freeze. If one or more people do write back, then my plan is
> to see what they have
On Tue, Feb 8, 2022 at 9:33 AM Robert Haas wrote:
> On Tue, Feb 8, 2022 at 12:12 PM Peter Geoghegan wrote:
> > I believe that the main benefit of the dead TID conveyor belt (outside
> > of global index use cases) will be to enable us to do more (much more)
> > index vacuuming for one index in
On Tue, Feb 8, 2022 at 12:12 PM Peter Geoghegan wrote:
> I believe that the main benefit of the dead TID conveyor belt (outside
> of global index use cases) will be to enable us to do more (much more)
> index vacuuming for one index in particular. So it's not really about
> doing less index
On Sun, Feb 6, 2022 at 11:25 PM Dilip Kumar wrote:
> > One thing we could try doing in order to make that easier would be:
> > tweak things so that when autovacuum vacuums the table, it only
> > vacuums the indexes if they meet some threshold for bloat. I'm not
> > sure exactly what happens with
On Wed, Dec 22, 2021 at 9:32 AM Ashutosh Sharma wrote:
> I couldn't find the mdpostchkpt() function. Are you talking about
> SyncPostCheckpoint() ? Anyway, as you have rightly said, we need to
> unlink all the files available inside the dst_tablespaceoid/dst_dboid/
> directory by scanning the
On Mon, Dec 6, 2021 at 12:45 PM Robert Haas wrote:
> So for example, imagine tests with 1GB of shard_buffers, 8GB, and
> 64GB. And template databases with sizes of whatever the default is,
> 1GB, 10GB, 100GB. Repeatedly make 75% of the pages dirty and then
> create a new database from one of the
Hi,
Commit 0ba281cb4bf9f5f65529dfa4c8282abb734dd454 added a new syntax for
the BASE_BACKUP command, and commit
cc333f32336f5146b75190f57ef587dff225f565 added a new COPY subprotocol
for taking base backups. In both cases, I preserved backward
compatibility. However, nothing in PostgreSQL itself
On 2/8/22 09:24, Daniel Gustafsson wrote:
>
> The attached v2 takes a stab at fixing up the POD sections.
There a capitalization typo in SSL/Backend/OpenSSL.pm - looks like
that's my fault:
+ my $backend = SSL::backend::OpenSSL->new();
Also, I think we should document that
On 2022-02-03 17:09, Robert Treat wrote:
On Wed, Feb 2, 2022 at 7:59 AM torikoshia
wrote:
2022-02-01 01:51, Fujii Masao wrote:
> +Note that nested statements (statements executed inside a
> function) are not
> +considered for logging. Only the plan of the most deeply nested
> query
On Tue, Feb 8, 2022 at 10:00 AM Joshua Brindle
wrote:
> 4 predefined roles currently use has_privs_of_role in master.
>
> Further, pg_monitor, as an SQL-only predefined role, also behaves
> consistently with the INHERIT rules that other roles do.
>
> In order for SQL-only predefined roles to
On 2022-Feb-07, Tom Lane wrote:
> In any case, the particular example we're looking at here is connection
> loss, which is not something that should greatly concern us as far as
> pipeline semantics are concerned, because you're not getting any more
> pipelined results anyway if that happens. In
On Tue, Feb 8, 2022 at 8:46 AM Robert Haas wrote:
>
> On Tue, Feb 8, 2022 at 6:59 AM Joe Conway wrote:
> > This is similar to bob's access to the default superuser privilege to
> > read data in someone else's table (must SET ROLE to access that capability).
> >
> > But it is different from bob's
On Tue, Feb 8, 2022 at 2:02 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-02-07 13:38:38 +0530, Ashutosh Sharma wrote:
> > Are you talking about this scenario - what if the logical replication
> > slot on the publisher is dropped, but is being referenced by the
> > standby where the slot is
> On 7 Feb 2022, at 17:29, Andrew Dunstan wrote:
> On 2/2/22 14:50, Daniel Gustafsson wrote:
>>> On 2 Feb 2022, at 17:09, Andrew Dunstan wrote:
>>> On 2/2/22 08:26, Daniel Gustafsson wrote:
Thoughts? I'm fairly sure there are many crimes against Perl in this
patch,
I'm happy to
On 2022/02/08 18:43, Ken Kato wrote:
On 2022-02-08 15:34, Fujii Masao wrote:
Thanks for updating the patch! It basically looks good to me. I
applied the following small changes to the patch. Updated version of
the patch attached. Could you review this version?
Thank you for the patch!
It
On 2/7/22 21:40, Tom Lane wrote:
> I wrote:
>> Andres Freund writes:
>>> What is the reason behind subtracting ccdlflags?
>> It looks like the coding actually originated here:
>> commit f5d0c6cad5bb2706e0e63f3f8f32e431ea428100
> Ah, here's the thread leading up to that:
>
>
On Mon, Feb 07, 2022 at 04:44:24PM +0100, Peter Eisentraut wrote:
> On 07.02.22 11:29, Julien Rouhaud wrote:
> > - that's not really something new with this patch, but should we output the
> >collation version info or mismatch info in \l / \dO?
>
> It's a possibility. Perhaps there is a
I had to do some analysis on the "sanity" tests in the regression test
suite (opr_sanity, type_sanity) recently, and I found some of the
queries very confusing. One main stumbling block is that for some
probably ancient reason many of the older queries are written with
correlation names p1,
On Tue, Feb 8, 2022 at 6:59 AM Joe Conway wrote:
> This is similar to bob's access to the default superuser privilege to
> read data in someone else's table (must SET ROLE to access that capability).
>
> But it is different from bob's access to inherited privileges which are
> GRANTed:
Yeah. I
On 07.02.22 20:24, Andres Freund wrote:
To be honest, I do not really understand the logic behind when autoconf ends
up with #defines that define a macro to 0/1 and when a macro ends defined/or
not and when we end up with a macro defined to 1 or not defined at all.
The default is to define to
On Tue, Feb 8, 2022 at 8:01 AM houzj.f...@fujitsu.com
wrote:
>
> >
> > 12. src/backend/replication/pgoutput/pgoutput.c - get_rel_sync_entry
> >
> > + /*
> > + * Initialize the row filter after getting the final publish_as_relid
> > + * as we only evaluate the row filter of the relation which we
Hi,
Here are some of my review comments on the v11 patch:
- (errmsg_internal("reached end of WAL in
pg_wal, entering archive recovery")));
+ (errmsg_internal("reached end of WAL at %X/%X
on timeline %u in %s during crash recovery, entering archive
On Tue, Feb 08, 2022 at 12:14:02PM +0100, Peter Eisentraut wrote:
> On 07.02.22 17:08, Julien Rouhaud wrote:
> > There's so limited testing in collate.* regression tests, so I thought it
> > would
> > be ok to add it there. At least some ALTER DATABASE ... REFRESH VERSION
> > would
> > be good,
Stephen Frost wrote:
> Perhaps this is all too meta and we need to work through some specific
> ideas around just what this would look like. In particular, thinking
> about what this API would look like and how it would be used by
> reorderbuffer.c, which builds up changes in memory and then
Here I'm starting a new thread to discuss a topic that's related to the
Transparent Data Encryption (TDE), but could be useful even without that. The
problem has been addressed somehow in the Cybertec TDE fork, and I can post
the code here if it helps. However, after reading [1] (and the posts
On 2/7/22 12:09, Robert Haas wrote:
On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote:
It is confusing and IMHO dangerous that the predefined roles currently
work differently than regular roles eith respect to privilege inheritance.
I feel like that's kind of a conclusory statement, as
On 07.02.22 17:08, Julien Rouhaud wrote:
There's so limited testing in collate.* regression tests, so I thought it would
be ok to add it there. At least some ALTER DATABASE ... REFRESH VERSION would
be good, similarly to collation-level versioning.
I don't think you can run ALTER DATABASE
Hello,
I was wondering if pg_restore should call VACUUM ANALYZE for all tables,
after the "COPY" stage, and before the "post-data" stage.
Indeed, without such a VACUUM, the visibility map isn't available.
Depending on the size of the tables and on the configuration, a foreign
key constraint
On Tue, Feb 8, 2022 at 12:48 AM Andres Freund wrote:
>
> On 2022-02-07 08:44:00 +0530, Amit Kapila wrote:
> > Right, and it is getting changed. We are just printing the first 200
> > characters (by using SQL [1]) from the decoded tuple so what is shown
> > in the results is the initial 200 bytes.
On 2022-02-08 15:34, Fujii Masao wrote:
Thanks for updating the patch! It basically looks good to me. I
applied the following small changes to the patch. Updated version of
the patch attached. Could you review this version?
Thank you for the patch!
It looks good to me!
I'm not sure how
Dear Wang,
Thank you for making a patch.
I applied your patch and confirmed that codes passed regression test.
I put a short reviewing:
```
+ static int skipped_changes_count = 0;
+ /*
+* Conservatively, at least 150,000 changes can be skipped in 1s.
+*
+*
On Tue, Feb 8, 2022 at 2:10 PM Kyotaro Horiguchi
wrote:
> > Thus.. the attached removes the ambiguity of of the proposed patch
> > about the LSNs in the restartpoint-ending log message.
>
> Thoughts?
Thanks for the patch. I have few comments on the
Mmm.. checkpoint and checkpointer are quite confusing in this context..
At Tue, 08 Feb 2022 16:58:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Mon, 7 Feb 2022 13:51:31 +0900, Fujii Masao
> wrote in
> >
> >
> > On 2022/02/07 12:02, Kyotaro Horiguchi wrote:
> > > - If any later
At Tue, 8 Feb 2022 01:13:44 +0900, Fujii Masao
wrote in
>
>
> On 2022/02/02 21:59, torikoshia wrote:
> >> This may cause users to misunderstand that pg_log_query_plan() fails
> >> while the target backend is holding *any* locks? Isn't it better to
> >> mention "page-level locks", instead? So
79 matches
Mail list logo
