This is great work thanks for the Realisation Update.
Euler Taveira schrieb am Sa., 4. Dez. 2021, 00:13:
> On Thu, Dec 2, 2021, at 4:18 AM, Peter Smith wrote:
>
> PSA a new v44* patch set.
>
> We are actively developing this feature for some months and we improved
> this
> feature a lot. This h
On Thu, Dec 2, 2021 at 3:11 AM Daniel Gustafsson wrote:
> > On 3 Nov 2021, at 12:02, Daniel Gustafsson wrote:
> >
> > This patch doesn't compile on Windows according to Appveyor, seemingly
> > because
> > of a syntax error in the new win32ntdll.h file, but the MSVC logs are hard
> > on
> > the
On Fri, Dec 03, 2021 at 05:46:51PM +, Bossart, Nathan wrote:
> Perhaps this patch should be marked Rejected in favor of that one,
> then.
Let's do so, then. I can also get behind the coverage argument for
this code path.
--
Michael
signature.asc
Description: PGP signature
On Tue, Nov 30, 2021 at 3:14 AM Andrew Dunstan wrote:
> choco install -y Carbon
> Import-Module Carbon
> Grant-CPrivilege -Identity myuser -Privilege SeCreateSymbolicLinkPrivilege
Interesting. Well, I found the problem with my last patch (to wit:
junction points must be absolute, unl
Chapman Flack writes:
> If a person wanted to refer to those tuples after SPI_finish,
> would it be a dangerous idea to just reparent that context into one
> that will live longer, shortly before SPI_finish is called?
Seems kinda dangerous to me ...
> AtEOSubXact_SPI can free tuptables retail, b
Hi,
When SPI produces a tuple table result, its DestReceiver makes a new
"SPI TupTable" memory context, as a child of the SPI Proc context,
and the received tuples get copied into it. It goes away at SPI_finish,
as a consequence of its parent SPI Proc context going away.
If a person wanted to ref
On 12/03/21 14:12, Tom Lane wrote:
> This reminds me of something I've been intending to bring up, which
> is that the "char" type is not very encoding-safe. charout() for
> example just regurgitates the single byte as-is.
I wonder if maybe what to do about that lies downstream of some other
thou
On Thu, Dec 2, 2021 at 8:59 PM Tatsuo Ishii wrote:
> > On 2021-12-03 10:28:34 +0900, Tatsuo Ishii wrote:
> >> It seems there are no environment variables corresponding to keepalives
> >> etc. connection parameters in libpq. Is there any reason for this?
> >
> > PGOPTIONS='-c tcp_keepalive_*=foo' s
On Fri, Dec 3, 2021 at 1:30 PM Tom Lane wrote:
> What's most likely to happen IMO is that committers will just start
> back-patching essential portability fixes into out-of-support-but-
> still-in-the-buildability-window branches, contemporaneously with
> the original fix. Yeah, that does mean mo
On Fri, Dec 03, 2021 at 03:13:24PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 12/3/21 14:42, Tom Lane wrote:
> >> Right, I envisioned that ASCII behaves the same but we'd use
> >> a numeric representation for high-bit-set values. These
> >> cases could be told apart fairly easily by c
Andrew Dunstan writes:
> On 12/3/21 14:42, Tom Lane wrote:
>> Right, I envisioned that ASCII behaves the same but we'd use
>> a numeric representation for high-bit-set values. These
>> cases could be told apart fairly easily by charin(), since
>> the numeric representation would always be three d
On 12/3/21 14:42, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 12/3/21 14:12, Tom Lane wrote:
>>> I can think of at least three ways we might address this:
>>>
>>> * Forbid all non-ASCII values for type "char". This results in
>>> simple and portable semantics, but it might break usages that
Hello,
Please find attached a patch for the daitch_mokotoff module.
This implements the Daitch-Mokotoff Soundex System, as described in
https://www.avotaynu.com/soundex.htm
The module is used in production at Finance Norway.
In order to verify correctness, I have compared generated soundex code
Thanks again! I really appreciate the thorough review.
I have combined responses to all three of your emails below.
Let me know if it is more confusing to do it this way.
On Wed, Dec 1, 2021 at 6:59 PM Justin Pryzby wrote:
>
> On Wed, Dec 01, 2021 at 05:00:14PM -0500, Melanie Plageman wrote:
> >
Andrew Dunstan writes:
> On 12/3/21 14:12, Tom Lane wrote:
>> I can think of at least three ways we might address this:
>>
>> * Forbid all non-ASCII values for type "char". This results in
>> simple and portable semantics, but it might break usages that
>> work okay today.
>>
>> * Allow such va
On 12/3/21 14:12, Tom Lane wrote:
> [ breaking off a different new thread ]
>
> Chapman Flack writes:
>> Then there's "char". It's category S, but does not apply the server
>> encoding. You could call it an 8-bit int type, but it's typically used
>> as a character, making it well-defined for ASC
[ breaking off a different new thread ]
Chapman Flack writes:
> Then there's "char". It's category S, but does not apply the server
> encoding. You could call it an 8-bit int type, but it's typically used
> as a character, making it well-defined for ASCII values and not so
> for others, just like
[ breaking this off to an actual new thread ]
Chapman Flack writes:
> Is there any way to find out, from the catalogs or in any automatable way,
> which types are implemented with a dependence on the database encoding
> (or on some encoding)?
Nope. Base types are quite opaque; we don't have a l
On 12/02/21 16:22, Tom Lane wrote:
> ... types belonging to the STRING category, which are predicated
> on the assumption that such types are reasonably general-purpose
> string types.
This prods me to submit a question I've been incubating for a while.
Is there any way to find out, from the cata
Peter Eisentraut writes:
> On 02.12.21 23:16, Andres Freund wrote:
>> I realize it's more complicated for users, but a policy based on supporting a
>> certain number of out-of-support branches calculated from the newest major
>> version is more realistic. I'd personally go for something like newes
On 12/3/21, 5:57 AM, "Bharath Rupireddy"
wrote:
> On Fri, Dec 3, 2021 at 3:01 AM Bossart, Nathan wrote:
>>
>> On 12/1/21, 6:48 PM, "Bharath Rupireddy"
>> wrote:
>> > +1 for the overall idea of making the checkpoint faster. In fact, we
>> > here at our team have been thinking about this problem
Andrew Dunstan writes:
> On 12/3/21 12:10, Tom Lane wrote:
>> I experimented to see what this would entail exactly. Using
>> current macOS (Apple clang version 13.0.0) on M1 hardware,
>> I built with minimal configure options (--enable-debug --enable-cassert)
>> and ran the core regression tests.
On 12/3/21, 6:21 AM, "Bharath Rupireddy"
wrote:
> +1 to add here in the "Parameter Names and Values section", but do we
> want to backlink every string parameter to this section? I think it
> needs more effort. IMO, we can just backlink for
> shared_preload_libraries alone. Thoughts?
IMO this is
On 12/3/21, 7:40 AM, "Peter Geoghegan" wrote:
> If my patch to unite vacuum verbose and the autovacuum logging gets
> in, then this issue also goes away.
Perhaps this patch should be marked Rejected in favor of that one,
then.
Nathan
Bharath Rupireddy writes:
> On Fri, Dec 3, 2021 at 1:43 PM Daniel Gustafsson wrote:
>> On 3 Dec 2021, at 08:58, Bharath Rupireddy
>> wrote:
>>> It seems like there's an extra Logging_collector check before calling
>>> SysLogger_Start().
>> I think the code reads clearer with the Logging_collec
Bharath Rupireddy writes:
> Although the pg_stat_activity has no entry for the sys logger and
> stats collector (because of no shared memory access), the wait events
> WAIT_EVENT_SYSLOGGER_MAIN and WAIT_EVENT_PGSTAT_MAIN are defined. They
> seem to be unnecessary. Passing 0 or some other undefined
On 12/3/21 12:10, Tom Lane wrote:
> Peter Eisentraut writes:
>> [ policy requiring that 9.2 and up be kept buildable, as of today ]
> I experimented to see what this would entail exactly. Using
> current macOS (Apple clang version 13.0.0) on M1 hardware,
> I built with minimal configure options
On 12/2/21, 11:57 PM, "tanghy.f...@fujitsu.com" wrote:
> Thanks for your patch.
> I tested it and it fixed this problem as expected. It also passed "make
> check-world".
+1, the patch looks good to me, too. My only other suggestion would
be to move IsSchemaPublication() to pg_publication.c
Nat
On Thu, Dec 2, 2021 at 9:24 PM Justin Pryzby wrote:
> On Thu, Nov 04, 2021 at 12:44:45AM +0100, Tomas Vondra wrote:
> > >> And I'm not sure we do the right thing after removing children, for
> example
> > >> (that should drop the inheritance stats, I guess).
>
> > > Do you mean for inheritance on
Peter Eisentraut writes:
> [ policy requiring that 9.2 and up be kept buildable, as of today ]
I experimented to see what this would entail exactly. Using
current macOS (Apple clang version 13.0.0) on M1 hardware,
I built with minimal configure options (--enable-debug --enable-cassert)
and ran t
> On Dec 2, 2021, at 1:29 AM, Amit Kapila wrote:
>
> If we want to maintain the property that subscriptions can only be
> owned by superuser for your first version then isn't a simple check
> like ((!superuser()) for each of the operations is sufficient?
As things stand today, nothing prevent
On Fri, 2021-12-03 at 17:03 +0300, Andrei Zubkov wrote:
> I've added the following fields to the pg_stat_statements view:
>
> min_plan_time_local float8,
> max_plan_time_local float8,
> min_exec_time_local float8,
> max_exec_time_local float8
>
> and a function that is able to res
On Fri, Dec 3, 2021 at 3:15 AM Dinesh Chemuduru
wrote:
> Hi Michael,
>
> Attaching the latest patch here(It's the recent patch), and looking for
> more suggestions/inputs from the team.
>
> On Fri, 3 Dec 2021 at 13:09, Michael Paquier wrote:
>
>> On Wed, Nov 10, 2021 at 01:58:58PM +0530, Dinesh
On 02.12.21 23:16, Andres Freund wrote:
I think we should at least include pg_upgrade in this as well, it's pretty
closely tied to at least pg_dump.
right
* pg_dump and psql will maintain compatibility with servers at least
ten major releases back.
Personally I think that's too long... I
> On Fri, Dec 03, 2021 at 09:51:21AM +0100, Daniel Gustafsson wrote:
> I've now closed the 2021-11 commitfest, ~36% of the patches were closed in
> some
> way (committed, returned with feedback, withdrawn or rejected) with 184
> patches
> moved to the next CF.
Impressive numbers, thank you!
On 02.12.21 18:30, Tom Lane wrote:
This assumes a yearly major release cadence.
If the point is to not have to count dates carefully, why does the cadence
matter?
If we were to change the release cadence, then it would be appropriate
to review this policy.
I can get behind something rough
On 02.12.21 19:22, Tom Lane wrote:
That's surely no problem in HEAD, but as you say, it is an issue for
the older branches. How difficult would it be to teach configure to
try both ways, or adapt based on its python version check?
I think it wouldn't be unreasonable to do that. I'll look into
Peter Eisentraut writes:
> pg_regress.c sets bytea_output to hex already.
Ah, right. Nevermind that then.
regards, tom lane
On 02.12.21 19:30, Tom Lane wrote:
Generally +1, but I see you removed some instances of
--- ensure consistent test output regardless of the default bytea format
-SET bytea_output TO escape;
I think that the principle still applies that this should work regardless
of the installation's default
If my patch to unite vacuum verbose and the autovacuum logging gets in,
then this issue also goes away.
Peter Geoghegan
(Sent from my phone)
Daniel Gustafsson writes:
> I've now closed the 2021-11 commitfest, ~36% of the patches were closed in
> some
> way (committed, returned with feedback, withdrawn or rejected) with 184
> patches
> moved to the next CF.
Thanks for all your hard work on managing the CF!
(And particularly, thanks
On 2021/11/08 22:40, kuroda.hay...@fujitsu.com wrote:
Attached patches are the latest version.
Thanks for updating the patch!
+ buf = makeStringInfo();
This is necessary only when application_name is set. So it's better to avoid
this if appname is not set.
Currently StringI
On Fri, Dec 3, 2021 at 7:38 PM Ashutosh Sharma wrote:
>
> I see that this patch is reducing the database creation time by almost 3-4
> times provided that the template database has some user data in it. However,
> there are couple of points to be noted:
Thanks a lot for looking into the patches
On Wed, Dec 1, 2021 at 12:31 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> I recently did a small experiment to see how one can create extensions
> properly in HA(primary-standby) setup.
>
> Here are my findings:
> 1) ALTER SYSTEM SET or GUC(configuration parameters) settings are not
> replicated to sta
On Fri, Dec 3, 2021 at 6:33 AM Michael Paquier wrote:
>
> On Fri, Dec 03, 2021 at 12:45:56AM +, Bossart, Nathan wrote:
> > I think the problems you noted upthread are shared for all GUCs with
> > type GUC_LIST_QUOTE (e.g., search_path, temp_tablespaces). Perhaps
> > the documentation for each
On Wed, Dec 1, 2021 at 9:50 PM Alvaro Herrera wrote:
>
> On 2021-Dec-01, Bharath Rupireddy wrote:
>
> > The active_pid of ReplicationSlot structure, which tells whether a
> > replication slot is active or inactive, isn't persisted to the disk
> > i.e has no entry in ReplicationSlotPersistentData s
I see that this patch is reducing the database creation time by almost 3-4
times provided that the template database has some user data in it.
However, there are couple of points to be noted:
1) It makes the crash recovery a bit slower than before if the crash has
occurred after the execution of a
On Fri, Dec 3, 2021 at 2:26 PM Fujii Masao wrote:
> > For a cancel request maybe we can just say without te errcontext:
> > ereport(WARNING,
> > (errmsg("could not get result of cancel
> > request due to timeout")));
> >
> > See the below existing
Hi, Anton!
Thank you for your review!
On Mon, 2021-10-18 at 22:11 +0300, Anton A. Melnikov wrote:
> So i suppose that additional vars loc_min and loc_max is a right way
> to do it.
I've added the following fields to the pg_stat_statements view:
min_plan_time_local float8,
max_plan_time_
On Fri, Dec 3, 2021 at 3:01 AM Bossart, Nathan wrote:
>
> On 12/1/21, 6:48 PM, "Bharath Rupireddy"
> wrote:
> > +1 for the overall idea of making the checkpoint faster. In fact, we
> > here at our team have been thinking about this problem for a while. If
> > there are a lot of files that checkp
Hi,
Few comments for v7 patch, note that I haven't been through the
previous discussion, if any of the review comments that has been
already discussed & overridden, then please ignore here too:
partbounds.c: In function ‘get_qual_for_list.isra.18’:
partbounds.c:4284:29: warning: ‘boundinfo’ may
> On 2 Dec 2021, at 16:04, Peter Eisentraut
> wrote:
> This change looks correct to me.
Thanks for review, I've pushed this backpatched (in part) down to 10.
--
Daniel Gustafsson https://vmware.com/
On Fri, Dec 3, 2021 at 21:34 Amit Langote wrote:
> On Fri, Dec 3, 2021 at 12:37 PM Amit Kapila
> wrote:
> > On Thu, Dec 2, 2021 at 7:18 PM Amit Langote
> wrote:
> > > On Thu, Dec 2, 2021 at 2:27 PM Amit Kapila
> wrote:
> > > > On Thu, Dec 2, 2021 at 8:42 AM Amit Langote
> wrote:
> > > > > Rea
Thursday, December 2, 2021 4:41 PM I wrote:
> On Thursday, December 2, 2021 1:49 PM Amit Kapila
> wrote:
> > On Thu, Dec 2, 2021 at 6:35 AM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > On Wednesday, December 1, 2021 10:16 PM Amit Kapila
> > wrote:
> > > Updated the patch to include the not
On 23.11.21 16:09, Alvaro Herrera wrote:
In init_fork(), there's a typo:
+* For tables, the AM callback creates both the main and the init fork.
should read:
+* For tables, the AM callback creates both the main and the init forks.
I believe the original wording is correct.
Ov
On Fri, Dec 3, 2021 at 6:03 PM Amit Kapila wrote:
>
> On Thu, Dec 2, 2021 at 6:01 PM Masahiko Sawada wrote:
> >
> > I've attached updated patches.
> >
>
> I have a few comments on v4-0001.
Thank you for the comments!
> 1.
> In parallel_vacuum_process_all_indexes(), we can combine the two
> chec
On Fri, Dec 3, 2021 at 12:37 PM Amit Kapila wrote:
> On Thu, Dec 2, 2021 at 7:18 PM Amit Langote wrote:
> > On Thu, Dec 2, 2021 at 2:27 PM Amit Kapila wrote:
> > > On Thu, Dec 2, 2021 at 8:42 AM Amit Langote
> > > wrote:
> > > > Reading Alvaro's email at the top again gave me a pause to recons
and
On Fri, Dec 3, 2021 at 6:56 PM Amit Kapila wrote:
>
> On Fri, Dec 3, 2021 at 2:33 PM Amit Kapila wrote:
> >
> > On Thu, Dec 2, 2021 at 6:01 PM Masahiko Sawada
> > wrote:
> > >
> > > I've attached updated patches.
> > >
> >
> > I have a few comments on v4-0001.
> >
>
> The new test propose
On Fri, Dec 3, 2021 at 5:00 PM Simon Riggs wrote:
>
> On Fri, 3 Dec 2021 at 01:27, Dilip Kumar wrote:
>
> > > On review, I think it is also possible that we update subtrans ONLY if
> > > someone uses >PGPROC_MAX_CACHED_SUBXIDS.
> > > This would make subtrans much smaller and avoid one-entry-per-p
On Fri, 3 Dec 2021 at 01:27, Dilip Kumar wrote:
> > On review, I think it is also possible that we update subtrans ONLY if
> > someone uses >PGPROC_MAX_CACHED_SUBXIDS.
> > This would make subtrans much smaller and avoid one-entry-per-page
> > which is a major source of cacheing.
> > This would me
Hi Michael,
Attaching the latest patch here(It's the recent patch), and looking for
more suggestions/inputs from the team.
On Fri, 3 Dec 2021 at 13:09, Michael Paquier wrote:
> On Wed, Nov 10, 2021 at 01:58:58PM +0530, Dinesh Chemuduru wrote:
> > The proposed statements are much clear, but will
On Fri, Dec 3, 2021 at 2:33 PM Amit Kapila wrote:
>
> On Thu, Dec 2, 2021 at 6:01 PM Masahiko Sawada wrote:
> >
> > I've attached updated patches.
> >
>
> I have a few comments on v4-0001.
>
The new test proposed by v4-0003 is increasing the vacuum_parallel.sql
timing by more than 10 times. It a
On Fri, Dec 3, 2021 at 1:13 PM Michael Paquier wrote:
>
> On Thu, Aug 26, 2021 at 09:00:39PM +0530, vignesh C wrote:
> > The previous patch was failing because of the recent test changes made
> > by commit 201a76183e2 which unified new and get_new_node, attached
> > patch has the changes to handle
On Fri, Dec 3, 2021 at 3:01 PM houzj.f...@fujitsu.com
wrote:
>
> On Thur, Dec 2, 2021 8:31 PM Masahiko Sawada wrote:
> > I've attached updated patches.
> >
> > The first patch is the main patch for refactoring parallel vacuum code;
> > removes
> > bitmap-related code and renames function names f
On Thur, Dec 2, 2021 8:31 PM Masahiko Sawada wrote:
> I've attached updated patches.
>
> The first patch is the main patch for refactoring parallel vacuum code;
> removes
> bitmap-related code and renames function names for consistency. The second
> patch moves these parallel-related codes to va
On Fri, Dec 3, 2021 at 12:45 AM Alvaro Herrera wrote:
>
> On 2021-Sep-16, Peter Smith wrote:
>
> > I noticed that the latest v5 no longer includes the TAP test which was
> > in the v4 patch.
> >
> > (src/test/subscription/t/021_column_filter.pl)
> >
> > Was that omission deliberate?
>
> Somehow I
On 2021/11/16 18:55, Etsuro Fujita wrote:
I changed my mind; I’ll update the patch to ignore the error as
before, because 1) as far as I know, there are no reports from the
field concerning that we ignore all kinds of errors in cleaning up the
prepared statements, so maybe we don’t need to cha
On Thu, Dec 2, 2021 at 6:01 PM Masahiko Sawada wrote:
>
> I've attached updated patches.
>
I have a few comments on v4-0001.
1.
In parallel_vacuum_process_all_indexes(), we can combine the two
checks for vacuum/cleanup at the beginning of the function and I think
it is better to keep the variable
On 2021/11/22 14:16, Bharath Rupireddy wrote:
BTW, we can hide the message "remote SQL command: .." in cancel request case,
but which would make the debug and troubleshooting harder.
Yeah, let's not hide the message.
Yes!
For a cancel request maybe we can just say without te errcontext:
I've now closed the 2021-11 commitfest, ~36% of the patches were closed in some
way (committed, returned with feedback, withdrawn or rejected) with 184 patches
moved to the next CF.
--
Daniel Gustafsson https://vmware.com/
This review has gone unanswered for two months, so I'm marking this patch
Returned with Feedback. Please feel free to resubmit when a new version of the
patch is available.
--
Daniel Gustafsson https://vmware.com/
On 2021/11/22 13:59, Bharath Rupireddy wrote:
On Mon, Nov 22, 2021 at 8:17 AM Fujii Masao wrote:
Well, in that case, why can't we get rid of "(message_primary != NULL"
and just have "message_primary[0] != '\0' ? errmsg_internal("%s",
message_primary) : errmsg("could not obtain message string
On Fri, Dec 3, 2021 at 1:43 PM Daniel Gustafsson wrote:
>
> > On 3 Dec 2021, at 08:58, Bharath Rupireddy
> > wrote:
>
> > It seems like there's an extra Logging_collector check before calling
> > SysLogger_Start(). Note that the SysLogger_Start() has a check to
> > return 0 if Logging_collector
> On 3 Dec 2021, at 08:58, Bharath Rupireddy
> wrote:
> It seems like there's an extra Logging_collector check before calling
> SysLogger_Start(). Note that the SysLogger_Start() has a check to
> return 0 if Logging_collector is off. This change is consistent with
> the other usage of SysLogger_
74 matches
Mail list logo
