On Fri, Mar 1, 2019 at 12:01 AM Antonin Houska wrote:
> Tom Lane wrote:
>
> > Antonin Houska writes:
> > > Michael Paquier wrote:
> > >> Latest patch set fails to apply, so moved to next CF, waiting on
> > >> author.
> >
> > > Rebased.
> >
> > This is in need of rebasing again :-(. I went
On Tue, 2 Jul 2019 at 11:27, Tom Lane wrote:
> My previous patch would have had you replace this with a loop using
> an integer list-position index. You can still do that if you like,
> but it's less change to convert the loop to a foreach(), drop the
> prev/next variables, and replace the
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 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
On Sun, Jun 30, 2019 at 12:09:18PM -0400, Tom Lane wrote:
> We could apply the same hack on the source node, but I wonder if it
> wouldn't be better to make this less of a kluge. I'm tempted to
> propose that "pg_regress --config-auth --user XXX" should understand
> XXX as the bootstrap superuser
В письме от понедельник, 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
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
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 <<
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"
В письме от понедельник, 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
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
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
---
On Tue, Jul 2, 2019 at 1:47 PM amul sul wrote:
> Attached version is rebase atop of the latest master head(c74d49d41c), thanks.
Thanks! Will review.
Best regards,
Etsuro Fujita
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:
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
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
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 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
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
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
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,
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
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,
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
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.
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
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
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
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
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
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
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
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
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
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
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
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) */
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.
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
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
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 },
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
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
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.
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
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
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
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
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
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
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
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 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 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
> >
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
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
Observe the following buildfarm failures:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela=2019-07-03%2013%3A33%3A59
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory=2019-04-30%2014%3A45%3A26
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
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
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
> "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
66 matches
Mail list logo
