Hello Tom,
I took a look at this. I have no quibble with the proposed feature,
and the implementation is certainly simple enough. But I'm unconvinced
about the proposed test scaffolding. Spinning up a new PG instance is a
*hell* of a lot of overhead to pay for testing something that could b
On Wed, Jul 03, 2019 at 10:41:59AM +0800, Rui Hai Jiang wrote:
> Could the attached patch fix this issue? Or does any one else plan to fix
> it?
>
> If people are busy and have not time, I can go ahead to fix it. To fix
> this issue, do we need a patch for each official branch?
Only a committer
On Tue, Jul 2, 2019 at 5:12 PM Tom Lane wrote:
> Oleksandr Shulgin writes:
> > Not related to the diff v6..v7, but shouldn't we throw additionally a
> > memset() with '\0' before calling pfree():
>
> I don't see the point of that. In debug builds CLOBBER_FREED_MEMORY will
> take care of it, and
On Wed, 3 Jul 2019 at 17:27, Amit Langote wrote:
> A cursory look at the patch suggests that most of its changes will be
> for nothing if [1] materializes. What do you think about that?
Yeah, I had this in mind when writing the patch, but kept going
anyway. I think it's only really a small patc
On Tue, Jul 02, 2019 at 01:26:26AM +1200, David Rowley wrote:
> I've pushed the original patch plus a small change to only call
> table_finish_bulk_insert() for the target of the copy when we're using
> bulk inserts.
Yes, sorry for coming late at the party here. What I meant previously
is that I
On Wed, 3 Jul 2019 at 19:35, Michael Paquier wrote:
>
> On Tue, Jul 02, 2019 at 01:26:26AM +1200, David Rowley wrote:
> > I've pushed the original patch plus a small change to only call
> > table_finish_bulk_insert() for the target of the copy when we're using
> > bulk inserts.
>
> Yes, sorry for
Hosoya-san,
Thanks for updating the patches.
I have no comment in particular about
v4_default_partition_pruning.patch, but let me reiterate my position
about v5_ignore_contradictory_where_clauses_at_partprune_step.patch,
which I first stated in the following email a few months ago:
https://www.p
On 2019-07-01 19:38, Surafel Temesgen wrote:
Thank you for informing. attach is a rebased patch against current
master
[...]
[fetch_first_with_ties_v10.patch]
Hi Surafel,
The patch applies OK, make check is OK, compiles OK.
But I get:
TRAP: FailedAssertion("!(!(((slot)->tts_flags & (1 << 1)
Dear Mr. Thomas
> The July Commitfest is now beginning. To give the patch the best chance of
> attracting reviewers, could you please post a rebased version? The last
> version
> doesn't apply.
I really appreciate your comments.
Recently, I'm very busy because of my work.
So, I'll fix this wit
On Wed, Jul 3, 2019 at 4:34 PM David Rowley
wrote:
> On Wed, 3 Jul 2019 at 17:27, Amit Langote wrote:
> > A cursory look at the patch suggests that most of its changes will be
> > for nothing if [1] materializes. What do you think about that?
>
> Yeah, I had this in mind when writing the patch,
On Wed, 3 Jul 2019 at 10:01, Michael Paquier wrote:
> On Tue, Jul 02, 2019 at 02:10:11PM +0900, Michael Paquier wrote:
> > OK, committed to HEAD for now after perltidy'ing the patch. Let's see
> > what the buildfarm has to say about it first. Once we are sure that
> > the thing is stable, I'll
> On 2 Jul 2019, at 09:49, Michael Paquier wrote:
> On Tue, Jul 02, 2019 at 08:14:25AM +0100, Peter Eisentraut wrote:
>>
>> I was wondering whether the provided binary blob contained any checksums
>> or other internal checks. How would we know whether it contains
>> transposed characters or rep
On Fri, Jun 28, 2019 at 7:15 PM Etsuro Fujita wrote:
> On Fri, Jun 28, 2019 at 6:54 PM Julien Rouhaud wrote:
> > On Fri, Jun 28, 2019 at 11:39 AM Etsuro Fujita
> > wrote:
> > > In postgresAcquireSampleRowsFunc, we 1) determine the fetch size and
> > > then 2) construct the fetch command in each
В письме от понедельник, 1 июля 2019 г. 21:25:30 MSK пользователь Thomas Munro
написал:
> > It's not clear to me that all of Michael's and Álvaro's issues have been
> > addressed, so I've marked this Waiting on Author.
> To help reviewers for the Commitfest that is starting, could you
> please re
В письме от понедельник, 1 июля 2019 г. 14:06:28 MSK пользователь Alvaro
Herrera написал:
> It strikes me that the way to avoid sentence construction is to have
> each enum reloption declare a string that it uses to list the values it
> accepts. So for example we would have
>
> +#define GIST_OPT
On 7/1/19 12:55 PM, Jamison, Kirk wrote:
> On Wednesday, June 26, 2019 6:10 PM(GMT+9), Adrien Nayrat wrote:
>> As far as I remember, you should see "relation" wait events (type lock) on
>> standby server. This is due to startup process acquiring AccessExclusiveLock
>> for the truncation and other b
Thanks Amit for the fix patch,
I have applied the patch and verified the issue.
The attached partition with altered column properties shows error as below:
postgres=# alter table p attach partition p2 for values in (2);
psql: ERROR: child table "p2" has different storage option for column "b"
tha
On Wed, Jul 03, 2019 at 10:56:41AM +0200, Daniel Gustafsson wrote:
> OpenSSL provides DH_check() which we use in load_dh_file() to ensure that the
> user is passing a valid prime in the DH file. Adding this to the hardcoded
> blob seems overkill though, once the validity has been verified before i
Hi Erik,
Thank you for looking at it.
Can you have a look?
>
>
It is because of the patch didn't handle that edge case.
attache patch contain a fix for it
regards
Surafel
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 06d611b64c..e83d309c5b 100644
--- a/doc/src/sg
Hi Alexey,
Thank you for looking at it
On Tue, Jul 2, 2019 at 7:57 PM Alexey Kondratov
wrote:
> On 28.06.2019 16:12, Alvaro Herrera wrote:
> >> On Wed, Feb 20, 2019 at 7:04 PM Andres Freund
> wrote:
> >>> Or even just return it as a row. CopyBoth is relatively widely
> supported
> >>> these day
On Wed, Jul 3, 2019 at 5:35 AM Tom Lane wrote:
>
> John Naylor writes:
> > 0001 is a small patch to remove some unneeded generality from the
> > current rules. This lowers the number of elements in the yy_transition
> > array from 37045 to 36201.
>
> I don't particularly like 0001. The two bits
Hi Everyone,
I have installed PostgresSQL 11.2 version on Centos 7 and try to install
*pguint* from source to install *TINYINT* datatype .
But installation had problem not able to resolve dependency packages. I
have followed below method to install , please help me to resolve this
issue.
1. yum
Hi,
I'm very interested in this patch and would like to give a review within a
week. On the feature side, how about simply using the less verbose "ERRORS"
instead of "ERROR LIMIT" ?
On Wed, Jul 3, 2019 at 1:42 PM Surafel Temesgen
wrote:
> Hi Alexey,
> Thank you for looking at it
>
> On Tue, Jul
On Tue, Jul 2, 2019 at 11:23 AM Tom Lane wrote:
> Rui Hai Jiang writes:
> > I think I found an issue in the TopoSort() function.
>
> This indeed seems like a live bug introduced by a1c1af2a.
> Robert?
This is pretty thoroughly swapped out of my head, but it looks like
that analysis might be corr
Amit Langote writes:
> On Wed, Feb 20, 2019 at 6:49 AM Tom Lane wrote:
>> Obviously this'd be a major rewrite with no chance of making it into v12,
>> but it doesn't sound too big to get done during v13.
> Are you planning to work on this?
It's on my list, but so are a lot of other things. If
Michael Paquier writes:
> I have been reviewing that part, and the part to split the bootstrap
> user from the set of extra roles created looks fine to me. Now, it
> seems to me that you can simplify 010_dump_connstr.pl as per the
> attached because PostgresNode::Init can take care of --auth-conf
Fabien COELHO writes:
> The point is that there would be at least *one* TAP tests so that many
> other features of psql, although not all, can be tested. I have been
> reviewing quite a few patches without tests because of this lack of
> infrastructure, and no one patch is ever going to justify
On 6/28/19 6:47 AM, Alexander Korotkov wrote:
On Tue, Jun 25, 2019 at 6:38 PM Liudmila Mantrova
wrote:
Thank you for the catch! Please see the modified version of patch 0004
attached.
I tried to review and revise the part related to filters, but I failed
because I don't understand the notions
Hello Tom,
The point is that there would be at least *one* TAP tests so that many
other features of psql, although not all, can be tested. [...]
Yeah, but the point I was trying to make is that that's mostly down to
laziness.
Not always.
I agree that using TAP test if another simpler opti
On Mon, Jul 1, 2019 at 7:32 PM Andres Freund wrote:
> On 2019-06-29 22:15:19 +0200, Tomas Vondra wrote:
> > I think we should consider changing the effective_io_concurrency default
> > value, i.e. the guc that determines how many pages we try to prefetch in
> > a couple of places (the most importa
On Tue, Jul 2, 2019 at 7:16 PM Julien Rouhaud wrote:
>
> On Fri, Apr 26, 2019 at 5:38 AM Michael Paquier wrote:
> >
> > On Thu, Apr 25, 2019 at 03:08:36PM -0400, Alvaro Herrera wrote:
> > > On 2019-Apr-26, Fujii Masao wrote:
> > >> I did that arrangement because the format of PREPARE TRANSACTION
On Wed, Jul 03, 2019 at 11:04:59AM -0400, Robert Haas wrote:
On Mon, Jul 1, 2019 at 7:32 PM Andres Freund wrote:
On 2019-06-29 22:15:19 +0200, Tomas Vondra wrote:
> I think we should consider changing the effective_io_concurrency default
> value, i.e. the guc that determines how many pages we t
On Wed, Jul 3, 2019 at 11:24 AM Tomas Vondra
wrote:
> Maybe. And it would probably work for the systems I used for benchmarks.
>
> It however assumes two things: (a) the storage system actually has
> spindles and (b) you know how many spindles there are. Which is becoming
> less and less safe thes
Daniel Gustafsson writes:
>> On 2 Jul 2019, at 22:35, Alvaro Herrera wrote:
>> Anyway I'm not objecting to the patch -- I agree that we're already not
>> testing translatability and that this patch shouldn't be forced to start
>> doing it.
> I forgot to add that to my previous email, the patch a
Paul Ramsey 于2019年7月2日周二 下午10:46写道：
> This looks good to me. A little commentary around why
> pglz_maximum_compressed_size() returns a universally correct answer
> (there's no way the compressed size can ever be larger than this
> because...) would be nice for peasants like myself.
>
> If you're
Alvaro Herrera wrote:
> So you suggest that it should be
>
> pg_restore: error: one of -d/--dbname, -f/--file and -l/--list must be
> specified
> ?
I'd suggest this minimal fix :
(int argc, char **argv)
/* Complain if neither -f nor -d was specified (except if dumping
TOC) */
Hi Thomas and David,
Thanks for the feedback !
On 7/2/19 8:27 AM, David Rowley wrote:
On Tue, 2 Jul 2019 at 21:00, Thomas Munro wrote:
I took this for a quick spin today. The DISTINCT ON support is nice
and I think it will be very useful. I've signed up to review it and
will have more to sa
David Rowley writes:
> I've now read over the entire patch and have noted down the following:
Thanks for the review! Attached is a v8 responding to most of your
comments. Anything not quoted below I just accepted.
> 1. MergeAttributes() could do with a comment mention why you're not
> using fo
On Wed, Jul 3, 2019 at 5:21 PM Fujii Masao wrote:
>
> On Tue, Jul 2, 2019 at 7:16 PM Julien Rouhaud wrote:
> >
> > On Fri, Apr 26, 2019 at 5:38 AM Michael Paquier wrote:
> > >
> > > On Thu, Apr 25, 2019 at 03:08:36PM -0400, Alvaro Herrera wrote:
> > > > On 2019-Apr-26, Fujii Masao wrote:
> > > >
On 2019-Jul-03, Tom Lane wrote:
> David Rowley writes:
> > 10. I wonder if we can reduce a bit of pain for extension authors by
> > back patching a macro that wraps up a lnext() call adding a dummy
> > argument for the List.
>
> I was wondering about a variant of that yesterday; specifically,
>
> On 3 Jul 2019, at 12:11, Michael Paquier wrote:
> It would be nice to add a comment on that though, perhaps in
> libpq-be.h where the key is defined.
Agreed, I’ve updated the patch with a comment on this formulated such that it
should stand the test of time even as OpenSSL changes etc.
cheers
David Rowley writes:
> I also did some more benchmarking of the patch. ...
> Which makes the patched version 2.2% faster than master on that run.
BTW, further on the subject of performance --- I'm aware of at least
these topics for follow-on patches:
* Fix places that are maintaining arrays para
On Wed, Jul 03, 2019 at 12:27:09AM +1200, David Rowley wrote:
> On Tue, 2 Jul 2019 at 21:00, Thomas Munro wrote:
>
> The more I think about these UniqueKeys, the more I think they need to
> be a separate concept to PathKeys. For example, UniqueKeys: { x, y }
> should be equivalent to { y, x }, bu
Hi,
Currently there's 0 coverage of CustomScan code path in core.
What about adding a noops custom_scan test in src/test/modules/ ? Or
is it out of pg perimeter and each extension using it should take are
of themselves?
If there's an interest I'm willing to write and propose such test suite.
R
On 2019-Jul-03, didier wrote:
> Currently there's 0 coverage of CustomScan code path in core.
Yeah :-(
> What about adding a noops custom_scan test in src/test/modules/ ? Or
> is it out of pg perimeter and each extension using it should take are
> of themselves?
>
> If there's an interest I'm
Hi!
On Wed, Jul 3, 2019 at 5:27 PM Liudmila Mantrova
wrote:
>
> I have rechecked the standard and I agree that we should use "filter
> expression" whenever possible.
> "A filter expression must be enclosed in parentheses..." looks like an
> oversight, so I fixed it. As for what's actually enclose
On Wed, Jul 3, 2019 at 3:46 PM David Fetter wrote:
>
> On Wed, Jul 03, 2019 at 12:27:09AM +1200, David Rowley wrote:
> > On Tue, 2 Jul 2019 at 21:00, Thomas Munro wrote:
> >
> > The more I think about these UniqueKeys, the more I think they need to
> > be a separate concept to PathKeys. For examp
On 2019-Jul-03, Nikolay Shaplov wrote:
> В письме от понедельник, 1 июля 2019 г. 14:06:28 MSK пользователь Alvaro
> Herrera написал:
> > + GistBufferingValidMsg = gettext_noop("Valid values are \"on\", \"off\",
> > and \"auto\".");
> >
> > I think that's the most contentious point on this patch
On Tue, Jun 18, 2019 at 3:24 PM Melanie Plageman
wrote:
>
> These questions will probably make a lot more sense with corresponding
> code, so I will follow up with the second version of the state machine
> patch once I finish it.
>
>
I have changed the state machine and resolved the questions I h
On Thu, 4 Jul 2019 at 09:02, James Coleman wrote:
>
> On Wed, Jul 3, 2019 at 3:46 PM David Fetter wrote:
> >
> > On Wed, Jul 03, 2019 at 12:27:09AM +1200, David Rowley wrote:
> > > On Tue, 2 Jul 2019 at 21:00, Thomas Munro wrote:
> > >
> > > The more I think about these UniqueKeys, the more I th
On Thu, 4 Jul 2019 at 06:15, Tom Lane wrote:
>
> David Rowley writes:
> > I've now read over the entire patch and have noted down the following:
>
> Thanks for the review! Attached is a v8 responding to most of your
> comments. Anything not quoted below I just accepted.
Thanks for the speedy t
Observe the following buildfarm failures:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2019-07-03%2013%3A33%3A59
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory&dt=2019-04-30%2014%3A45%3A26
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory&dt=2019-06
On Thu, Jul 04, 2019 at 10:06:11AM +1200, David Rowley wrote:
> On Thu, 4 Jul 2019 at 09:02, James Coleman wrote:
> > I think that example is the opposite direction of what David (Rowley)
> > is saying. Unique on {a, b} implies unique on {a, b, c} while you're
> > correct that the inverse doesn't
On Wed, Jul 03, 2019 at 08:56:42PM +0200, Daniel Gustafsson wrote:
> Agreed, I’ve updated the patch with a comment on this formulated such that it
> should stand the test of time even as OpenSSL changes etc.
I'd like to think that we had rather mention the warning issue
explicitely, so as people d
On Mon, 2019-07-01 at 12:13 -0700, Jeff Davis wrote:
> This is for design review. I have a patch (WIP) for Approach 1, and
> if
> this discussion starts to converge on that approach I will polish and
> post it.
WIP patch attached (based on 9a81c9fa); targeting September CF.
Not intended for detai
On Thu, Apr 4, 2019 at 8:15 AM Heikki Linnakangas wrote:
> I think we should fix this in a similar manner in B-tree, too, but that
> can be done separately. For B-tree, we need to worry about
> backwards-compatibility, but that seems simple enough; we just need to
> continue to understand old dele
On Sun, 26 May 2019 at 04:50, Tom Lane wrote:
>
> David Rowley writes:
> > Here's a small patch series aimed to both clean up a few misuses of
> > string functions and also to optimise a few things along the way.
>
> > 0001: Converts various call that use appendPQExpBuffer() that really
> > shoul
On Wed, 2019-07-03 at 02:17 +0200, Tomas Vondra wrote:
> What does "partitioned hash strategy" do? It's probably explained in
> one
> of the historical discussions, but I'm not sure which one. I assume
> it
> simply hashes the group keys and uses that to partition the data, and
> then
> passing it
On Wed, Jul 03, 2019 at 09:53:14AM -0400, Tom Lane wrote:
> I haven't checked that this actually works, but it looks plausible,
> and I agree it's simpler/easier.
Thanks, committed. While testing on Windows, I have been trapped by
the fact that IPC::Run mishandles double quotes, causing the tests
I'll try to figure out some scenarios to do the test. A parallel process
group is needed for the test.
Actually I was trying to do some testing against the locking mechanism. I
happened to see this issue.
On Wed, Jul 3, 2019 at 9:38 PM Robert Haas wrote:
> On Tue, Jul 2, 2019 at 11:23 AM Tom L
On Mon, 1 Jul 2019 at 23:29, Thomas Munro wrote:
> The new CF is here. I'm going through poking threads for submissions
> that don't apply, but it sounds like this needs more than a rebase?
> Perhaps this belongs in the next CF?
0001 and 0004 of v7 got pushed in PG12. The CFbot will be trying to
Hi, Amit
> If I understand the details of [1] correctly, ModifyTable will no longer
> have N subplans for N result relations as there are today. So, it doesn't
> make sense for ModifyTable to contain PartitionedRelPruneInfos and for
> ExecInitModifyTable/ExecModifyTable
> to have to perform initi
> "Tom" == Tom Lane writes:
Tom> I'm dubious that relying on zone[1970].tab would improve matters
Tom> substantially; it would fix some cases, but I don't think it would
Tom> fix all of them. Resolving all ambiguous zone-name choices is not
Tom> the charter of those files.
Allowing zone
> On 04 Jul 2019, at 02:58, Michael Paquier wrote:
>
>> On Wed, Jul 03, 2019 at 08:56:42PM +0200, Daniel Gustafsson wrote:
>> Agreed, I’ve updated the patch with a comment on this formulated such that it
>> should stand the test of time even as OpenSSL changes etc.
>
> I'd like to think that
64 matches
Mail list logo
