On Wed, Nov 06, 2019 at 10:41:39AM +0100, Fabien COELHO wrote:
> Indeed, I put it on the wrong side of a "#ifndef WIN32".
>
> Basically it is a false constant under WIN32, which it seems does not have
> sigint handler, but the code checks whether the non existent handler is
> enabled anyway.
>
>
Hello:
> Have you considered *also* reporting this to Citus developers, because while
> the crash seems to have occurred in the core PostgreSQL code they may have a
> better chance reproducing this if at all.
I've sent this issue to the citus community, and then received the reply with
"Just a
čt 28. 11. 2019 v 4:48 odesílatel Pavel Stehule
napsal:
> Hi
>
> čt 28. 11. 2019 v 3:56 odesílatel David Fetter napsal:
>
>> On Wed, Nov 27, 2019 at 08:47:56AM +0100, Pavel Stehule wrote:
>> > Hi
>> >
>> > I have a report from my customer about migration his application from
>> > Oracle to Postg
Hi Fabien,
On Thu, Nov 28, 2019 at 4:35 PM Fabien COELHO wrote:
>
>
> Hello Amit,
>
> > I wonder why we don't use the same style for $subject as pg_basebackup
> > --progress, that is, use a carriage return instead of a newline after
> > each line reporting the number of tuples copied?
>
> Why not
Hi,
you mean if we don't add new compiler options the compiler will do the loop
unrolling using SIMD automatically?
Beside the function calls, cache miss etc, for VOPS I think the call stack
is squeezing too, but the JIT optimize still process rows one by one.
Konstantin Knizhnik 于2019年11月28日周四 下
Hello Amit,
I wonder why we don't use the same style for $subject as pg_basebackup
--progress, that is, use a carriage return instead of a newline after
each line reporting the number of tuples copied?
Why not.
Attached patch for that.
I'll look into it. Could you add it to the CF app?
On 27.11.2019 19:05, Tomas Vondra wrote:
On Wed, Nov 27, 2019 at 06:38:45PM +0300, Konstantin Knizhnik wrote:
On 25.11.2019 18:24, Merlin Moncure wrote:
On Mon, Nov 25, 2019 at 9:09 AM Konstantin Knizhnik
wrote:
JIT was not able to significantly (times) increase speed on Q1 query?
Experi
On Tue, Nov 05, 2019 at 11:18:00AM +0900, Michael Paquier wrote:
> That may have been me. I can take this one if there is nobody else
> around.
>
> Note: I have switched the app as in progress a couple of days ago,
> after AoE was on the 1st of November of course.
So, we are close to the end of
Hi
pá 16. 8. 2019 v 8:41 odesílatel Pavel Stehule
napsal:
> Hi
>
> rebase
>
another rebase
Regards
Pavel
> Pavel
>
diff --git a/contrib/Makefile b/contrib/Makefile
index 92184ed487..dafa42844d 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -15,6 +15,7 @@ SUBDIRS = \
citext \
On Thu, Nov 28, 2019 at 8:54 AM Amit Kapila wrote:
>
> On Wed, Nov 27, 2019 at 10:15 AM vignesh C wrote:
> >
> >
> > Attached patch has the fixes for the above comments.
> >
>
> I have pushed the refactoring patch. In the second patch, I have a
> few more comments. I am not completely sure if i
On Thu, Nov 28, 2019 at 2:00 PM LIANGBO wrote:
>
> Hello:
>
> > Have you considered *also* reporting this to Citus developers, because
> > while the crash seems to have occurred in the core PostgreSQL code they may
> > have a better chance reproducing this if at all.
>
> I've sent this issue to
On Wed, Nov 27, 2019 at 04:09:57PM -0500, Robert Haas wrote:
> Yeah, I like #3 too. If we're going to the trouble to build all of
> this mechanism, it seems worth it to build the additional machinery to
> be precise about the difference between "looks like a problem" and "we
> don't know".
Indeed,
On Thu, Nov 28, 2019 at 01:24:00PM +0900, Amit Langote wrote:
> Have you considered *also* reporting this to Citus developers, because
> while the crash seems to have occurred in the core PostgreSQL code
> they may have a better chance reproducing this if at all.
Hard to fully conclude with the in
Hello,
On Wed, Nov 27, 2019 at 8:59 PM LIANGBO wrote:
> I've met the following problem in our product environment. We tried to
> reproduce the problem, but because of the low probability of occurrence, we
> could not reproduce it.
> 1. phenomenon
> Backend process crashed when executing 2pc tra
On Fri, Nov 01, 2019 at 12:48:50AM -0300, Euler Taveira wrote:
> Hmm. Good idea. Let me try it.
Marked as RwF, as this has not been updated in four weeks. Please
feel free to resubmit later once you have an updated version.
--
Michael
signature.asc
Description: PGP signature
On Mon, Nov 11, 2019 at 12:13:20PM -0800, Paul A Jungwirth wrote:
> I could use some guidance on where in the query-processing pipeline I
> should implement some things here. Basically if you say
> [...]
Paul, please be careful to update correctly the entry of the patch in
the CF app. This was ma
On Fri, Nov 15, 2019 at 06:48:01PM +0300, Konstantin Knizhnik wrote:
> Attached pleased find rebased version of the patch with
> "wal_receiver_start_condition" GUC added (preserving by default original
> behavior).
Konstantin, please be careful with the patch entry in the CF app.
This was marked a
On Thu, Nov 28, 2019 at 01:00:05PM +0900, nuko yokohama wrote:
> To Suggest a "DROP INCREMENTAL MATERIALIZED VIEW" in psql, but the syntax
> error when you run.
> ("DROP MATERIALIZED VIEW" command can drop Incremental Materialozed view
> normally.)
It seems to me that this is just an issue with th
On Wed, Nov 27, 2019 at 10:14:16AM +0100, Fabien COELHO wrote:
> Indeed, I did not notice.
Thanks, Fabien!
--
Michael
signature.asc
Description: PGP signature
Hi.
I'm using the "Incremental Materialized View Maintenance" patch and have
reported the following issues.
(https://commitfest.postgresql.org/25/2138/)
To Suggest a "DROP INCREMENTAL MATERIALIZED VIEW" in psql, but the syntax
error when you run.
("DROP MATERIALIZED VIEW" command can drop Increme
On Wed, Sep 11, 2019 at 04:10:20PM -0700, Peter Geoghegan wrote:
> Why is this not a problem for the new amcheck checks? Maybe this is a
> very naive question. I don't claim to be a GiST expert.
This thread did not receive any updates after a couple of months, and
visibly input was waited from An
On Wed, Nov 06, 2019 at 10:01:43PM +0800, Quan Zongliang wrote:
> What the user needs is the same replication link that selectively skips some
> transactions. And this choice only affects transactions that are doing bulk
> delete sessions. The operations of other sessions are not affected and can
>
Hi
čt 28. 11. 2019 v 3:56 odesílatel David Fetter napsal:
> On Wed, Nov 27, 2019 at 08:47:56AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > I have a report from my customer about migration his application from
> > Oracle to Postgres.
> >
> > The most significant issue was missing correct estimatio
On 11/27/19 9:35 PM, Michael Paquier wrote:
> On Fri, Nov 15, 2019 at 09:45:59PM +0100, Pavel Stehule wrote:
>> Maybe ERRCODE_NULL_VALUE_NOT_ALLOWED, and "NULL is not allowed",
>> errdetail - a exception due setting "null_value_treatment" =>
>> raise_exception
>> and maybe some errhint - "Maybe y
On 2019/11/27 13:22, Michael Paquier wrote:
On Wed, Nov 27, 2019 at 11:35:14AM +0900, Artur Zakirov wrote:
Other approach is similar to Anastasia's patch, which is scanning pg_proc,
pg_class, pg_attribute and others to get modified ACL's and compare it with
initial ACL from pg_init_privs. Next s
On Wed, Nov 27, 2019 at 10:15 AM vignesh C wrote:
>
>
> Attached patch has the fixes for the above comments.
>
I have pushed the refactoring patch. In the second patch, I have a
few more comments. I am not completely sure if it is a good idea to
write a new test file 060_dropdb_force.pl when we
On Wed, Nov 13, 2019 4:20AM (GMT +9), Tomas Vondra wrote:
> On Tue, Nov 12, 2019 at 10:49:49AM +, k.jami...@fujitsu.com wrote:
> >On Thurs, November 7, 2019 1:27 AM (GMT+9), Robert Haas wrote:
> >> On Tue, Nov 5, 2019 at 10:34 AM Tomas Vondra
> >>
> >> wrote:
> >> > 2) This adds another hashta
On Wed, Oct 02, 2019 at 05:08:07PM +0200, Jehan-Guillaume de Rorthais wrote:
> I wonder if this is useful to show these messages for slots that were already
> dead before this checkpoint?
This thread has been waiting for input from the patch author,
Horiguchi-san, for a couple of months now, so I
On Thu, Nov 28, 2019 at 3:45 PM Michael Paquier wrote:
> On Tue, Sep 17, 2019 at 10:03:20AM +1200, Thomas Munro wrote:
> > Oops, right. So it should just be added to the if condition. Will do.
>
> It's been a couple of months and the discussion has stale. It seems
> also that the patch was wait
On Wed, Nov 27, 2019 at 08:47:56AM +0100, Pavel Stehule wrote:
> Hi
>
> I have a report from my customer about migration his application from
> Oracle to Postgres.
>
> The most significant issue was missing correct estimation for coalesce
> function. He had to rewrite coalesce(var, X) = X to "var
On Thu, Nov 28, 2019 at 10:41:14AM +0900, Amit Langote wrote:
> I wonder why we don't use the same style for $subject as pg_basebackup
> --progress, that is, use a carriage return instead of a newline after
> each line reporting the number of tuples copied?
>
> Attached patch for that.
I have not
On Tue, Sep 17, 2019 at 10:03:20AM +1200, Thomas Munro wrote:
> Oops, right. So it should just be added to the if condition. Will do.
It's been a couple of months and the discussion has stale. It seems
also that the patch was waiting for an update. So I am marking it as
RwF for now. Please fe
On Tue, Sep 03, 2019 at 06:30:32PM -0400, Tom Lane wrote:
> Oh ... actually, I bet the problem is that the patch thinks it's okay
> to immediately free space in PlanCacheRelCallback and friends, rather
> than just marking invalid entries as invalid. Nope, you cannot do that.
> You can't tell wheth
On Wed, Nov 27, 2019 at 04:28:18PM +0100, Tomas Vondra wrote:
> Yes. I was considering using the test_pglz extension first, but in the
> end I decided an end-to-end test is easier to do and more relevant.
I actually got something in this area in one of my trees:
https://github.com/michaelpq/pg_plu
On Fri, Nov 15, 2019 at 09:45:59PM +0100, Pavel Stehule wrote:
> Maybe ERRCODE_NULL_VALUE_NOT_ALLOWED, and "NULL is not allowed",
> errdetail - a exception due setting "null_value_treatment" =>
> raise_exception
> and maybe some errhint - "Maybe you would to use Jsonb NULL - "null"::jsonb"
>
> I d
On Mon, Nov 25, 2019 at 11:48:29AM +0900, Amit Langote wrote:
> On Mon, Nov 25, 2019 at 11:38 AM Amit Langote wrote:
>> Needed to be rebased, which I did, to be able to test them; patches attached.
>
> Oops, really attached this time.
Euler, this thread is waiting for input from you regarding th
On Tue, Sep 03, 2019 at 01:13:43PM +1200, David Rowley wrote:
> Antonin, Thank you for the review. I will respond to it when I get
> time again.
It has been close to three months since this last update, so marked
the patch as returned with feedback.
--
Michael
signature.asc
Description: PGP sign
On Thu, Sep 05, 2019 at 04:56:40PM -0400, Tom Lane wrote:
> As coded, this certainly breaks pg_stat for those, and for foreign tables
> as well. Likely better to write something like
> "case when relkind = 'i' then do-something-for-indexes else old-code end".
Pierre, as an author of the patch cur
> Note that this is the last patch in the series of IVM patches: now we
> would like focus on blushing up the patches, rather than adding new
> SQL support to IVM, so that the patch is merged into PostgreSQL 13
> (hopefully). We are very welcome reviews, comments on the patch.
>
> BTW, the SGML do
Yamada-san,
Thank you for updating the patch.
On Wed, Nov 27, 2019 at 12:46 PM Tatsuro Yamada
wrote:
> But I just remembered I replaced column name "*_table" with "*_relid"
> based on Robert's comment three months ago, see below:
>
> > /me reviews.
> >
> > + scanning_table
> >
> > I think t
Hi,
I wonder why we don't use the same style for $subject as pg_basebackup
--progress, that is, use a carriage return instead of a newline after
each line reporting the number of tuples copied?
Attached patch for that.
Thanks,
Amit
compactify-pgbench-init-progress-output.patch
Description: Bin
On Fri, Nov 15, 2019 at 12:32:55AM +0100, Daniel Gustafsson wrote:
> > On 14 Nov 2019, at 23:16, Bruce Momjian wrote:
> >
> > On Thu, Nov 14, 2019 at 04:06:52PM -0300, Alvaro Herrera wrote:
> >> BTW, how is one supposed to "manually upgrade databases that use
> >> contrib/isb"? This part is not
On 11/25/19 4:09 PM, Andrew Dunstan wrote:
> On 10/31/19 7:27 PM, Andrew Dunstan wrote:
>> On 10/31/19 6:34 PM, Andrew Dunstan wrote:
>>> This time with attachment.
>>>
>>>
>>> On 10/31/19 6:33 PM, Andrew Dunstan wrote:
This patch provides for an sslpassword parameter for libpq, and a hook
>>
On Wed, 2019-08-28 at 12:52 -0700, Taylor Vesely wrote:
> Right now the patch always initializes 32 spill partitions. Have you
> given
> any thought into how to intelligently pick an optimal number of
> partitions yet?
Attached a new patch that addresses this.
1. Divide hash table memory used by
I got interested in $SUBJECT as a result of the complaint at [1]
about typmods not being checked/enforced in places where they
reasonably should be. The cause is that executor/functions.c's
check_sql_fn_retval() only worries about types not typmods.
Another thing not to like is that it only suppor
Thanks.
(I would suggest renaming the new state LIMIT_WINDOWEND_TIES, because it
seems to convey what it does a little better.)
I think you should add a /* fall-though */ comment after changing state.
Like this (this flow seems clearer; also DRY):
if (!node->noCount &&
On Tue, Nov 26, 2019 at 3:44 PM Thomas Munro wrote:
> I suppose another reason to use such a switch would be if there is a
> change in the versioning scheme; for example, as of today in master we
> are using the glibc version, but a future glibc release might offer an
> interface to query the CLDR
On Wed, Nov 27, 2019 at 3:38 AM Jeevan Chalke
wrote:
> I am still not sure why we need SEND_BACKUP_FILELIST as a separate command.
> Can't we return the file list with START_BACKUP itself?
I had the same thought, but I think it's better to keep them separate.
Somebody might want to use the SEND_B
On 2019-Nov-27, Andrey Borodin wrote:
>
>
> > 27 нояб. 2019 г., в 20:28, Tomas Vondra
> > написал(а):
> >
> >>>
> >>> 6) I'm pretty sure the comment in the 'while (off < len)' branch will be
> >>> badly mangled by pgindent.
> >>
> >> I think I can just write it without line limit and then r
> 27 нояб. 2019 г., в 20:28, Tomas Vondra
> написал(а):
>
>>>
>>> 6) I'm pretty sure the comment in the 'while (off < len)' branch will be
>>> badly mangled by pgindent.
>>
>> I think I can just write it without line limit and then run pgindent.
>> Will try to do it this evening. Also, I wil
On Wed, 27 Nov 2019 at 23:14, Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Wed, 27 Nov 2019 at 13:26, Amit Kapila wrote:
> >
> > On Wed, Nov 27, 2019 at 8:14 AM Amit Kapila
> wrote:
> > >
> > > On Wed, Nov 27, 2019 at 12:52 AM Masahiko Sawada
> > > wrote:
> > > >
> > > >
> > >
On 27.11.2019 6:54, Michael Paquier wrote:
On Tue, Nov 26, 2019 at 11:09:55PM +0100, Masahiko Sawada wrote:
I looked at v4 patch. Here are some comments:
+ /* Skip all mapped relations if TABLESPACE is specified */
+ if (OidIsValid(tableSpaceOid) &&
+
On Wed, 27 Nov 2019 at 13:28, Mahendra Singh wrote:
>
> On Wed, 27 Nov 2019 at 08:14, Amit Kapila wrote:
>>
>> On Wed, Nov 27, 2019 at 12:52 AM Masahiko Sawada
>> wrote:
>> >
>> >
>> > I've incorporated the comments I got so far including the above and
>> > the memory alignment issue.
>> >
>>
>>
On Tue, Nov 26, 2019 at 08:59:22AM +0800, Andy Fan wrote:
The optimizer cost model usually needs 2 inputs, one is used to represent
data distribution and the other one is used to represent the capacity of
the hardware, like cpu/io let's call this one as system stats.
In Oracle database, the sys
Maxence Ahlouche writes:
> The length of %w should probably be computed starting from the last newline
> in PROMPT1.
Good idea, but I think you need to account for "visible" (ie, if the
newline is inside RL_PROMPT_START_IGNORE, it shouldn't change the width).
It might be best to add logic inside
On Wed, Nov 27, 2019 at 06:38:45PM +0300, Konstantin Knizhnik wrote:
On 25.11.2019 18:24, Merlin Moncure wrote:
On Mon, Nov 25, 2019 at 9:09 AM Konstantin Knizhnik
wrote:
JIT was not able to significantly (times) increase speed on Q1 query?
Experiment with VOPS shows that used aggregation al
On 2019-11-27 09:26, Michael Paquier wrote:
On Fri, Sep 13, 2019 at 06:39:40PM -0300, Alvaro Herrera wrote:
I think this patch is at a point where it merits closer review from
fellow committers, so I marked it RfC for now. I hope non-committers
would also look at it some more, though.
I guess
On 25.11.2019 18:24, Merlin Moncure wrote:
On Mon, Nov 25, 2019 at 9:09 AM Konstantin Knizhnik
wrote:
JIT was not able to significantly (times) increase speed on Q1 query?
Experiment with VOPS shows that used aggregation algorithm itself is not
a bottleneck.
Profile also give no answer for t
Hi,
I noticed that this patch does not work when PROMPT1 contains a new line,
since the whole length of PROMPT1 is taken into account for the length of
%w.
Attached screenshot shows the issue on my psql, with the following PROMPT
variables (colors edited out for readability):
\set PROMPT1 '\n[pid
On Wed, Nov 27, 2019 at 05:47:25PM +0500, Andrey Borodin wrote:
Hi Tomas!
Thanks for benchmarking this!
26 нояб. 2019 г., в 14:43, Tomas Vondra
написал(а):
On Mon, Nov 25, 2019 at 05:29:40PM +0900, Michael Paquier wrote:
On Mon, Nov 25, 2019 at 01:21:27PM +0500, Andrey Borodin wrote:
I th
po 25. 11. 2019 v 14:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Mon, Jun 17, 2019 at 05:31:40AM +0200, Pavel Stehule wrote:
> >
> > > I like anycompatible and anycompatiblearray.
> > >
> > > I'll update the patch
> > >
> >
> > and here it is
>
> Thanks for the patch! I've r
On 27.11.2019 15:12, Rafia Sabih wrote:
On Wed, 27 Nov 2019 at 12:33, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
Hi hackers,
I wonder how it is possible to prohibit parallel scan for the
external
storage accessed through tableam?
For example if I wan
Hi Tomas!
Thanks for benchmarking this!
> 26 нояб. 2019 г., в 14:43, Tomas Vondra
> написал(а):
>
> On Mon, Nov 25, 2019 at 05:29:40PM +0900, Michael Paquier wrote:
>> On Mon, Nov 25, 2019 at 01:21:27PM +0500, Andrey Borodin wrote:
>>> I think status Needs Review describes what is going on bet
On 2019-11-26 21:33, Tom Lane wrote:
Peter Eisentraut writes:
My revised proposal is to remove --disable-float8-byval as a configure
option but keep it as an option in pg_config_manual.h. It is no longer
useful as a user-facing option, but as was pointed out, it is somewhat
useful for develope
On Wed, 27 Nov 2019 at 08:14, Amit Kapila wrote:
> On Wed, Nov 27, 2019 at 12:52 AM Masahiko Sawada
> wrote:
> >
> >
> > I've incorporated the comments I got so far including the above and
> > the memory alignment issue.
> >
>
> Thanks, I will look into the new version. BTW, why haven't you pos
On Wed, Nov 27, 2019 at 8:14 AM Amit Kapila wrote:
>
> On Wed, Nov 27, 2019 at 12:52 AM Masahiko Sawada
> wrote:
> >
> >
> > I've incorporated the comments I got so far including the above and
> > the memory alignment issue.
> >
>
> Thanks, I will look into the new version.
>
Few comments:
-
> It seems to me that there is a good point to be consistent with the treatment
> of StaticAssertStmt and StaticAssertExpr in c.h, which have fallback
> implementations in *all* the configurations supported.
Consistency is good, but:
* That is beyond the scope for what I wanted my patch to achi
On Wed, 27 Nov 2019 at 12:33, Konstantin Knizhnik
wrote:
> Hi hackers,
>
> I wonder how it is possible to prohibit parallel scan for the external
> storage accessed through tableam?
> For example if I want to implement specialized tableam for fast access
> to temp tables, how can I inform optimiz
Dear all,
I've met the following problem in our product environment. We tried to
reproduce the problem, but because of the low probability of occurrence, we
could not reproduce it.
1. phenomenon
Backend process crashed when executing 2pc transaction in citus.
- coordinator
2019
Hi Andres,
>>> As far as I can tell we should be able to use the prototype based approach
>>> in all the cases where we currently use the "negative bit-field width"
>>> approach?
>> ...
>> But I did not refactor existing code to use the new way because I was
>> fearful that there might be some
Hi hackers,
I wonder how it is possible to prohibit parallel scan for the external
storage accessed through tableam?
For example if I want to implement specialized tableam for fast access
to temp tables, how can I inform optimizer that
parallel scan is not possible (because table data is local
On Wed, Nov 27, 2019 at 05:01:47PM +0900, Michael Paquier wrote:
On Tue, Nov 26, 2019 at 09:05:59PM +0100, Tomas Vondra wrote:
Yeah, although the difference is minimal. We could probably construct a
benchmark where #2 wins, but I think these queries are fairly realistic.
So I'd just go with #1.
Michaël,
Not this round.
You have registered yourself as a reviewer of this patch since the end
of June. Could you please avoid that? Sometimes people skips patches
when they see someone already registered to review it.
Yep. ISTM that I did a few reviews on early versions of the patch, wh
On Mon, Sep 30, 2019 at 12:38:02AM -0700, Andres Freund wrote:
> That does not strike me as a good idea. The upper layer is going to need
> to manage some resources (e.g. it's the only bit that knows about how to
> manage lifetime of the incoming data), and by exposing it to each AM
> we're going t
On Wed, Sep 04, 2019 at 04:11:17PM -0400, Alvaro Herrera wrote:
> This patch has been dormant for months. There's been at lot of
> discussion but it doesn't seem conclusive; it doesn't look like we know
> what we actually want to do. Can I try to restart the discussion and
> see if we can get to
Bonjour Michaël,
Please note that you have received comments on this patch a couple of
weeks ago. The patch was still marked as "needs review", which was
incorrect, and it does not apply. Perhaps you did not notice it, so I
am moving it to next CF, waiting on author for a rebase and for
repli
On Tue, Nov 26, 2019 at 6:09 PM Alvaro Herrera
wrote:
> I rebased this patch, and my proposed changes are in 0002.
>
Thank you
>
> Looking at the changes in ExecLimit, I'm wondering if it would be better
> to add a new state to the state machine there -- instead of doing all
> the work in dupli
On Tue, 26 Nov 2019 at 12:10, Amit Kapila wrote:
>
> On Tue, Nov 26, 2019 at 11:19 AM Amit Khandekar
> wrote:
> >
> > On Tue, 26 Nov 2019 at 10:49, Amit Kapila wrote:
> > >
> > >
> > > So, what is the next step here? How about if we somehow check whether
> > > the file exists before doing unli
On Wed, Nov 13, 2019 at 7:04 PM Asif Rehman wrote:
>
> Sorry, I sent the wrong patches. Please see the correct version of the
> patches (_v6).
>
Review comments on these patches:
1.
+XLogRecPtrwal_location;
Looking at the other field names in basebackup_options structure, let's use
wal
On Wed, Sep 11, 2019 at 04:25:07PM +0200, Fabien COELHO wrote:
> Not this round.
You have registered yourself as a reviewer of this patch since the end
of June. Could you please avoid that? Sometimes people skips patches
when they see someone already registered to review it.
The patch applies c
On Fri, Sep 13, 2019 at 06:39:40PM -0300, Alvaro Herrera wrote:
> I think this patch is at a point where it merits closer review from
> fellow committers, so I marked it RfC for now. I hope non-committers
> would also look at it some more, though.
I guess so. The patch has conflicts in the seria
On Thu, Nov 21, 2019 at 04:50:22AM +, Smith, Peter wrote:
> I thought this submission actually started out very popular, but
> then support slowly eroded, and currently seems headed towards a
> likely rejection.
Yeah, it seems to me that this tends to be a rejection, and the thread
has actuall
On Mon, Sep 23, 2019 at 09:55:24PM +0800, Binguo Bao wrote:
> Personally, I prefer patch v10. Its performance is superior, although it
> exposes some struct details.
Please be careful. The patch was waiting for author input, but its
latest status does not match what the CF app was saying. I have
On Tue, Nov 05, 2019 at 04:04:25PM +1300, Thomas Munro wrote:
> On Thu, Sep 12, 2019 at 10:10 AM Alvaro Herrera
> wrote:
> > Here's a rebased version of this patch (it had a trivial conflict).
>
> Hi, FYI partition_prune.sql currently fails (maybe something to do
> with commit d52eaa09?):
David,
Hi Alexander,
On Mon, Sep 23, 2019 at 10:54:51PM +0300, Alexander Korotkov wrote:
> Revised patch is attached.
The commit log of the patch reads like that:
"Fix handling Inf and Nan values in GiST pairing heap comparator"
That's obviously incorrect. Do you have an updated patch? I am
moving th
On Tue, Nov 26, 2019 at 09:05:59PM +0100, Tomas Vondra wrote:
> Yeah, although the difference is minimal. We could probably construct a
> benchmark where #2 wins, but I think these queries are fairly realistic.
> So I'd just go with #1.
Nice results. Using your benchmarks it indeed looks like pat
86 matches
Mail list logo
