On 11/23/20 7:49 AM, tsunakawa.ta...@fujitsu.com wrote:
Hi Andrey-san,
From: Tomas Vondra
I needed to look at this patch while working on something related, and I found
it
got broken by 6973533650c a couple days ago. So here's a fixed version, to keep
cfbot happy. I haven't done any seriou
>
> >> undocumented. Maybe instead of removing, change the text to be
> >> "Deprecated, use the equivalent XXX operator instead." Or we could
> >> add a footnote similar to what was there for a previous renaming:
>
> > The problem that this new <<| is equivalent to <^ only for points (To
> > reca
Attaching v2 patch, rebased on the latest master 17958972.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
v2-0001-Multi-Inserts-in-Create-Table-As.patch
Description: Binary data
On 18/11/2020 08:21, Soumyadeep Chakraborty wrote:
On Tue, Nov 17, 2020 at 2:38 AM Heikki Linnakangas wrote:
Fixed all the other things you listed, fixed a bug in setting
'file_encoding', and trimmed down the #includes.
Thanks! LGTM! Marking as Ready for Committer.
Pushed, thanks for the re
>
> The wording seems no problem to me. I looked into a patch and changes
>> also seem sensible but I can not apply this patch because of really many
>> rejects. Which commit should I use to apply it onto?
>
> Sorry, the rejects were due to my git configuration. I will apply and make
the final che
On 23/11/2020 11:15, Bharath Rupireddy wrote:
Attaching v2 patch, rebased on the latest master 17958972.
I just broke this again with commit c532d15ddd to split up copy.c.
Here's another rebased version.
- Heikki
>From dca55175c590914f6a802ec3d36e20db55a3e3c7 Mon Sep 17 00:00:00 2001
From: B
Hi,
After my commit c532d15ddd to split up copy.c, buildfarm animal "prion"
failed in pg_upgrade
(https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2020-11-23%2009%3A23%3A16):
Upgrade Complete
Optimizer statistics are not transferred by pg_upgrade so,
once you
On Sun, Nov 22, 2020 at 12:31 AM Amit Kapila wrote:
> I am planning to continue review of these patches but I thought it is
> better to check about the above changes before proceeding further. Let
> me know what you think?
>
I've had a look at the changes and done a few tests, and have no
commen
On Mon, Nov 23, 2020 at 3:26 PM Heikki Linnakangas wrote:
>
> On 23/11/2020 11:15, Bharath Rupireddy wrote:
> > Attaching v2 patch, rebased on the latest master 17958972.
>
> I just broke this again with commit c532d15ddd to split up copy.c.
> Here's another rebased version.
>
Thanks! I noticed t
On 05.11.2020 02:53, James Coleman wrote:
On Tue, Nov 3, 2020 at 4:42 PM Tomas Vondra
wrote:
On Tue, Nov 03, 2020 at 03:53:53AM +0100, Tomas Vondra wrote:
Hi,
I took another look at this, and 99% of the patch (the fixes to sort
debug messages) seems fine to me. Attached is the part I plan to
On Mon, Oct 19, 2020 at 10:47 PM Bharath Rupireddy
wrote:
>
> Attaching v3 patch herewith.
>
> I'm done with all the open points in my list. Please review the v3 patch and
> provide comments.
>
Attaching v4 patch, rebased on the latest master 68b1a4877e. Also,
added this feature to commitfest -
On Mon, Nov 23, 2020 at 3:41 PM Ajin Cherian wrote:
>
> On Sun, Nov 22, 2020 at 12:31 AM Amit Kapila wrote:
>
> > I am planning to continue review of these patches but I thought it is
> > better to check about the above changes before proceeding further. Let
> > me know what you think?
> >
>
> I'
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
I've made another check of the final state and suppose it is read
On Sat, Nov 21, 2020 at 3:50 AM Robert Haas wrote:
>
> On Wed, Nov 11, 2020 at 9:39 AM Dilip Kumar wrote:
> > There were a few problems in this rebased version, basically, the
> > compression options were not passed while compressing values from the
> > brin_form_tuple, so I have fixed this.
>
>
Hi Greg,
The implicit conversion was the cause of the non parallel plan, thanks for the
explanation and the workarounds. It can cause a huge difference in terms of
performance, I will give the information to our developers.
Regards,
Phil
De : Greg Nancarrow
On 21.11.2020 04:30, Michael Paquier wrote:
The only method I can think as being really
reliable is based on two facts:
- Do a check only on pd_checksums, as that validates the full contents
of the page.
- When doing a retry, make sure that there is no concurrent I/O
activity in the shared buffer
On Sun, Nov 22, 2020 at 5:07 PM Tomas Vondra
wrote:
>
> On 11/22/20 10:31 PM, Tom Lane wrote:
> > Tomas Vondra writes:
> >> On 11/20/20 11:24 PM, James Coleman wrote:
> >>> While looking at another issue I noticed that create_gather_merge_plan
> >>> calls make_sort if the subplan isn't sufficient
On Sun, Nov 22, 2020 at 4:59 PM Tomas Vondra
wrote:
>
> On 11/21/20 2:55 AM, James Coleman wrote:
> > Over on the -bugs list we had a report [1] of a seg fault with
> > incremental sort. The short of the investigation there was that a
> > subplan wasn't being serialized since it wasn't parallel sa
** this is a plaintext version of the previous HTML-formatted message **
Hi,
I’ve run a couple of pgbenchmarks using this patch with odyssey connection
pooler, with client-to-pooler ZSTD compression turned on.
pgbench --builtin tpcb-like -t 75 --jobs=32 --client=1000
CPU utilization chart of t
On 2020-11-20 18:23, David G. Johnston wrote:
If there is dead code there is an underlying problem to
address/discover, not just removing the dead code. In this case are we
saying that a new server won’t ever fail to start because the socket
file exists but instead will just clobber the file w
Hi,
On 11/23/20 3:01 AM, Tomas Vondra wrote:
> Hi,
>
> On 10/30/20 6:57 AM, Takashi Menjo wrote:
>> Hi Heikki,
>>
>>> I had a new look at this thread today, trying to figure out where
>>> we are.
>>
>> I'm a bit confused.
>>>
>>> One thing we have established: mmap()ing WAL files performs worse
With the exception of "Fix /contrib/btree_gist's implementation of inet
indexing", all items above have been either moved over, or removed if they
were done already by PG13.
--
John Naylor
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sun, 22 Nov 2020 at 20:58, Tom Lane wrote:
>
> I found only one nitpicky bug: in
> findDefaultOnlyColumns, the test must be bms_is_empty(default_only_cols)
> not just default_only_cols == NULL, or it will fail to fall out early
> as intended when the first row contains some DEFAULTs but later r
On 2020-Nov-17, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Nov 17, 2020 at 10:32 AM Tom Lane wrote:
> >> Adding the expected length to the error message might be OK though.
>
> > Certainly seems like we should do at least that much. The current
> > message is just wrong, right?
>
> It's
Alvaro Herrera writes:
> So let's go with this one.
WFM.
regards, tom lane
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Nov 20, 2020 at 11:08:27AM -0500, Stephen Frost wrote:
> > David Steele (da...@pgmasters.net) wrote:
> >> Our current plan for pgBackRest:
> >>
> >> 1) Remove the LSN check as you have done in your patch and when rechecking
> >>
On 2020-Nov-18, Andres Freund wrote:
> In 13 this is:
> LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
> MyPgXact->vacuumFlags |= PROC_IN_VACUUM;
> if (params->is_wraparound)
> MyPgXact->vacuumFlags |= PROC_VACUUM_FOR_WRAPAROUND;
>
On 23-11-2020 13:17, Phil Florent wrote:
Hi Greg,
The implicit conversion was the cause of the non parallel plan, thanks
for the explanation and the workarounds. It can cause a huge difference
in terms of performance, I will give the information to our developers.
Regards,
Phil
-
Greetings,
* Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
> On 21.11.2020 04:30, Michael Paquier wrote:
> >The only method I can think as being really
> >reliable is based on two facts:
> >- Do a check only on pd_checksums, as that validates the full contents
> >of the page.
> >- Wh
On Mon, Nov 23, 2020 at 10:41:25AM -0400, John Naylor wrote:
> With the exception of "Fix /contrib/btree_gist's implementation of inet
> indexing", all items above have been either moved over, or removed if they
> were
> done already by PG13.
Thanks.
--
Bruce Momjian https://momjian.
Alvaro Herrera writes:
> PROC_IN_LOGICAL_DECODING:
> Oddly enough, I think the reset of PROC_IN_LOGICAL_DECODING in
> ReplicationSlotRelease might be the most problematic one of the lot.
> That's because a proc's xmin that had been ignored all along by
> ComputeXidHorizons, will now be included in
On Mon, Nov 23, 2020 at 6:50 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-11-20 18:23, David G. Johnston wrote:
> > If there is dead code there is an underlying problem to
> > address/discover, not just removing the dead code. In this case are we
> > saying that a new
Dean Rasheed writes:
> On Sun, 22 Nov 2020 at 20:58, Tom Lane wrote:
>> However, I think that just adjusting the error string would be
>> helpful, as attached.
> +1
>> (I'm also wondering why the second case is generic ERRCODE_SYNTAX_ERROR
>> and not ERRCODE_GENERATED_ALWAYS. Didn't change it
On 2020-Nov-23, Tom Lane wrote:
> Alvaro Herrera writes:
> > So let's go with this one.
>
> WFM.
Thanks, pushed.
Hi,
On 2020-11-23 09:48, Bharath Rupireddy wrote:
Here is how I'm making 4 separate patches:
1. new function and it's documentation.
2. GUC and it's documentation.
3. server level option and it's documentation.
4. test cases for all of the above patches.
Hi, I'm attaching the patches here.
Tested this patch by running several upgrades from different major
versions and different setups.
ACL, that are impossible to apply, are detected and reported, so it
looks good for me.
Pavel Borisov writes:
> I've made another check of the final state and suppose it is ready to be
> pushed.
Sounds good, pushed.
regards, tom lane
On 17/11/2020 10:56, Daniel Gustafsson wrote:
On 5 Oct 2020, at 13:36, Heikki Linnakangas wrote:
2. The signaling between enable_data_checksums() and the launcher process looks
funny to me. The general idea seems to be that enable_data_checksums() just
starts the launcher process, and the laun
On Thu, Nov 12, 2020 at 9:56 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> On 2020-06-30 06:34, John Naylor wrote:
> > In v9, I've simplified the patch somewhat to make it easier for future
> > work to build on.
> >
> > - When truncating on month-or-greater intervals, require
Thank you for the assistance.
From: Andrew Dunstan
Sent: Saturday, November 21, 2020 11:14
To: Corbit, Dann ; PostgreSQL Developers
Cc: Luton, Bill ; Fifer, Brian
; Lao, Alexander
Subject: Re: Connection using ODBC and SSL
On 11/20/20 4:54 PM, Corbit, Dann w
James Coleman writes:
> But I think that still leaves something missing: after all,
> prepare_sort_from_pathkeys does know how to insert new target list
> entries, so something either there (or in the caller/how its called)
> has to be enforcing an apparently implicit rule about what point in
> th
I think this formulation (attached v3) has fewer moving parts.
However, now that I did that, I wonder if this is really the best
approach to solve this problem. Maybe instead of doing this at the BRIN
level, it should be handled at the autovac level, by having the worker
copy the work-item to loc
>From a report by user "kes" on irc, I constructed this test case:
create table marktst (id integer, val numrange, exclude using gist (val with
&&));
insert into marktst select i, numrange(i, i+1, '[)') from
generate_series(1,1000) i;
vacuum marktst;
analyze marktst;
select * from (select val f
Andrew Gierth writes:
> The problem is that the planner calls ExecSupportsMarkRestore to find
> out whether a Materialize node is needed, and that function looks no
> further than the Path type of T_Index[Only]Path in order to return true,
> even though in this case it's a GiST index which does no
On 30.09.2020 05:00, David G. Johnston wrote:
On Tue, Sep 15, 2020 at 3:48 PM Alexander Korotkov
mailto:aekorot...@gmail.com>> wrote:
Hi!
I've skimmed through the thread and checked the patchset. Everything
looks good, except one paragraph, which doesn't look completely clear.
On 2020-Nov-19, Michael Paquier wrote:
> On Thu, Nov 19, 2020 at 12:13:44PM +0900, Michael Paquier wrote:
> > That still looks useful for debugging, so DEBUG1 sounds fine to me.
>
> By the way, it strikes me that you could just do nothing as long as
> (log_min_messages > DEBUG1), so you could enc
On Sat, 21 Nov 2020 at 03:26, Peter Eisentraut
wrote:
>
> I did tests of elog_ereport_attribute_cold_v4.patch on an oldish Mac
> Intel laptop with pgbench scale 1 (default), and then:
>
> pgbench -S -T 60
>
> master: tps = 8251.883229 (excluding connections establishing)
> patched: tps = 9556.836
Hello
Chloe Dives reported that sometimes a walsender would become stuck
during shutdown and *not* shutdown, thus preventing postmaster from
completing the shutdown cycle. This has been observed to cause the
servers to remain in such state for several hours.
After a lengthy investigation and tha
It was only needed between these:
commit a8677e3ff6bb8ef78a9ba676faa647bba237b1c4
Author: Peter Eisentraut
Date: Fri Apr 13 17:06:28 2018 -0400
Support named and default arguments in CALL
commit f09346a9c6218dd239fdf3a79a729716c0d305bd
Author: Tom Lane
Date: Tue Jan 29 15:48:51 2019 -0
Justin Pryzby writes:
>> This patch has been waiting for input from a committer on the approach I've
>> taken with the patches since March 10, so I'm planning to set to "Ready" - at
>> least ready for senior review.
I took a quick look through this. This is just MHO, of course:
* I don't think
On 23.11.2020 18:35, Stephen Frost wrote:
Greetings,
* Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
On 21.11.2020 04:30, Michael Paquier wrote:
The only method I can think as being really
reliable is based on two facts:
- Do a check only on pd_checksums, as that validates the fu
Alvaro Herrera writes:
> On 2020-Nov-19, Michael Paquier wrote:
>> By the way, it strikes me that you could just do nothing as long as
>> (log_min_messages > DEBUG1), so you could encapsulate most of the
>> logic that plays with the lock tag using that.
> Good idea, done.
I'm less sure that that
On 2020-Nov-23, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Nov-19, Michael Paquier wrote:
> >> By the way, it strikes me that you could just do nothing as long as
> >> (log_min_messages > DEBUG1), so you could encapsulate most of the
> >> logic that plays with the lock tag using that.
>
On 27.10.2020 13:46, Amit Kapila wrote:
On Sun, Oct 25, 2020 at 9:39 PM Euler Taveira
wrote:
On Mon, 5 Oct 2020 at 08:34, Amit Kapila wrote:
On Mon, May 11, 2020 at 2:41 AM Euler Taveira
wrote:
Hi,
While looking at an old wal2json issue, I stumbled on a scenario that a table
with a deferre
Hi,
Here's a new version with the pgbench support included.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: https://www.manitou-mail.org
Twitter: @DanielVerite
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 9ce32fb39b..2a94f8f6b9 100644
--- a/doc/src/sgml/libpq.s
Justin Pryzby writes:
> It was only needed between these:
> commit a8677e3ff6bb8ef78a9ba676faa647bba237b1c4
> commit f09346a9c6218dd239fdf3a79a729716c0d305bd
Hm, you're right. Removed.
> I noticed while looking at "what includes what" and wondered if some of these
> are kind of "modularity viol
Alvaro Herrera writes:
> Well, we already do this in a number of places. But I can get behind
> this:
>> Maybe it'd be a good idea to have elog.c expose a new function
>> along the lines of "bool message_level_is_interesting(int elevel)"
>> to support this and similar future optimizations in a l
On 29.10.2020 17:19, Stephen Frost wrote:
Greetings,
* Georgios Kokolatos (gkokola...@protonmail.com) wrote:
this patch is in "Ready for committer" state and the Cfbot is happy.
Glad that's still the case. :)
Is there any committer that is available for taking a look at it?
If there aren't
On 2020-Nov-23, Tom Lane wrote:
> Alvaro Herrera writes:
> > Well, we already do this in a number of places. But I can get behind
> > this:
>
> >> Maybe it'd be a good idea to have elog.c expose a new function
> >> along the lines of "bool message_level_is_interesting(int elevel)"
> >> to suppo
On 2020-Nov-23, Daniel Verite wrote:
> Hi,
>
> Here's a new version with the pgbench support included.
Thanks, incorporated into my local copy.
Greetings,
* Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
> On 23.11.2020 18:35, Stephen Frost wrote:
> >* Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
> >>On 21.11.2020 04:30, Michael Paquier wrote:
> >>>The only method I can think as being really
> >>>reliable is ba
Greetings,
* Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
> On 29.10.2020 17:19, Stephen Frost wrote:
> >* Georgios Kokolatos (gkokola...@protonmail.com) wrote:
> >>this patch is in "Ready for committer" state and the Cfbot is happy.
> >Glad that's still the case. :)
> >
> >>Is ther
Here's a draft patch.
regards, tom lane
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index 03c553e7ea..9cd0b7c11b 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -5344,7 +5344,7 @@ static void
On 2020-Nov-23, Tom Lane wrote:
> Here's a draft patch.
Here's another of my own. Outside of elog.c it seems identical.
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index 03c553e7ea..a4ab9090f9 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backen
On 2020-Nov-23, Alvaro Herrera wrote:
> On 2020-Nov-23, Tom Lane wrote:
>
> > Here's a draft patch.
>
> Here's another of my own. Outside of elog.c it seems identical.
Your version has the advantage that errstart() doesn't get a new
function call. I'm +1 for going with that ... we could avoid
On 2020-Nov-23, Tom Lane wrote:
> Anyway, if you're feeling motivated to explore a more wide-ranging
> refactoring, by all means have a go at it.
I was contemplating commands/trigger.c this morning (after Heikki split
copy.c) thinking about the three pieces embedded in there -- one
catalog/pg_tri
Alvaro Herrera writes:
> On 2020-Nov-23, Tom Lane wrote:
>> Here's a draft patch.
> Here's another of my own. Outside of elog.c it seems identical.
Ah, I see I didn't cover the case in ProcSleep that you were originally on
about ... I'd just looked for existing references to log_min_messages
an
Alvaro Herrera writes:
> Your version has the advantage that errstart() doesn't get a new
> function call. I'm +1 for going with that ... we could avoid the
> duplicate code with some additional contortions but this changes so
> rarely that it's probably not worth the trouble.
I was considering
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Justin Pryzby writes:
> >> This patch has been waiting for input from a committer on the approach I've
> >> taken with the patches since March 10, so I'm planning to set to "Ready" -
> >> at
> >> least ready for senior review.
>
> I took a qui
On 2020-Nov-23, Tom Lane wrote:
> Ah, I see I didn't cover the case in ProcSleep that you were originally on
> about ... I'd just looked for existing references to log_min_messages
> and client_min_messages.
Yeah, it seemed bad form to add that when you had just argued against it
:-)
> I think i
On Tue, 24 Nov 2020 at 09:36, David Rowley wrote:
> Well, that makes it look pretty good. If we can get 10-15% on some
> machines without making things slower on any other machines, then that
> seems like a good win to me.
Pushed.
Thank you both for reviewing this.
David
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I took a quick look through this. This is just MHO, of course:
>>
>> * I don't think it's okay to change the existing signatures of
>> pg_ls_logdir() et al.
> I disagree that we need to stress over this- we pretty routinely chang
Alvaro Herrera writes:
> On 2020-Nov-23, Tom Lane wrote:
>> I'm not too fussed about whether we invent is_log_level_output_client,
>> although that name doesn't seem well-chosen compared to
>> is_log_level_output.
> Just replacing "log" for "client" in that seemed strictly worse, and I
> didn't (
On Tue, Nov 24, 2020 at 10:06 AM David Rowley wrote:
>
> On Tue, 24 Nov 2020 at 09:36, David Rowley wrote:
> > Well, that makes it look pretty good. If we can get 10-15% on some
> > machines without making things slower on any other machines, then that
> > seems like a good win to me.
>
> Pushed
No one have any comments, patch tester says OK, and I think this works well.
I changed status to "Ready for Committer."
Hayato Kuroda
FUJITSU LIMITED
-Original Message-
From: kuroda.hay...@fujitsu.com
Sent: Friday, November 20, 2020 11:05 AM
To: 'japin'
Cc: David G. Johnston ; Kyotaro
On Tue, 24 Nov 2020 at 12:50, Greg Nancarrow wrote:
> Hmmm, unfortunately this seems to break my build ...
> I think your commit needs to be fixed based on the following documentation:
>
> https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005fattribute.html#g_t_005f_005fhas_005fattribute
Agreed.
Hi,
On 2020-11-23 12:30:05 -0300, Alvaro Herrera wrote:
> ProcSleep: no bug here.
> The flags are checked to see if we should kill() the process (used when
> autovac blocks some other process). The lock here appears to be
> inconsequential, since we release it before we do kill(); so strictly
>
On Tue, Nov 24, 2020 at 2:34 AM Luc Vlaming wrote:
>
> Hi,
>
> For this problem there is a patch I created, which is registered under
> https://commitfest.postgresql.org/30/2787/ that should fix this without
> any workarounds. Maybe someone can take a look at it?
>
I tried your patch with the lat
David Rowley writes:
> On Tue, 24 Nov 2020 at 12:50, Greg Nancarrow wrote:
>> Hmmm, unfortunately this seems to break my build ...
>
>> I think your commit needs to be fixed based on the following documentation:
>>
>> https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005fattribute.html#g_t_005f_0
On Mon, Nov 23, 2020 at 10:35:54AM -0500, Stephen Frost wrote:
> * Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
>> It seems reasonable to me to rely on checksums only.
>>
>> As for retry, I think that API for concurrent I/O will be complicated.
>> Instead, we can introduce a functio
On Mon, Nov 23, 2020 at 05:28:52PM -0500, Stephen Frost wrote:
> * Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
>> Yes and this is a tricky part. Until you have explained it in your latest
>> message, I wasn't sure how we can distinct concurrent update from a page
>> header corruptio
On Mon, Nov 23, 2020 at 2:24 PM Tom Lane wrote:
>
> James Coleman writes:
> > But I think that still leaves something missing: after all,
> > prepare_sort_from_pathkeys does know how to insert new target list
> > entries, so something either there (or in the caller/how its called)
> > has to be e
On Tue, Nov 24, 2020 at 3:04 AM Anastasia Lubennikova
wrote:
>
> On 27.10.2020 13:46, Amit Kapila wrote:
> > On Sun, Oct 25, 2020 at 9:39 PM Euler Taveira
> > wrote:
> >> On Mon, 5 Oct 2020 at 08:34, Amit Kapila wrote:
> >>> On Mon, May 11, 2020 at 2:41 AM Euler Taveira
> >>> wrote:
> Hi,
On 11/23/20 3:17 AM, tsunakawa.ta...@fujitsu.com wrote:
> From: Tomas Vondra
>> I don't think this is usable in practice, because a single session
>> may be using multiple FDW servers, with different implementations,
>> latency to the data nodes, etc. It's unlikely a single GUC value
>> will be
Greetings,
On Mon, Nov 23, 2020 at 20:28 Michael Paquier wrote:
> On Mon, Nov 23, 2020 at 05:28:52PM -0500, Stephen Frost wrote:
> > * Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
> >> Yes and this is a tricky part. Until you have explained it in your
> latest
> >> message, I wasn
On Fri, Nov 20, 2020 at 04:06:43PM +0100, Peter Eisentraut wrote:
> I think we are getting a bit sidetracked here with the message wording. The
> reason I looked at this was that "remove socket file and retry" is never an
> appropriate action with abstract sockets. And on further analysis, it is
>
On Mon, Nov 02, 2020 at 12:45:51PM -0600, Justin Pryzby wrote:
> On Mon, Nov 02, 2020 at 07:53:45AM +0100, Luc Vlaming wrote:
> > On 30.10.20 05:51, Justin Pryzby wrote:
> > > On Thu, Oct 22, 2020 at 01:29:53PM +0100, Simon Riggs wrote:
> > > > On Fri, 16 Oct 2020 at 22:05, Justin Pryzby
> > > >
On 2020-Nov-23, Tom Lane wrote:
> I never cared that much for "is_log_level_output" either. Thinking
> about renaming it to "should_output_to_log()", and then the new function
> would be "should_output_to_client()".
Ah, that sounds nicely symmetric and grammatical.
Thanks!
On Mon, Nov 23, 2020 at 06:13:17PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
>> Please feel free to go ahead, including the change to ProcSleep.
>
> Will do.
Thank you both for 450c823 and 789b938.
--
Michael
signature.asc
Description: PGP signature
Hi
On Monday, Nov 23, 2020 12:17 PM Tsunakawa, Takayuki
wrote:
> PREPARE TRANSACTION is the same as COMMIT in that it persists
> transaction updates. A crash during wal_level = none loses both of them.
> So, I don't think PREPARE TRANSACTION needs special treatment.
Yeah, I got it. That makes s
At Sat, 21 Nov 2020 17:33:53 -0500, Tom Lane wrote in
> I went ahead and pushed 0001 and 0003 (the latter in two parts), since
> they didn't seem particularly controversial to me. Just to keep the
> cfbot from whining, here's a rebased version of 0002.
I didn't noticed that inf == inf sould be
On Mon, Nov 23, 2020 at 5:39 PM Andrey Lepikhov
wrote:
> On 11/23/20 7:49 AM, tsunakawa.ta...@fujitsu.com wrote:
> > Could I or my colleague continue this patch in a few days? It looks it's
> > stalled over one month.
>
> I don't found any problems with this patch that needed to be corrected.
>
On Mon, Nov 23, 2020 at 5:02 PM kuroda.hay...@fujitsu.com <
kuroda.hay...@fujitsu.com> wrote:
> No one have any comments, patch tester says OK, and I think this works
> well.
> I changed status to "Ready for Committer."
>
Some proof-reading:
v8-0001
Documentation:
My suggestion wasn't taken for
On Fri, Nov 20, 2020 at 03:25:50PM +0900, Michael Paquier wrote:
> I agree that this makes this code a bit cleaner, so let's use those
> macros. Others may have some comments here, so let's wait a bit
> first.
Got this one committed as of d03d754.
--
Michael
signature.asc
Description: PGP signa
Thanks for the review comments.
On Mon, Nov 23, 2020 at 9:57 PM Alexey Kondratov
wrote:
>
> > v1-0001-postgres_fdw-function-to-discard-cached-connections.patch
>
> This patch looks pretty straightforward for me, but there are some
> things to be addressed IMO:
>
> + server = GetFore
On Mon, Nov 23, 2020 at 09:11:26AM +0200, Heikki Linnakangas wrote:
> On 21/11/2020 21:32, Alvaro Herrera wrote:
>> This is pretty unhelpful; it would be better not to try to print the
>> data instead of dying. With that, at least you can know where the
>> problem is.
>>
>> This was introduced in
Andrey-san, Fujita-san,
From: Etsuro Fujita
> On Mon, Nov 23, 2020 at 5:39 PM Andrey Lepikhov
> wrote:
> > On 11/23/20 7:49 AM, tsunakawa.ta...@fujitsu.com wrote:
> > > Could I or my colleague continue this patch in a few days? It looks it's
> stalled over one month.
> >
> > I don't found any p
At Fri, 20 Nov 2020 15:57:46 -0500, Tom Lane wrote in
> I spent some more time looking at this patch.
>
> Some experimentation shows that the changes around bounding box
> calculation (ie float8_min_nan() and its call sites) seem to be
> completely pointless: removing them doesn't change any of
On 11/24/20 9:27 AM, tsunakawa.ta...@fujitsu.com wrote:
Andrey-san, Fujita-san,
From: Etsuro Fujita
On Mon, Nov 23, 2020 at 5:39 PM Andrey Lepikhov
wrote:
On 11/23/20 7:49 AM, tsunakawa.ta...@fujitsu.com wrote:
Could I or my colleague continue this patch in a few days? It looks it's
st
Hi, Kuroda
Thank for your review.
> On Nov 24, 2020, at 8:01 AM, kuroda.hay...@fujitsu.com wrote:
>
> No one have any comments, patch tester says OK, and I think this works well.
> I changed status to "Ready for Committer."
>
> Hayato Kuroda
> FUJITSU LIMITED
>
> -Original Message-
> F
1 - 100 of 106 matches
Mail list logo
