(2019/03/02 1:10), Robert Haas wrote:
On Fri, Mar 1, 2019 at 5:47 AM Etsuro Fujita
wrote:
Robert, I CCed you because you are the author of that commit. Before
that commit ("Rewrite the code that applies scan/join targets to
paths."), apply_scanjoin_target_to_paths() had a boolean parameter na
On 2/8/19 3:30 PM, Raúl Marín wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Tested `pgbench-tap-glob-fix-1.pat
(2019/03/02 1:14), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/03/01 20:00), Antonin Houska wrote:
Sorry, my explanation was not enough again, but I showed that query ("SELECT
a+b, random() FROM foreign_table GROUP BY a+b ORDER BY a+b;") to explain why
the following code bit is needed:
On 2/27/19 2:26 AM, David Rowley wrote:
On Wed, 27 Feb 2019 at 13:13, Tom Lane wrote:
"Li, Zheng" writes:
However, given that the March CommitFest is imminent and the runtime smarts
patent concerns David had pointed out (which I was not aware of before), we
would not move that direction at
On 3/1/19 7:48 AM, Etsuro Fujita wrote:
(2019/03/01 14:17), Tatsuro Yamada wrote:
Attached patch is wip patch.
Is it possible to remove the following patch?
Because I registered the patch twice on CF Mar.
https://commitfest.postgresql.org/22/2049/
Please remove the above and keep this:
htt
Hi Paul,
On 11/24/18 4:55 AM, Paul A Jungwirth wrote:
On Fri, Nov 23, 2018 at 3:41 PM Paul A Jungwirth
wrote:
Here is a patch for my progress on this so far.
Well this is embarrassing, but my last patch used the mistaken syntax
`PRIMARY KEY (cols, WITHOUT OVERLAPS col)`. Here is a new patch
Imai-san,
Thanks for sharing your tests!
On Thu, Feb 28, 2019 at 5:27 PM Imai, Yoshikazu
wrote:
>
> Hosoya-san
>
> On Wed, Feb 27, 2019 at 6:51 AM, Yuzuko Hosoya wrote:
> > > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp]
> > > Sent: Wednesday, February 27, 2019 11:22 AM
> > >
> > > H
Hi David,
On 2019/03/05 17:29, David Steele wrote:
On 3/1/19 7:48 AM, Etsuro Fujita wrote:
(2019/03/01 14:17), Tatsuro Yamada wrote:
Attached patch is wip patch.
Is it possible to remove the following patch?
Because I registered the patch twice on CF Mar.
https://commitfest.postgresql.org/2
Hi Peter,
On 2/28/19 11:43 PM, Peter Moser wrote:
Dear all,
we rebased our temporal normalization patch on top of
554ebf687852d045f0418d3242b978b49f160f44 from 2019-02-28.
I will also add this prototype (WIP) patch to the commitfest of March,
as suggested by two developers met at the
FOSDEM
On Tue, 5 Mar 2019 at 21:21, David Steele wrote:
>
> On 2/27/19 2:26 AM, David Rowley wrote:
> > FWIW, I did add this to the March CF, but I set the target version to
> > 13. I wasn't considering this for PG12. I see Zheng was, but I agree
> > with you on PG13 being the target for this.
>
> Looks
Hi Horiguchi-san,
Thank you for your reply and suggestions.
> > 1. Expand PQtrace() facility and improve libpq logging.
> >
> > 2. Prepare "output level". There are 3 type of levels;
> > - TRADITIONAL : if set, outputs protocol messages
> > - LEVEL1: if set, outputs ph
Hi Robert!
On 2019/03/05 11:35, Robert Haas wrote:
On Mon, Mar 4, 2019 at 5:38 AM Tatsuro Yamada
wrote:
=== Current design ===
CLUSTER command uses Index Scan or Seq Scan when scanning the heap.
Depending on which one is chosen, the command will proceed in the
following sequence of phases:
On 3/5/19 10:53 AM, David Rowley wrote:
On Tue, 5 Mar 2019 at 21:21, David Steele wrote:
On 2/27/19 2:26 AM, David Rowley wrote:
FWIW, I did add this to the March CF, but I set the target version to
13. I wasn't considering this for PG12. I see Zheng was, but I agree
with you on PG13 being t
Hi Ibrar,
On Tue, Mar 5, 2019 at 2:37 AM Ibrar Ahmed wrote:
>
> Hi Yuzuko Hosoya,
>
> Ignore my last message, I think this is also a legitimate scan on default
> partition.
>
Oh, I got it. Thanks a lot.
>
> On Mon, Mar 4, 2019 at 10:29 PM Ibrar Ahmed wrote:
>>
>> Hi
>>
>> Patch work fine to
сб, 2 мар. 2019 г. в 12:14, Alexander Korotkov :
>
> Hi!
Thanks for reply. Comments and questions are below.
>
> On Fri, Feb 1, 2019 at 7:08 PM Matwey V. Kornilov
> wrote:
> > This patch series is to add support for spgist quadtree @<(point,circle)
> > operator. The first two patches are to refa
On 2/28/19 10:43 AM, Osumi, Takamichi wrote:
One past thread about introducing CREATE OR REPLACE TRIGGER into the syntax
had stopped without complete discussion in terms of LOCK level.
The past thread is this. I'd like to inherit this one.
Since this patch landed at the last moment in the la
(2019/03/04 16:46), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/03/01 20:00), Antonin Houska wrote:
It's still unclear to me why add_foreign_ordered_paths() passes the input
relation (input_rel) to estimate_path_cost_size(). If it passed the output rel
(i.e. ordered_rel in this case) li
On Tue, Mar 5, 2019 at 8:27 AM Bossart, Nathan wrote:
>
> On 2/28/19, 12:13 AM, "Masahiko Sawada" wrote:
> > Attached the updated version patch. I've incorporated all review
> > comments I got and have changed the number of tuples being reported as
> > 'removed tuples'. With this option, tuples c
On Sun, 3 Mar 2019 at 01:34, Jim Finnerty wrote:
> I agree with Tom's comment above - when the cost of the NOT IN is dominated
> by the cost of the outer scan (i.e. when the cardinality of the outer
> relation is large relative to the cardinality of the subquery), and if the
> inner cardinality is
(2019/03/01 20:16), Antonin Houska wrote:
Etsuro Fujita wrote:
Conversely, it appears that add_foreign_ordered_paths() added by the patchset
would generate such pre-sorted paths *redundantly* when the input_rel is the
final scan/join relation. Will look into that.
Currently I have no idea
On 03/04/2019 10:57 PM, Andres Freund wrote:
Note that hot_standby_feedback=on needs to be set on a standby, not on
the primary (although it doesn't do any harm there).
Right, This parameter was enabled on both Master and slave.
Is someone able to reproduce this issue ?
--
regards,tushar
Ente
On Tue, Mar 5, 2019 at 3:46 AM Tomas Vondra
wrote:
>
>
>
> On 3/4/19 6:40 AM, Masahiko Sawada wrote:
> > On Sat, Mar 2, 2019 at 5:27 AM Robert Haas wrote:
> >>
> >> On Thu, Feb 7, 2019 at 3:28 AM Masahiko Sawada
> >> wrote:
> >>> WAL encryption will follow as an additional feature.
> >>
> >> I
On Tue, Mar 5, 2019 at 2:25 PM Shawn Debnath wrote:
> [v11 patch]
Thanks. Hmm, something is wrong here because make check is
dramatically slower -- for example the "insert" test runs in ~8-13
seconds instead of the usual ~0.2 seconds according to Travis,
AppVeyor and my local FreeBSD system (not
Hi everyone,
I appreciate all the helpful advice.
I agree to display message more clearly. I will follow your advice.
I would like to add timestamp per line and when command processing function
start/end.
I think it is useful to know the application process start/end for diagnosis.
So I
1. Currently, cube extension has CUBE_MAX_DIM set as 100.
A recent github issue. [1]
2. To compile a custom version of the extension off the tree requires:
```
make -C contrib/custom_cube USE_PGXS=1
```
3. But utils/float.h required by cube.c and cubeparse.y is not installed.
It's not present in
On 2/22/19 2:05 AM, Nikita Glukhov wrote:
Attached set of patches with some jsonb optimizations that were made during
comparison of performance of ordinal jsonb operators and jsonpath operators.
This patch was submitted just before the last commitfest for PG12 and
seems to have potential for b
On 2019/03/05 9:50, Amit Langote wrote:
> I'll post the updated patches after diagnosing what
> I'm suspecting a memory over-allocation bug in one of the patches. If you
> configure build with --enable-cassert, you'll see that throughput
> decreases as number of partitions run into many thousands,
On 2019/03/04 19:38, Amit Langote wrote:
> 2. Defer inheritance expansion to add_other_rels_to_query(). Although the
> purpose of doing this is to perform partition pruning before adding the
> children, this patch doesn't change when the pruning occurs. It deals
> with other issues that must be t
On 04.03.2019 21:31, Justin Pryzby wrote:
It wasn't intentional. Find attached v3 patch which handles that case,
by removing the 2nd call to errdetail_execute() ; since it's otherwise unused,
so remove that function entirely.
Thank you.
Thanks for reviewing. I'm also interested in discussio
> Marking the patch as either Ready for Committer or Waiting on Author
will help move things along.
Thanks for the heads-up, I've retested it again and it applies cleanly on
top of master and addresses the issue.
I've moved it to `Ready for Committer`.
--
Raúl Marín Rodríguez
carto.com
Hello, I have some other comments.
At Mon, 4 Mar 2019 23:27:10 +, "Bossart, Nathan"
wrote in <48410154-e6c5-4c07-8122-8d04e3bcd...@amazon.com>
> On 2/28/19, 12:13 AM, "Masahiko Sawada" wrote:
> > Attached the updated version patch. I've incorporated all review
> > comments I got and have ch
On 05.03.2019 6:45, Michael Paquier wrote:
On Fri, Mar 01, 2019 at 05:24:39AM +0300, Nikita Glukhov wrote:
Unfortunately, contrib/jsonb_plpython still contain a lot of problems in error
handling that can lead to memory leaks:
- not all Python function calls are checked for the success
- not
On Tue, Mar 5, 2019 at 11:35 AM Tom Lane wrote:
> True. I've spent some time today running the ssl tests on various
> machines here, without any luck reproducing.
BTW, I went looking for other failures on the buildfarm I noticed that
even for eelpout it's only happening on master and REL_11_STAB
I'm looking at the first patch in the series now. I'd suggest that you
commit that very soon. It's useful on its own, and seems pretty much
ready to be committed already. I don't think it will be much affected by
whatever changes we make to the later patches, anymore.
I did some copy-editing o
On 2/16/19 4:13 AM, Andres Freund wrote:
On 2019-02-09 20:12:53 +1300, Edmund Horner wrote:
I had a look at this. Your V2 patch applies cleanly, and the code was
straightforward and well commented. I appreciate the big comment at the
top of network_abbrev_convert explaining how you encode the
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I ran make checkworld and everything passed.
I tried installing
On 3/5/19 1:14 AM, Peter Geoghegan wrote:
> On Mon, Feb 25, 2019 at 8:48 AM Robert Haas wrote:
>> +1 for raising the default substantially. In my experience, and it
>> seems others are in a similar place, nobody ever gets into trouble
>> because the default is too high, but sometimes people get i
On 3/5/19 4:12 AM, Michael Paquier wrote:
> On Mon, Mar 04, 2019 at 03:08:09PM +0100, Tomas Vondra wrote:
>> I still don't understand what issue you see in how basebackup verifies
>> checksums. Can you point me to the explanation you've sent after 11 was
>> released?
>
> The history is mostly on t
On 05/03/2019 02:26, Andrey Borodin wrote:
I also tried your amcheck tool with this. It did not report any
errors.
Attached is also latest version of the patch itself. It is the
same as your latest patch v19, except for some tiny comment
kibitzing. I'll mark this as Ready for Committer in the c
Hi Fabien,
On Tue, 5 Mar 2019 07:09:01 +0100 (CET)
Fabien COELHO wrote:
> > Doc patch, against master. Documents encode() and decode() base64
> > format.
>
> It is already documented. Enhance documentation, though.
Right. I was thinking that there are various implementations
of the base64
On 3/5/19 11:48 AM, Iwata, Aya wrote:
So is it alright to add these information to the new/proposed PQtrace() default
output?
I agree with Andres [1] that it's not very clear where this patch is
going and we should push the target to PG13.
Regards,
--
-David
da...@pgmasters.net
[1]
htt
On 2/4/19 4:21 AM, Michael Paquier wrote:
On Wed, Jan 30, 2019 at 05:08:03PM +0100, Pavel Stehule wrote:
maybe "supertype". It is one char shorter .. somewhere is term
"supperclass, ..."
In Czech language this term is short, "nadtyp", but probably it is not
acceptable :)
Moved to next CF.
T
On Tue, 5 Mar 2019 07:26:17 -0600
"Karl O. Pinc" wrote:
> (I am not entirely pleased with the double dash
> but can't come up with anything better. And
> can't make an emdash entity work either.)
Attached: doc_base64_v3.patch
There is an mdash entity. This patch uses that.
Regards,
Karl
Fr
Hi,
(cc'ing -hackers and Peter E)
On Tue, Mar 5, 2019 at 8:02 PM PG Bug reporting form
wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 15668
> Logged by: Alexander Lakhin
> Email address: exclus...@gmail.com
> PostgreSQL version: Unsupported/Unk
út 5. 3. 2019 v 14:38 odesílatel David Steele napsal:
> On 2/4/19 4:21 AM, Michael Paquier wrote:
> > On Wed, Jan 30, 2019 at 05:08:03PM +0100, Pavel Stehule wrote:
> >> maybe "supertype". It is one char shorter .. somewhere is term
> >> "supperclass, ..."
> >>
> >> In Czech language this term is
Thomas Munro writes:
> BTW, I went looking for other failures on the buildfarm I noticed that
> even for eelpout it's only happening on master and REL_11_STABLE:
Yeah, I'd noticed that.
> Disappointingly, that turned out to be just because 10 and earlier
> didn't care what the error message said
David Steele writes:
> This thread has been very quiet for a month. I agree with Andres [1]
> that we should push this to PG13.
I think the main thing it's blocked on is disagreement on what the
type name should be, which is kind of a silly thing to get blocked on,
but nonetheless it's importan
David Steele writes:
> I'm not sure if I have an issue with competing patches on the same
> thread. I've seen that before and it can lead to a good outcome. It
> case, as you say, also lead to confusion.
It's a bit of a shame that the cfbot will only be testing one of them
at a time if we lea
Siarhei Siniak writes:
> 3. But utils/float.h required by cube.c and cubeparse.y is not installed.
AFAICT, that file only exists in HEAD, not in any released branch, and
it is installed during "make install" from HEAD. Please be sure you
are using installed files that match whatever branch you'r
On Sun, Mar 3, 2019 at 6:31 PM Thomas Munro wrote:
> A more obvious approach that probably moves us closer to the way
> kernel developers expect us to write programs is to call fsync()
> before close() (due to vfd pressure) if you've written.
Interesting
> The obvious
> problem with that is
> On Thu, Feb 28, 2019 at 10:45 PM Jeff Janes wrote:
>
> This version of the patch can return the wrong answer.
Yes, indeed. In fact it answers my previous question related to the backward
cursor scan, when while going back we didn't skip enough. Within the current
approach it can be fixed by pro
On Mon, Mar 4, 2019 at 1:01 AM Masahiko Sawada wrote:
> I think that there is no need to use the same key for both the spill
> files and WAL because only one process encrypt/decrypt spill files. We
> can use something like temporary key for that use case, which is used
> by only one process and li
On Tue, Mar 5, 2019 at 7:53 AM Tomas Vondra
wrote:
> But on the other hand it feels a bit weird that we increase this one
> value and leave all the other (also very conservative) defaults alone.
Are you talking about vacuum-related defaults or defaults in general?
In 2014, we increased the defaul
currently there is one process per connection and it will not not very good
for some short time connection.In oracle database, it support shared
server which can serve more than 1 users at the same time.
See
https://docs.oracle.com/cd/B28359_01/server.111/b28310/manproc001.htm#ADMIN11166
do
On 3/5/19 6:55 AM, David Rowley wrote:
> On Sat, 2 Feb 2019 at 02:52, Robert Haas wrote:
>> I think the key question here is whether or not you can cope with
>> someone having done arbitrary AEL-requiring modifications to the
>> delaylocked partitions. If you can, the fact that the plan might
On 3/5/19 5:24 AM, Amit Langote wrote:
Attached an updated version. This incorporates fixes for both Jesper's
and Imai-san's review. I haven't been able to pin down the bug (or
whatever) that makes throughput go down as the partition count increases,
when tested with a --enable-cassert build.
On Tue, Mar 5, 2019 at 3:00 AM Etsuro Fujita
wrote:
> apply_projection_to_path() not only jams the given tlist into the
> existing path but updates its tlist eval costs appropriately except for
> the cases of Gather and GatherMerge:
I had forgotten that detail, but I don't think it changes the ba
On Tue, Mar 5, 2019 at 3:56 AM Tatsuro Yamada
wrote:
> >> === Discussion points ===
> >>
> >>- Progress counter for "3. sorting tuples" phase
> >> - Should we add pgstat_progress_update_param() in tuplesort.c like a
> >> "trace_sort"?
> >> Thanks to Peter Geoghegan for th
On Wed, Mar 6, 2019 at 3:33 AM Tom Lane wrote:
> Thomas Munro writes:
> > Disappointingly, that turned out to be just because 10 and earlier
> > didn't care what the error message said.
>
> That is, you can reproduce the failure on old branches? That lets
> out a half-theory I'd had, which was t
On Wed, Mar 6, 2019 at 5:07 AM Shawn Debnath wrote:
> Confirmed. Patch shows 8900 ms vs 192 ms on master for the insert test.
> Interesting! It's reproducible so should be able to figure out what's
> going on. The only thing we do in ForwardSyncRequest() is split up the 8
> bits into 2x4 bits and
On Mon, Mar 4, 2019 at 6:27 PM Tomas Vondra
wrote:
> 11) Wording of some of the error messages in the execute methods seems a
> bit odd. For example executeNumericItemMethod may complain that it
>
> ... is applied to not a numeric value
>
> but perhaps a more natural wording would be
>
>
Thomas Munro writes:
> +#include "fmgr.h"
> +#include "storage/block.h"
> +#include "storage/relfilenode.h"
> +#include "storage/smgr.h"
> +#include "storage/sync.h"
> Why do we need to include fmgr.h in md.h?
More generally, any massive increase in an include file's inclusions
is probably a sig
>
>
> I agree with Andres and Robert. This patch should be pushed to PG13.
>
> I'll do that on March 8 unless there is a compelling argument not to.
>
>
No objection. I'll continue to work on it, though.
Thomas Munro writes:
> You can see that poll() already knew the other end had closed the
> socket. Since this is clearly timing... let's see, yeah, I can make
> it fail every time by adding sleep(1) before the comment "Send the
> startup packet.". I assume that'll work on any Linux machine?
Gre
On 2/28/19 4:27 PM, Alexander Kuzmenkov wrote:
On 2/18/19 03:20, Tom Lane wrote:
The dummy-relation stuff I referred to has now been merged, so there's
really no good reason not to revise the patch along that line.
I'll try to post the revised implementation soon.
I'll close this on March 8
út 5. 3. 2019 v 15:35 odesílatel Tom Lane napsal:
> David Steele writes:
> > This thread has been very quiet for a month. I agree with Andres [1]
> > that we should push this to PG13.
>
> I think the main thing it's blocked on is disagreement on what the
> type name should be, which is kind of
Peter Eisentraut wrote:
> Older ICU versions (<54) don't support all the locale customization
> options, so many of my new tests in collate.icu.utf8.sql will fail on
> older systems. What should we do about that? Have another extra test file?
Maybe stick to the old-style syntax for the
On 2019-03-04 22:08:04 -0800, Andres Freund wrote:
> Hi,
>
> On 2019-03-05 16:01:50 +1300, David Rowley wrote:
> > On Tue, 5 Mar 2019 at 12:47, Andres Freund wrote:
> > > CREATE TABLE tableam_parted_heap2 (a text, b int) PARTITION BY list (a)
> > > USING heap2;
> > >
> > > SET default_table_acce
On Wed, Mar 6, 2019 at 6:07 AM Tom Lane wrote:
> Thomas Munro writes:
> > You can see that poll() already knew the other end had closed the
> > socket. Since this is clearly timing... let's see, yeah, I can make
> > it fail every time by adding sleep(1) before the comment "Send the
> > startup p
On Wed, Dec 19, 2018 at 5:08 PM David Rowley
wrote:
> With my idea for using live_parts, we'll process the partitions
> looking for interleaved values on each query, after pruning takes
> place. In this case, we'll see the partitions are naturally ordered. I
> don't really foresee any issues with
On Tue, Mar 5, 2019 at 12:59 PM Andres Freund wrote:
> Based on this mail I'm currently planning to simply forbid specifying
> USING for partitioned tables. Then we can argue about this later.
+1. I actually think that might be the right thing in the long-term,
but it undeniably avoids committin
We don't currently have any buildfarm animals running 32 bit mingw
builds for releases > 10. As part of my testing of msys 2 I thought I
would try its 32 bit compiler and got this regression diff on HEAD
cheers
andrew
diff -w -U3
C:/tools/msys64/home/Administrator/bf/root/HEAD/pgsql/src/tes
On 3/5/19, 1:22 AM, "Masahiko Sawada" wrote:
> On Tue, Mar 5, 2019 at 8:27 AM Bossart, Nathan wrote:
>> + VACUUM removes dead tuples and prunes HOT-updated
>> + tuples chain for live tuples on table. If the table has any dead tuple
>> + it removes them from both table and indexes f
On Wed, Mar 6, 2019 at 7:05 AM Thomas Munro wrote:
> On Wed, Mar 6, 2019 at 6:07 AM Tom Lane wrote:
> > Annoying. I'd be happier about writing code to fix this if I could
> > reproduce it :-(
>
> Hmm. Note that eelpout only started doing it with OpenSSL 1.1.1.
Bleugh. I think this OpenSSL pac
There already are solutions regarding this feature in Postgres
using "connection pooler" wording
see
pgpool: http://www.pgpool.net/mediawiki/index.php/Main_Page
pgbouncer: https://pgbouncer.github.io/
there are also discussions to include this as a core feature
https://www.postgresql.org/mes
Hello, David!
> I've made a pass over v10. I think it's in pretty good shape, but I
> did end up changing a few small things.
Thank you! I merged your changes to new patch version.
> The only thing that I'm a bit unsure of is the tests. I've read the
> thread and I see the discussion above about
> On Mar 4, 2019, at 4:22 PM, Tom Lane wrote:
>
> Paul Ramsey writes:
>>> On Mar 4, 2019, at 2:52 PM, Tom Lane wrote:
>>> BTW, if you'd like me to review the code you added for this, I'd be happy
>>> to do so. I've never looked at PostGIS' innards, but probably I can make
>>> sense of the c
On Tue, Mar 5, 2019 at 3:37 AM Heikki Linnakangas wrote:
> I'm looking at the first patch in the series now. I'd suggest that you
> commit that very soon. It's useful on its own, and seems pretty much
> ready to be committed already. I don't think it will be much affected by
> whatever changes we
Thomas Munro writes:
> Bleugh. I think this OpenSSL package might just be buggy on ARM. On
> x86, apparently the same version of OpenSSL and all other details of
> the test the same, I can see that SSL_connect() returns <= 0
> (failure), and then we ask for that cert revoked message directly and
-- Forwarded message -
From: Siarhei Siniak
Date: Tue, 5 Mar 2019 at 23:31
Subject: Re: [Issue] Can't recompile cube extension as PGXS, utils/float.h
is not installed
To: Tom Lane
>AFAICT, that file only exists in HEAD, not in any released branch, and
>it is installed during "ma
On Tue, Mar 5, 2019 at 12:24:14AM -0300, Alvaro Herrera wrote:
> On 2019-Mar-04, Bruce Momjian wrote:
>
> > On Thu, Feb 28, 2019 at 10:28:44AM +0300, Sergei Kornilov wrote:
> > > Hello
> > >
> > > postgresql.conf.sample was changed recently in REL_10_STABLE (commit
> > > ab1d9f066aee4f9b81abde6
On Thu, Feb 28, 2019 at 3:27 PM Robert Haas wrote:
> I'm not currently aware of any remaining correctness issues with this
> code, although certainly there may be some. There has been a certain
> dearth of volunteers to review any of this. I do plan to poke at it a
> bit to see whether it has an
Hello Karl,
Attached: doc_base64_v3.patch
I'm ok with referencing the historical MIME RFC.
"RFC2045 section 6.8" -> "RFC 2045 Section 6.8"
you can link to the RFC directly with:
https://tools.ietf.org/html/rfc2045#section-6.8";>RFC 2045
Section 6.8
--
Fabien.
On Wed, Mar 6, 2019 at 9:21 AM Tom Lane wrote:
> The bug #15598 report is more troublesome, as we don't have a strong
> reason to believe it's not common on Windows. However, I wonder whether
> we can really do anything at all about that one. If I understand what
> Andrew was hypothesizing in th
On 2/25/19 8:38 AM, David Rowley wrote:
> On Tue, 26 Feb 2019 at 02:06, Joe Conway wrote:
>> On 2/25/19 1:17 AM, Peter Geoghegan wrote:
>>> On Sun, Feb 24, 2019 at 9:42 PM David Rowley
>>> wrote:
The current default vacuum_cost_limit of 200 seems to be 15 years old
and was added in f4
On 2019-03-05 17:14:55 -0500, Andrew Dunstan wrote:
> This patch is tiny, seems perfectly reasonable, and has plenty of
> support. I'm going to commit it shortly unless there are last minute
> objections.
+1
On 2/6/19 2:32 AM, Pavan Deolasee wrote:
> Hello,
>
> Currently either the table level option `toast_tuple_target` or the
> compile time default `TOAST_TUPLE_TARGET` is used to decide whether a
> new tuple should be compressed or not. While this works reasonably
> well for most situations, at tim
On 3/4/19 7:42 AM, Christoph Berg wrote:
> Re: Andrew Dunstan 2019-03-04
> <7cc6d2c1-bd87-9890-259d-36739c247...@2ndquadrant.com>
>> Looks good to me.
> +1.
>
OK, I think we have agreement on Tom's patch. Do we want to backpatch
it? It's a change in behaviour, but I find it hard to believe any
Alvaro,
Thanks again for your review. I went through your proposed patch diffs and
applied most of them to my original changes. I did a few things slightly
differently since I wanted to keep to to 80 columns for the source code,
but I can revisit that if it is not an issue. I also cleaned up the
c
Thanks for chipping in on this.
On Wed, 6 Mar 2019 at 01:53, Tomas Vondra wrote:
> But on the other hand it feels a bit weird that we increase this one
> value and leave all the other (also very conservative) defaults alone.
Which others did you have in mind? Like work_mem, shared_buffers? If
s
On Wed, 6 Mar 2019 at 08:41, Sergei Kornilov wrote:
> In this case we need extra argument for ConstraintImpliedByRelConstraint for
> some caller-provided existConstraint, right? Along with Relation itself? Then
> I need make copy of existConstraint, append relation constraints and call
> predic
On Wed, 6 Mar 2019 at 03:37, Tom Lane wrote:
>
> David Steele writes:
> > I'm not sure if I have an issue with competing patches on the same
> > thread. I've seen that before and it can lead to a good outcome. It
> > case, as you say, also lead to confusion.
>
> It's a bit of a shame that the c
Paul Ramsey writes:
> Thanks for the patch, I’ve applied and smoothed and taken your advice on
> schema-qualified lookups as well.
Hm, I think your addition of this bit is wrong:
+/*
+* Arguments were swapped to put the index value on the
+
> On Mar 5, 2019, at 3:26 PM, Tom Lane wrote:
>
> Paul Ramsey writes:
>> Thanks for the patch, I’ve applied and smoothed and taken your advice on
>> schema-qualified lookups as well.
>
> Hm, I think your addition of this bit is wrong:
>
> +/*
> +* Arg
Way back in [1] I proposed that we allow NOT IN subqueries to be
converted into an anti-join where the subquery cannot return any NULL
values. As Tom pointed out to me, I had neglected to consider that
the outer side producing NULLs can cause the anti-join plan to produce
incorrect results. The
Paul Ramsey writes:
> On Mar 5, 2019, at 3:26 PM, Tom Lane wrote:
>> Hm, I think your addition of this bit is wrong:
>>
>> +/*
>> +* Arguments were swapped to put the index value on the
>> +* left, so we need the commutated operator for
On Wed, 6 Mar 2019 at 12:25, David Rowley wrote:
> That sounds fine. I'll take mine elsewhere since I didn't start this thread.
Moved to
https://www.postgresql.org/message-id/CAKJS1f82pqjqe3WT9_xREmXyG20aOkHc-XqkKZG_yMA7JVJ3Tw%40mail.gmail.com
--
David Rowley http://www.2ndQ
On Tue, Mar 5, 2019 at 3:46 AM David Steele wrote:
> I have marked this entry as targeting PG13 since it is too late to
> consider for PG12.
Sounds right. As Peter said himself, this patch is WIP, so it's too
soon to consider integrating it. This is also fairly evident from the
content of the p
On Wed, 6 Mar 2019 at 07:17, Robert Haas wrote:
>
> On Wed, Dec 19, 2018 at 5:08 PM David Rowley
> wrote:
> > With my idea for using live_parts, we'll process the partitions
> > looking for interleaved values on each query, after pruning takes
> > place. In this case, we'll see the partitions are
Here is Pavel's patch rebased to master branch, added the dropdb
--force option, a test case & documentation.
I'm willing to work on it if needed. What are possible bad things that
could happen here? Is the documentation clear enough?
Thanks.
On Tue, Dec 18, 2018 at 4:34 PM Marti Raudsepp wrot
1 - 100 of 155 matches
Mail list logo
