> High-level approaches:
>
> 1. When the in-memory hash table fills, keep existing entries in the
> hash table, and spill the raw tuples for all new groups in a
> partitioned fashion. When all input tuples are read, finalize groups
> in memory and emit. Now that the in-memory hash table is cleared
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:not tested
Hi Antonin,
It is very glad to see the new patch. I used the publ
Hello Robert,
All in all, pgbench overheads are small compared to postgres processing
times and representative of a reasonably optimized client application.
It's pretty easy to devise tests where pgbench is client-limited --
just try running it with threads = clients/4, sometimes even
clients
Hello.
At Fri, 2 Aug 2019 11:35:06 +1200, Thomas Munro wrote
in
> On Sat, Jul 27, 2019 at 6:26 PM Noah Misch wrote:
> > On Thu, Jul 25, 2019 at 10:39:36AM +0900, Kyotaro Horiguchi wrote:
> > > No substantial change have been made by this rebasing.
> >
> > Thanks. I'll likely review this on 20
On Fri, Aug 2, 2019 at 6:55 AM Amit Langote wrote:
>
> On Fri, Aug 2, 2019 at 9:18 AM Thomas Munro wrote:
> > On Thu, Aug 1, 2019 at 7:12 PM Pavlo Golub wrote:
> > > > As a normal lurker on hackers, it has been nice seeing the weekly
> > > > updates. Thanks for those.
> > >
> > > Yeap! Great jo
On Wed, Jul 31, 2019 at 04:43:26PM -0400, Alvaro Herrera wrote:
> As for the test module, the one I submitted takes a lot of time to run
> (well, 60s) and I don't think it's a good idea to include it as
> something to be run all the time by every buildfarm member. I'm not
> sure that there's a lea
On Fri, Aug 2, 2019 at 9:18 AM Thomas Munro wrote:
> On Thu, Aug 1, 2019 at 7:12 PM Pavlo Golub wrote:
> > > As a normal lurker on hackers, it has been nice seeing the weekly
> > > updates. Thanks for those.
> >
> > Yeap! Great job! Please, do the same for the rest of our lifes. :)
>
> I guess t
On Thu, Aug 01, 2019 at 06:59:06PM -0700, Peter Geoghegan wrote:
> Seems like I should propose a patch this time around. I don't do Perl,
> but I suppose I could manage something as trivial as this.
Well, that new project policy is not that well-advertised then, see
for example the recent 5925e55,
On Thu, Aug 01, 2019 at 11:01:59PM -0400, Alvaro Herrera wrote:
> I think slight variations don't really detract from the value of the
> product, and consider the odd variation a reminder of the diversity of
> the project. I don't suggest that we purposefully introduce spelling
> variations, or th
On Thu, Aug 01, 2019 at 05:01:17AM -0700, legrand legrand wrote:
> Shouldn't we update associated commitfest entry
> https://commitfest.postgresql.org/15/1318/
>
> to give it a chance to be included in pg13 ?
Well, it is mainly a matter of finding somebody willing to do the
legwork, in which case
Hi,
The Release Management Team is pleased to announce that the release
date for PostgreSQL 12 Beta 3 is set to be 2019-08-08 (wrapping [1]
the release 2019-08-05), together with the next set of planned minor
releases.
We’re excited to make the third beta for this latest major release of
Postgre
On 2019-Aug-01, Tom Lane wrote:
> It's British vs. American spelling. For the most part, Postgres
> follows American spelling, but there's the odd Briticism here and
> there. I'm not sure whether it's worth trying to standardize.
> I think the most recent opinion on this was Munro's:
>
> https:
Peter Geoghegan writes:
> Is it within the discretion of committers to not use the reserved
> range? It seems preferable for everybody to consistently use the
> reserved OID range.
I think it's up to the committer in the end. But if someone submits
a patch using high OIDs, I for one would not ch
Michael Paquier writes:
> On Thu, Aug 01, 2019 at 08:24:17AM -0400, Sehrope Sarkuni wrote:
>> Attached fixes some typos for "serialise" => "serialize" and "materialise"
>> => "materialize".
> These don't seem to be typos:
> https://en.wiktionary.org/wiki/materialise
> https://en.wiktionary.org/wi
Michael Paquier writes:
> On Fri, Aug 02, 2019 at 12:18:12PM +1200, Thomas Munro wrote:
>> In percentages, we returned and rejected 5%, withdrew 5%, committed
>> 28%, and pushed 62% to the next 'fest. That's a wrap. Thanks
>> everyone.
> Thanks Thomas for your efforts in making this possible.
On Thu, Aug 1, 2019 at 1:57 PM Julien Rouhaud wrote:
> Huge +1. Last time I had to pick a new oid it took me ages to find
> the correct range for that. The script could even suggest a random
> free oid in the range, for extra laziness as you also suggested in the
> almost exact same mail at
> CA
On Wed, Jul 31, 2019 at 9:49 PM Alvaro Herrera wrote:
> On 2019-Jul-31, Amit Langote wrote:
> > I noticed that the patch is still marked as "Waiting on Author" ever
> > since Shawn set it that way on June 17. Since Hosoya-san posted
> > updated patches on June 27, the status should've been change
On Thu, Aug 01, 2019 at 08:24:17AM -0400, Sehrope Sarkuni wrote:
> Attached fixes some typos for "serialise" => "serialize" and "materialise"
> => "materialize".
These don't seem to be typos:
https://en.wiktionary.org/wiki/materialise
https://en.wiktionary.org/wiki/serialise
--
Michael
signature
On Fri, Aug 02, 2019 at 12:18:12PM +1200, Thomas Munro wrote:
> In percentages, we returned and rejected 5%, withdrew 5%, committed
> 28%, and pushed 62% to the next 'fest. That's a wrap. Thanks
> everyone.
Thanks Thomas for your efforts in making this possible.
--
Michael
signature.asc
Descri
On Thu, Aug 01, 2019 at 03:14:06PM +0900, Michael Paquier wrote:
> Thanks for the set of flags. So this comes from the use of -Og, and
> the rest of the tree does not complain. The issue is that gcc
> complains about the buffer not being large enough, but %d only uses up
> to 2 characters so ther
On Thu, Aug 1, 2019 at 7:12 PM Pavlo Golub wrote:
> > As a normal lurker on hackers, it has been nice seeing the weekly updates.
> > Thanks for those.
>
> Yeap! Great job! Please, do the same for the rest of our lifes. :)
I guess the CF app could show those kind of metrics, but having a
written
On Thu, Jun 27, 2019 at 6:42 PM Andrey Lepikhov
wrote:
> Version v.17 of the patch that fix the bug see in attachment.
While moving this to the September CF, I noticed that it needs to be
updated for the recent pg_list.h API changes.
--
Thomas Munro
https://enterprisedb.com
On Thu, Aug 1, 2019 at 8:51 PM John Naylor wrote:
> select U&'\de04\d83d'; -- surrogates in wrong order
> -psql:test_unicode.sql:10: ERROR: invalid Unicode surrogate pair at
> or near "U&'\de04\d83d'"
> +psql:test_unicode.sql:10: ERROR: invalid Unicode surrogate pair
> LINE 1: select U&'\de04\
On Sat, Jul 27, 2019 at 6:26 PM Noah Misch wrote:
> On Thu, Jul 25, 2019 at 10:39:36AM +0900, Kyotaro Horiguchi wrote:
> > No substantial change have been made by this rebasing.
>
> Thanks. I'll likely review this on 2019-08-20. If someone opts to review it
> earlier, I welcome that.
Cool. Tha
On Thu, Jun 27, 2019 at 10:17 AM Dent John wrote:
> > On 3 Apr 2019, at 20:54, Nikolay Shaplov wrote:
> > В письме от вторник, 19 марта 2019 г. 16:09:13 MSK пользователь Michael
> > Paquier написал:
> >
> >> Thanks for doing the effort to split that stuff. This looks like an
> >> interesting bas
On Mon, Jul 8, 2019 at 7:04 PM Thomas Munro wrote:
> On Mon, Mar 18, 2019 at 8:46 PM Chris Travers
> wrote:
> > On Mon, Mar 18, 2019 at 4:09 AM Michael Paquier wrote:
> >> On Sun, Mar 17, 2019 at 09:00:57PM +0800, Chris Travers wrote:
> >> > I also added test cases and some docs. I don't know
On Sat, Jun 29, 2019 at 4:19 AM Li, Zheng wrote:>
> Resending patch v2.2, looks like the previous submission did not get attached
> to the original thread.
>
> This version fixed an issue that involves CTE. Because we call
> subquery_planner before deciding whether to proceed with the transforma
Anastasia Lubennikova writes:
> Thank you for pointing out on specific of int4() function,
> I updated tests to use dummy plpgsql function.
> I'm not sure if tests of various join types are redundant but I left them.
> As far as I understand, the principal motivation of this patch was to
> optimi
On Tue, Jul 9, 2019 at 11:07 PM Daniel Gustafsson wrote:
> The attached v3 also has that fix in order to see if the cfbot is happier with
> this.
Noticed while moving this to the next CF:
heap.c: In function ‘StorePartitionKey’:
1191heap.c:3582:3: error: ‘referenced’ undeclared (first use in thi
On Sat, Jul 13, 2019 at 5:32 AM Nikita Glukhov wrote:
> Attached 13th version of the patches.
While moving this to the next CF, I noticed that this needs to be
adjusted for the new pg_list.h API.
--
Thomas Munro
https://enterprisedb.com
On Mon, Jul 15, 2019 at 10:52 PM Paul Guo wrote:
> Please see the attached v4 patch.
While moving this to the next CF, I noticed that this needs updating
for the new pg_list.h API.
--
Thomas Munro
https://enterprisedb.com
On Thu, Jul 25, 2019 at 5:49 AM Tom Lane wrote:
> David Rowley writes:
> > Here's a more polished version with the debug code removed, complete
> > with benchmarks.
>
> A few gripes:
>
> [gripes]
Based on the above, I've set this to "Waiting on Author", in the next CF.
--
Thomas Munro
https://
On Thu, Aug 1, 2019 at 10:52 PM Andres Freund wrote:
>
> On 2019-08-01 22:42:23 +0200, Julien Rouhaud wrote:
> > Sure, but it requires extra wrapper functions, and the st_changecount
> > dance when writing the new value.
>
> So? You need a wrapper function anyway, there's no way we're going to
> a
Hi,
On 2019-08-01 22:49:48 +0200, Julien Rouhaud wrote:
> On Thu, Aug 1, 2019 at 8:36 PM Andres Freund wrote:
> >
> > On 2019-08-01 14:20:46 -0400, Robert Haas wrote:
> > > However, I think that the fact that this patch adds 15 new calls to
> > > pg_atomic_write_u64(&MyProc->queryId, ...) is prob
On Thu, 1 Aug 2019 at 17:57, Thomas Munro wrote:
>
> On Thu, Aug 1, 2019 at 5:51 PM Edmund Horner wrote:
> > I tried moving it to the new commitfest, but it seems I cannot from
> > its current state.
>
> Done. You have to move it to "Needs review" first, and then move to
> next. (Perhaps we sho
On Thu, Aug 1, 2019 at 10:37 PM Peter Geoghegan wrote:
>
> I pushed a commit that required a new pg_proc entry today. Had I not
> been involved with the work that became commit a6417078, I would
> definitely not have used an OID from the range reserved for devel
> system catalogs (8000 - 8999). As
Hi,
On 2019-08-01 22:42:23 +0200, Julien Rouhaud wrote:
> On Thu, Aug 1, 2019 at 8:36 PM Andres Freund wrote:
> >
> > On 2019-08-01 08:45:45 +0200, Julien Rouhaud wrote:
> > > On Wed, Jul 31, 2019 at 11:59 PM Andres Freund wrote:
> > > > And if it were necessary, why wouldn't any of the other fi
On Thu, Aug 1, 2019 at 8:36 PM Andres Freund wrote:
>
> On 2019-08-01 14:20:46 -0400, Robert Haas wrote:
> > However, I think that the fact that this patch adds 15 new calls to
> > pg_atomic_write_u64(&MyProc->queryId, ...) is probably not a good
> > sign. It seems like we ought to be able to cen
Hello Richard,
thanks for your quick reply.
> We need to fix this.
Do you have a better idea than just keeping the old quals - possibly just the
ones that get eliminated - in a separate data structure? Is the push down of
quals the only case of elimination of quals, only counting the ones w
"Tom Lane" wrote:
> Uh ... why? The pushed-down restrictions should result in pruning
> away any prunable partitions at the scan level, leaving nothing for
> the partitionwise join code to do.
It seems reasonable to me that the join condition can no longer be verified,
since 'sc.sl = sg.sl' is
On Thu, Aug 1, 2019 at 8:36 PM Andres Freund wrote:
>
> On 2019-08-01 08:45:45 +0200, Julien Rouhaud wrote:
> > On Wed, Jul 31, 2019 at 11:59 PM Andres Freund wrote:
> > > And if it were necessary, why wouldn't any of the other fields in
> > > PgBackendStatus need it? There's plenty of other fiel
I pushed a commit that required a new pg_proc entry today. Had I not
been involved with the work that became commit a6417078, I would
definitely not have used an OID from the range reserved for devel
system catalogs (8000 - 8999). As I understand it, this is now
standard practice.
Perhaps unsurpri
>
>
> > The people who expressed opinions on nuking triggers from orbit (it's
> the only way to be sure) have yet to offer up any guidance on how to
> proceed from here, and I suspect it's because they're all very busy getting
> things ready for v12. I definitely have an interest in working on this
Alexander Korotkov writes:
> On Thu, Aug 1, 2019 at 9:59 PM Tom Lane wrote:
>> While I've not attempted to fix that here, I wonder whether we shouldn't
>> fix it by just forcing forcedRecheck to true in any case where we discard
>> an ALL qualifier.
> +1 for setting forcedRecheck in any case we
On Thu, Aug 1, 2019 at 9:59 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > On Thu, Aug 1, 2019 at 4:37 PM Tom Lane wrote:
> >> Eyeing this a bit further ... doesn't scanPendingInsert also need
> >> to honor so->forcedRecheck? Something along the lines of
>
> > I think so.
>
> Yeah, it does -
Andres Freund writes:
> Fair enough. I'm mildly worried that people will just carry their
> timezone setting from one version's postgresql.conf to the next as they
> upgrade.
Maybe. I don't believe pg_upgrade copies over the old postgresql.conf,
and I doubt we should consider it good practice in
Julien Rouhaud writes:
> On Thu, Aug 1, 2019 at 4:37 PM Tom Lane wrote:
>> Eyeing this a bit further ... doesn't scanPendingInsert also need
>> to honor so->forcedRecheck? Something along the lines of
> I think so.
Yeah, it does --- the updated pg_trgm test attached fails if it doesn't.
Also,
>
> It seems this topic is ongoing so I've moved it to the September CF,
> but it's in "Waiting on Author" because we don't have a concrete patch
> that applies (or agreement on what it should do?) right now.
>
All recent work has been investigating the need(s) we're trying to address.
This is as
On 17/06/2019 15:53, Paul Guo wrote:
I noticed that to do batch insert, we might need additional memory copy
sometimes comparing with "single insert"
(that should be the reason that we previously saw a bit regressions) so a
good solution seems to fall back
to "single insert" if the tuple length i
Hmm, I'm trying this out now and I don't see the index_rebuild_count
ever go up. I think it's because the indexes are built using parallel
index build ... or maybe it was the table AM changes that moved things
around, not sure. There's a period at the end when the CLUSTER command
keeps working, b
Hi,
On 2019-08-01 08:45:45 +0200, Julien Rouhaud wrote:
> On Wed, Jul 31, 2019 at 11:59 PM Andres Freund wrote:
> > And if it were necessary, why wouldn't any of the other fields in
> > PgBackendStatus need it? There's plenty of other fields written to
> > without a lock, and several of those are
On 2019-08-01 14:20:46 -0400, Robert Haas wrote:
> However, I think that the fact that this patch adds 15 new calls to
> pg_atomic_write_u64(&MyProc->queryId, ...) is probably not a good
> sign. It seems like we ought to be able to centralize it better than
> that.
+1
Hi,
On 2019-08-01 13:59:11 -0400, Tom Lane wrote:
> Andres Freund writes:
> > When used and a symlink, could we resolve the symlink when determining
> > the timezone? When loading a timezone in the backend, not during
> > initdb. While that'd leave us with the instability, it'd at least would
> >
On Thu, Aug 1, 2019 at 2:46 AM Julien Rouhaud wrote:
> This patch is actually storing the queryid in PGPROC, not in
> PgBackendStatus, thus the need for an atomic. I used PGPROC because
> the value needs to be available in log_line_prefix() and spi.c, so
> pgstat.c / PgBackendStatus didn't seem l
Andres Freund writes:
> When used and a symlink, could we resolve the symlink when determining
> the timezone? When loading a timezone in the backend, not during
> initdb. While that'd leave us with the instability, it'd at least would
> help clients etc understand what the setting actually means?
On Thu, Aug 1, 2019 at 1:53 PM Andres Freund wrote:
> Could you wait until I either had a chance to look again, or until, say,
> Monday if I don't get around to it? I'll try to get to it earlier than
> that.
Sure, no problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpr
26.07.2019 21:26, Tom Lane wrote:
I took a quick look at this and I have a couple of gripes ---
* The naming and documentation of transform_const_function_to_result
seem pretty off-point to me. ISTM the real goal of that function is to
pull up constant values from RTE_FUNCTION RTEs. Replacing
Hi,
On 2019-08-01 12:23:42 -0400, Robert Haas wrote:
> Barring objections, I plan to commit the whole series of patches here
> (latest rebase attached). They are not perfect and could likely be
> improved in various ways, but I think they are an improvement over
> what we have now, and it's not l
Hi,
On 2019-08-01 08:52:52 +0200, Fabien COELHO wrote:
> sh> time pgbench -r -T 30 -M prepared
> ...
> latency average = 2.425 ms
> tps = 412.394420 (including connections establishing)
> statement latencies in milliseconds:
> 0.001 \set aid random(1, 10 * :scale)
> 0.000 \
On Thu, Aug 1, 2019 at 4:45 AM Thomas Munro wrote:
> On Tue, Jul 23, 2019 at 4:51 PM Tatsuro Yamada
> wrote:
> > Attached v4 patch file only includes this fix.
>
> I've moved this to the September CF, where it is in "Needs review" state.
/me reviews.
+ scanning_table
I think this should b
Hi,
On 2019-08-01 10:08:01 -0400, Tom Lane wrote:
> I have in fact committed that patch. It won't do anything for your
> problem with respect to existing installations that may have picked
> "localtime", but it'll at least prevent new initdb runs from picking
> that.
> Avoid choosing "localt
Hi,
On 2019-08-01 20:08:15 +1200, Thomas Munro wrote:
> On Tue, Jul 30, 2019 at 5:58 PM Andres Freund wrote:
> > > +#include "c.h"
> > > +static void (* volatile bzero_p)(void *, size_t) = bzero2;
> >
> > Hm, I'm not really sure that this does that much. Especially when the
> > call is via a func
On 31.07.2019 19:56, Heikki Linnakangas wrote:
On 09/07/2019 23:59, Konstantin Knizhnik wrote:
Fixed patch version of the path is attached.
Much of the patch and the discussion has been around the raw parsing,
and guessing which literals are actually parameters that have been
inlined into
On 26.07.2019 20:43, Liudmila Mantrova wrote:
I would like to suggest a couple of changes to docs and comments,
please see the attachment.
The "...or fetched on startup" part also seems wrong here, but it's
not a part of your patch, so I'm going to ask about it on psql-docs
separately.
Agre
On Thu, Aug 1, 2019 at 8:34 AM Brandur Leach wrote:
> Thanks Peter. V6 is pretty uncontroversial by me — the new
> conditional ladder broken cleanly into cases of (1) all
> subnet, (2) network/subnet mix, and (3) all network is a
> little more verbose, but all in all makes things easier to
> reaso
Tom,
> I have in fact committed that patch. It won't do anything for your
> problem with respect to existing installations that may have picked
>"localtime", but it'll at least prevent new initdb runs from picking
> that.
Thanks! At least over time the problem will hopefully diminish.
Thanks Peter. V6 is pretty uncontroversial by me — the new
conditional ladder broken cleanly into cases of (1) all
subnet, (2) network/subnet mix, and (3) all network is a
little more verbose, but all in all makes things easier to
reason about.
> Do you have any final input on the testing, Brandur
On Thu, Aug 1, 2019 at 4:37 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > Attached v4 that should address all comments.
>
> Eyeing this a bit further ... doesn't scanPendingInsert also need
> to honor so->forcedRecheck? Something along the lines of
>
> - tbm_add_tuples(
extern uint64 pg_strtouint64(const char *str, char **endptr, int base);
called 3 times, always with base == 10. We have a similar name but a totally
different interface, so basically it would have to be replaced
by something like the first interface.
My understanding on this one was to nuke
On Thu, 1 Aug 2019 at 11:30, Tomas Vondra wrote:
>
> I'll move it to the next CF. Aside from the issues pointed by Kyotaro-san
> in his review, I still haven't made my mind about whether to base the use
> statistics targets set for the attributes. That's what we're doing now,
> but I'm not sure it
Julien Rouhaud writes:
> Attached v4 that should address all comments.
Eyeing this a bit further ... doesn't scanPendingInsert also need
to honor so->forcedRecheck? Something along the lines of
- tbm_add_tuples(tbm, &pos.item, 1, recheck);
+ tbm_add_t
Richard Guo writes:
> For the third query, a rough investigation shows that, the qual 'sl =
> 5' and 'sc.sl = sg.sl' will form an equivalence class and generate two
> implied equalities: 'sc.sl = 5' and 'sg.sl = 5', which can be pushed
> down to the base rels. One consequence of the deduction is
Shay Rojansky writes:
>> I'm not sure we're any closer to a meeting of the minds on whether
>> consulting zone[1970].tab is a good thing to do, but we got an actual
>> user complaint[1] about how "localtime" should not be a preferred
>> spelling. So I want to go ahead and insert the discussed ant
On Thu, Aug 1, 2019 at 5:36 PM Thomas Munro wrote:
>
> Hi Vignesh,
>
> On Thu, Aug 1, 2019 at 9:32 PM vignesh C wrote:
> > In the undo system, we use full-transaction-id for transactions. For
> > rollback of prepared transactions, we were planning to use
> > FullTransactionId by combining Transa
On Thu, Aug 1, 2019 at 2:53 AM Fabien COELHO wrote:
> All in all, pgbench overheads are small compared to postgres processing
> times and representative of a reasonably optimized client application.
It's pretty easy to devise tests where pgbench is client-limited --
just try running it with threa
Hi Ryan,
sorry for not be fast to replay
> I was suggesting a warning in the documentation so users aren't caught
> unaware about the performance characteristics. My first version was very
> rough, how about adding this in doc/src/sgml/ref/select.sgml?
>
> "Using PERCENT is best suited to return
Hi,
Attached fixes some typos for "serialise" => "serialize" and "materialise"
=> "materialize".
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
From 30d34d082120ac2c041a4ad45e9d6e31b0ea9c9d Mon Sep 17 00:00:00 2001
From: Sehrope Sarkuni
Date: Thu, 1 Aug 2019 0
2019年8月1日(木) 19:24 Tomas Vondra :
>
> On Thu, Aug 01, 2019 at 06:28:08PM +0900, Kohei KaiGai wrote:
> >2019年8月1日(木) 16:19 Richard Guo :
> >>
> >> On Thu, Aug 1, 2019 at 2:12 PM Kohei KaiGai wrote:
> >>>
> >>> 2019年8月1日(木) 1:41 Tom Lane :
> >>> >
> >>> > Robert Haas writes:
> >>> > > Yeah, but I h
Hi Vignesh,
On Thu, Aug 1, 2019 at 9:32 PM vignesh C wrote:
> In the undo system, we use full-transaction-id for transactions. For
> rollback of prepared transactions, we were planning to use
> FullTransactionId by combining TransactionId and epoch, but as
> suggested by multiple people in that
Hello,
shouldn't we update associated commitfest entry
https://commitfest.postgresql.org/15/1318/
to give it a chance to be included in pg13 ?
Regards
PAscal
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On Thu, Aug 1, 2019 at 11:51 PM Michael Paquier wrote:
> On Thu, Aug 01, 2019 at 11:05:34PM +1200, Thomas Munro wrote:
> > I've moved this to the next CF, and set it to "Needs review" since a
> > rebase was provided.
>
> I may be missing something of course, but in this case we argued about
> addi
Hi,
Le jeu. 1 août 2019 à 13:51, Michael Paquier a écrit :
> On Thu, Aug 01, 2019 at 11:05:34PM +1200, Thomas Munro wrote:
> > I've moved this to the next CF, and set it to "Needs review" since a
> > rebase was provided.
>
> I may be missing something of course, but in this case we argued about
On Thu, Aug 01, 2019 at 11:05:34PM +1200, Thomas Munro wrote:
> I've moved this to the next CF, and set it to "Needs review" since a
> rebase was provided.
I may be missing something of course, but in this case we argued about
adding a couple of more fields. In consequence, the patch should be
wa
On Wed, Jul 31, 2019 at 6:27 AM Karl O. Pinc wrote:
> On Tue, 30 Jul 2019 11:40:03 -0400
> Tom Lane wrote:
> [review]
> Thanks for the help. I will wait for a response to this
> before submitting another patch, just in case someone sees any
> ideas here to be followed up on.
Based on the above
On Thu, Aug 01, 2019 at 11:34:34AM +0200, Fabien COELHO wrote:
> However there is a contrary objective to have a unified interface,
> but there also exists a:
>
> extern uint64 pg_strtouint64(const char *str, char **endptr, int base);
>
> called 3 times, always with base == 10. We have a simila
On Tue, Jul 30, 2019 at 9:39 AM Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
>
> I am almost done writing the patch for pg_combinebackup and will post soon.
>
Attached patch which implements the pg_combinebackup utility used to combine
full basebackup with one or more incremental ba
On Thu, Aug 1, 2019 at 5:38 PM Arne Roland wrote:
> Hello,
>
> I attached one example of a partitioned table with multi column partition
> key. I also attached the output.
> Disabling the hash_join is not really necessary, it just shows the more
> drastic result in the case of low work_mem.
>
> C
On Thu, Jul 18, 2019 at 1:28 AM Nikita Glukhov wrote:
> 1. I fixed some bugs (fixed patch with additional test cases is attached):
Hi Nikita,
Thanks. I have set this to "Needs review", in the September 'fest.
--
Thomas Munro
https://enterprisedb.com
On Thu, Jul 4, 2019 at 8:25 PM Julien Rouhaud wrote:
> On Thu, Jul 4, 2019 at 9:45 AM Michael Paquier wrote:
> > On Wed, Jul 03, 2019 at 08:23:44PM +0200, Julien Rouhaud wrote:
> > > So the patch compiles and works as intended. I don't have much to say
> > > about it, it all looks good to me, sin
On Wed, Jul 24, 2019 at 8:30 PM Martijn van Oosterhout
wrote:
> I'll give it a shot a see how it looks.
Moved to September CF, "Waiting on Author".
--
Thomas Munro
https://enterprisedb.com
On Tue, Feb 26, 2019 at 5:41 AM Corey Huinker wrote:
>> In order to avoid per-row calls of the constraint trigger functions, we could
>> try to "aggregate" the constraint-specific events somehow, but I think a
>> separate queue would be needed for the constraint-specific events.
>>
>> In general,
On Thu, Aug 1, 2019 at 12:13 PM Julien Rouhaud wrote:
>
> On Thu, Aug 1, 2019 at 8:43 AM Thomas Munro wrote:
> >
> > On Wed, Jul 31, 2019 at 5:28 AM Tom Lane wrote:
> > > Meanwhile, I looked at the v3 patch, and it seems like it might not be
> > > too far from committable. I think we should *no
Amit-san,
On Wed, Jul 31, 2019 at 2:47 PM Amit Langote wrote:
> On Tue, Jul 30, 2019 at 6:00 PM Etsuro Fujita wrote:
> > On Fri, Jul 19, 2019 at 10:44 PM Robert Haas wrote:
> > > I don't know whether partition_bounds_merge() is well-implemented; I
> > > haven't looked.
> >
> > My concern about
On Sat, Jul 27, 2019 at 2:43 AM Andrew Dunstan
wrote:
> On 7/23/19 6:48 PM, Nikita Glukhov wrote:
> > Some concrete pieces of review:
> >> +
> >> +FF1
> >> +decisecond (0-9)
> >> +
> >>
> >> Let's not use such weird terms as "deciseconds". We could say
> >> "fraction
On Thu, Aug 01, 2019 at 05:25:31PM +1200, Thomas Munro wrote:
On Thu, Aug 1, 2019 at 12:16 PM Jamison, Kirk wrote:
> On Saturday, July 27, 2019 7:06 AM(GMT+9), Tomas Vondra wrote:
> > On Fri, Jul 26, 2019 at 07:03:41AM +, Jamison, Kirk wrote:
> > >Overall, the patch is almost already in goo
On Thu, Aug 01, 2019 at 06:28:08PM +0900, Kohei KaiGai wrote:
2019年8月1日(木) 16:19 Richard Guo :
On Thu, Aug 1, 2019 at 2:12 PM Kohei KaiGai wrote:
2019年8月1日(木) 1:41 Tom Lane :
>
> Robert Haas writes:
> > Yeah, but I have to admit that this whole design makes me kinda
> > uncomfortable. Ever
On Wed, Jul 31, 2019 at 1:01 AM Ibrar Ahmed wrote:
> I have rebased the patch to master (1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012)
> and fixed some compilation warning. Now I am reviewing the actual code.
Thanks for doing that Ibrar. I think the right status for this CF
entry is now: Needs rev
On Thu, Aug 1, 2019 at 8:43 AM Thomas Munro wrote:
>
> On Wed, Jul 31, 2019 at 5:28 AM Tom Lane wrote:
> > Meanwhile, I looked at the v3 patch, and it seems like it might not be
> > too far from committable. I think we should *not* let this get bogged
> > down in questions of whether EXPLAIN can
Hello
> It has been some time, and I am finally catching up with this patch.
Thank you!
> +
> + WAL receiver will be restarted after primary_slot_name
> + was changed.
>
> The sentence sounds strange. Here is a suggestion:
> The WAL receiver is restarted after an update of primary_sl
On Sun, Jun 23, 2019 at 7:34 AM Corey Huinker wrote:
>> > So what is the uptake on implementing this at the server side, ie.
>> > DESCRIBE?
>>
>> I'm pretty skeptical of this idea, unless you are willing to throw
>> away at least one and possibly both of the following goals:
It seems this topic i
1 - 100 of 137 matches
Mail list logo
