Thank you so much for your comments!! I'll answer a bit later because
now I'm trying to find a test for int128 on Solaris 10.. [1]
On 17-01-2018 1:05, Tom Lane wrote:
[ I'm sending this comment separately because I think it's an issue
Andres might take an interest in. ]
Marina Polyakova write
On Tue, Jan 16, 2018 at 08:50:24AM -0800, Andres Freund wrote:
> On 2018-01-16 16:12:11 +0900, Michael Paquier wrote:
> > On Fri, Feb 03, 2017 at 12:26:50AM +, Noah Misch wrote:
> > > Since this emits double syncs with older xlc, I recommend instead
> > > replacing
> > > the whole thing with i
Hi!
> 16 янв. 2018 г., в 21:50, Anastasia Lubennikova
> написал(а):
>
> Updated patches are attached.
>
Cool, thanks!
I've looked into the code, but haven't found anything broken.
Since I've tried to rebase patch myself and failed on parse utils, I've spend
some cycles trying to break parsing
(2018/01/16 12:00), Etsuro Fujita wrote:
(2018/01/16 11:17), Tom Lane wrote:
Etsuro Fujita writes:
(2018/01/16 1:47), Robert Haas wrote:
Hmm, I was thinking that bar and baz wouldn't be constrained to return
just one tuple in that case, but I'm wrong: there would just be one
tuple per relation
On 17 January 2018 at 17:05, David Rowley wrote:
> 6. Which brings me to; why do we need match_clauses_to_partkey at all?
> classify_partition_bounding_keys seems to do all the work
> match_clauses_to_partkey does, plus more. Item #3 above is caused by
> an inconsistency between these functions. W
(2018/01/16 6:38), Tom Lane wrote:
Robert Haas writes:
On Mon, Jan 15, 2018 at 12:31 PM, Tom Lane wrote:
Hm. Simple is certainly good, but if there's multiple rows coming
back during an EPQ recheck then I think we have a performance problem.
You are correct ... I was wrong about that part
Hi David.
On Wed, Jan 17, 2018 at 6:19 PM, David Rowley
wrote:
> On 17 January 2018 at 17:05, David Rowley
> wrote:
>> 6. Which brings me to; why do we need match_clauses_to_partkey at all?
>> classify_partition_bounding_keys seems to do all the work
>> match_clauses_to_partkey does, plus more.
On 17 January 2018 at 23:48, Amit Langote wrote:
> I'm concerned that after your patch to remove
> match_clauses_to_partkey(), we'd be doing more work than necessary in
> some cases. For example, consider the case of using run-time pruning
> for nested loop where the inner relation is a partition
Am Dienstag, den 16.01.2018, 08:25 + schrieb REIX, Tony:
> I've been able to compare PostgreSQL compiled with XLC vs GCC 7.1
> and, using times outputs provided by PostgreSQL tests, XLC seems to
> provide at least 8% more speed. We also plan to run professional
> performance tests in order to c
While reading XLogPageRead() I was surprised that readLen variable is set but
not used in the read() call. Then I realized that it's declared static
although no other function uses it. Maybe it was used earlier to exit early if
sufficient amount of data was already read? I think this case is now ha
On 16 January 2018 at 17:20, Robert Haas wrote:
> (1) I doubt that we want to
> override the user's terminal settings and (2) it won't work on
> non-readline builds.
I'm inclined to agree with (1). (2) is something that could be worked
around with (relatively) small effort, and in theory we could
Michael, Andres,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Oct 27, 2017 at 3:13 AM, Michael Paquier
> wrote:
> > On Thu, Oct 26, 2017 at 3:05 AM, Kyotaro HORIGUCHI
> > wrote:
> >> The largest obstacle to do that is that walreceiver is not
> >> utterly concerned to record int
Greetings Etsuro, Robert, all,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> (2017/11/01 11:16), Robert Haas wrote:
> >On Wed, Oct 4, 2017 at 5:58 PM, Ashutosh Bapat
> > wrote:
> >>The view with WCO is local but the modification which violates WCO is
> >>being made on remote server by a
Hello,
What are the cons of setting BLCKSZ as 4kB? When saw the results
published on [...].
There were other posts and publications which points to the same direction
consistently.
This matches my deep belief is that postgres default block size is a
reasonable compromise for HDD, but is l
On Tue, Jan 16, 2018 at 6:24 AM, Peter Geoghegan wrote:
> On Fri, Jan 12, 2018 at 10:28 AM, Robert Haas wrote:
>> More comments:
>
> Attached patch has all open issues worked through, including those
> that I respond to or comment on below, as well as the other feedback
> from your previous e-mai
On Tue, Jan 16, 2018 at 6:08 PM, David Rowley
wrote:
> On 17 January 2018 at 03:58, Alvaro Herrera wrote:
>>> 9. Error details claim that p2_a_idx is not a partition of p.
>>> Shouldn't it say table "p2" is not a partition of "p"?
>>
>> You missed the "on" in the DETAIL:
>> DETAIL: Index "p2_a
I'm setting this patch to Returned with feedback.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 17 October 2017 at 14:16, Robert Haas wrote:
> On Sat, Oct 14, 2017 at 2:14 PM, Tomas Vondra
> wrote:
>> I propose is to add a new cursor option (PARALLEL), which would allow
>> parallel plans for that particular user-defined cursor. Attached is an
>> experimental patch doing this (I'm sure th
On 2 November 2017 at 01:55, Robert Haas wrote:
> On Wed, Nov 1, 2017 at 7:49 AM, Craig Ringer wrote:
>> If the client wants to fetch in chunks it can use a portal and limited
>> size fetches. That shouldn't (?) be parallel-unsafe, since nothing
>> else can happen in the middle anyway.
>
> I beli
On 1/3/18 10:25, Robert Haas wrote:
> On Tue, Jan 2, 2018 at 9:20 PM, Craig Ringer wrote:
>> Last time I tried to actually deploy packages that used --with-extra-version
>> a variety of tools that talk to postgres broke because they choked when
>> parsing the version. Including widely used ones li
Graham, will you be able to respond to my questions or provide an
updated patch within the next week or so?
On 1/2/18 09:17, Peter Eisentraut wrote:
> The server-side changes look pretty reasonable.
>
> On the client side, I'd like to see some comments explaining the
> business around ssl_ex_dat
Re: Peter Eisentraut 2018-01-17
> So what is the next action this thread? I think --with-extra-version is
> the right solution for packagers, so I'm tempted to close this commit
> fest item. There is some speculation that using it could break
> third-party tools, but (a) we would need more conc
On 01/17/18 06:50, Geoff Winkless wrote:
> Having said all that, has anyone suggested grabbing and writing out
> using the "stty quit" value? That appears to work whatever level
> you're at, readline-or-not, mid-line or not. It wasn't even something
> I was aware of.
Well, the usual use of SIGQUI
On 17 January 2018 at 14:17, Chapman Flack wrote:
> Well, the usual use of SIGQUIT is to abort a process while generating
> a core dump so it can be post-mortem debugged, and the abort is immediate
> without any exit hooks in the process having a chance to execute, so
> maybe it isn't a habit we w
Christoph Berg writes:
> Re: Peter Eisentraut 2018-01-17
>
>> So what is the next action this thread? I think --with-extra-version is
>> the right solution for packagers, so I'm tempted to close this commit
>> fest item. There is some speculation that using it could break
>> third-party tools,
Re: Tom Lane 2018-01-17 <15537.1516200...@sss.pgh.pa.us>
> IMO there's not really any evidence that we need an additional mechanism
> in this space. I don't see any way to get that evidence unless some
> packager tries to use the existing mechanism and hits insurmountable
> problems.
The problem
Chapman Flack writes:
> On 01/17/18 06:50, Geoff Winkless wrote:
>> Having said all that, has anyone suggested grabbing and writing out
>> using the "stty quit" value? That appears to work whatever level
>> you're at, readline-or-not, mid-line or not. It wasn't even something
>> I was aware of.
>
Christoph Berg writes:
> Re: Tom Lane 2018-01-17 <15537.1516200...@sss.pgh.pa.us>
>> IMO there's not really any evidence that we need an additional mechanism
>> in this space. I don't see any way to get that evidence unless some
>> packager tries to use the existing mechanism and hits insurmounta
On 17 January 2018 at 14:50, Tom Lane wrote:
> (I'm still not very sure which of ^C and ^D have Windows equivalents.)
Ctrl-C quits immediately for me no matter what input stage I'm at in
Windows' psql. Ctrl-Z (DOS EOF) only quits after enter is pressed and
only at beginning-of-line, so I'd say su
[I added Victor Wagner as co-researcher of this problem]
On 13-01-2018 21:10, Tom Lane wrote:
In the end this might just be an instance of the old saw about
avoiding dot-zero releases. Have you tried a newer gcc?
(Digging in their bugzilla finds quite a number of __int128 bugs
fixed in 5.4.x, t
I wrote:
> Yeah, but the same argument could be made against the variant
> you're proposing. In theory, people could have written arbitrarily
> brittle checks of version numbers/strings. I'm not exactly convinced
> that it's your (or our) problem if they did.
BTW, as concrete evidence in this ar
Marina Polyakova writes:
> investigating the regression diffs, we found out that the error occurs
> when we pass int128 as not the first argument to the function (perhaps
> its value is replaced by the value of some address):
> ...
> Based on this, we modified the test program (see attached). He
Sorry, diff.patch is attached now.
On 17-01-2018 18:02, Marina Polyakova wrote:
[I added Victor Wagner as co-researcher of this problem]
On 13-01-2018 21:10, Tom Lane wrote:
In the end this might just be an instance of the old saw about
avoiding dot-zero releases. Have you tried a newer gcc?
On Wed, 17 Jan 2018 18:02:26 +0300
Marina Polyakova wrote:
> > Attached is a possible test program. I can confirm it passes on a
> > machine with working __int128, but I have no idea whether it will
> > detect the problem on yours. If not, maybe you can tweak it?
>
> Thank you! Using gcc 5.5.
Re: Tom Lane 2018-01-17 <16522.1516201...@sss.pgh.pa.us>
> I wrote:
> > Yeah, but the same argument could be made against the variant
> > you're proposing. In theory, people could have written arbitrarily
> > brittle checks of version numbers/strings. I'm not exactly convinced
> > that it's your
BTW, now that you've demonstrated that the bug exists in a current
gcc release, you should definitely file a bug at
https://gcc.gnu.org/bugzilla/
I think you can just give them int128test2.c as-is as a test case.
Please do that and let me know the PR number --- I think it would be
good to cite the
On Wed, 17 Jan 2018 10:07:37 -0500
Tom Lane wrote:
> Marina Polyakova writes:
> Yeah, I can work with this. What I propose to do is use a somewhat
> stripped-down version of this test as an AC_RUN_IFELSE test normally,
> but if cross-compiling, fall back to just seeing if we can link.
I'd sug
Victor Wagner writes:
> On Wed, 17 Jan 2018 10:07:37 -0500
> Tom Lane wrote:
>> Yeah, I can work with this. What I propose to do is use a somewhat
>> stripped-down version of this test as an AC_RUN_IFELSE test normally,
>> but if cross-compiling, fall back to just seeing if we can link.
> I'd s
Victor Wagner writes:
> I'm attaching stripped-down version of test program, which demonstrate
> the problem and two assembler listings produced with this C source using
> alignment 8 and 16. May be this stripped-down version can be used as
> base for configure test.
Ah, thanks, this will be eas
On 17-01-2018 18:07, Tom Lane wrote:
Marina Polyakova writes:
investigating the regression diffs, we found out that the error occurs
when we pass int128 as not the first argument to the function (perhaps
its value is replaced by the value of some address):
...
Based on this, we modified the tes
Hi all,
I need to test whether a database is empty, in other words “createdb” has been
executed but no data of any kind appears in that database.
What is the correct postgresql way to do this?
Is there a pg_isempty command or equivalent somewhere?
Regards,
Graham
—
smime.p7s
Description: S/
Marina Polyakova writes:
> On 17-01-2018 18:07, Tom Lane wrote:
>> Yeah, I can work with this. What I propose to do is use a somewhat
>> stripped-down version of this test as an AC_RUN_IFELSE test normally,
>> but if cross-compiling, fall back to just seeing if we can link.
> Thanks, I'll try to
On 17-01-2018 18:28, Tom Lane wrote:
BTW, now that you've demonstrated that the bug exists in a current
gcc release, you should definitely file a bug at
https://gcc.gnu.org/bugzilla/
I think you can just give them int128test2.c as-is as a test case.
Please do that and let me know the PR number -
I always do:\l+and then you can compare the size:new_one | postgres | UTF8
| en_US.UTF-8 | en_US.UTF-8 | | *7869 kB* | pg_default
| template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres
+| *7869 kB* | pg_default | |
On 17 Jan 2018, at 6:01 PM, pinker wrote:
> I always do: \l+ and then you can compare the size: new_one | postgres | UTF8
> | en_US.UTF-8 | en_US.UTF-8 | | 7869 kB | pg_default | template0 | postgres |
> UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +| 7869 kB | pg_default | | |
> | | postgre
Hi hackers,
My recent experiments with pthread version of Postgres show that
although pthread offers some performance advantages comparing with
processes for large number of connections, them still can not eliminate
need in connection pooling. Large number even of inactive connections
cause s
> > CREATE ROUTINE MAPPING local_routine_name
> > > FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode ] [
> argname ]
> > > argtype [ { DEFAULT | = } default_expr ] [, ...] ] )
> > >[ RETURNS rettype
> > > | RETURNS TABLE ( column_name column_type [, ...] ) ]
> > > SERVER foreig
On 17 Jan 2018, at 5:47 PM, Graham Leggett wrote:
> I need to test whether a database is empty, in other words “createdb” has
> been executed but no data of any kind appears in that database.
>
> What is the correct postgresql way to do this?
>
> Is there a pg_isempty command or equivalent som
Hi,
On 02/01/18 17:16, Marco Nenciarini wrote:
> Hi,
>
> I've tried to amend the documentation to be more clear. Feel free to
> suggest further editing. Patch v2 attached.
>
I think the patch as is now looks okay. So marking as ready for committer.
This is noteworthy for the release notes thou
Attached is a draft patch to incorporate Victor's slimmed-down test
into configure. If you have a chance, could you confirm it does
the right thing on your Sparc machine?
BTW, it would be a good idea to set up a buildfarm member on that
machine, if you care about whether that configuration contin
On Wed, Jan 17, 2018 at 9:10 AM, Graham Leggett wrote:
>
> db=# select count(s.nspname) from pg_class c join pg_namespace s on s.oid
> = c.relnamespace where s.nspname in ('public');
> count
> ---
> 0
> (1 row)
>
> It is based on the idea that the database is not empty if there are any
On 17 Jan 2018, at 6:34 PM, David G. Johnston
wrote:
> That was my original thought - though comparing the size of template1 to the
> target database should be reasonably safe...
>
> If you do go for object detection you will want to ensure that no schemas
> other than public exist in additi
On Wed, Jan 17, 2018 at 9:39 AM, Graham Leggett wrote:
> Would it be true to say that if this query returned more than zero rows
> the database is not empty?
>
> db=# select distinct s.nspname from pg_class c join pg_namespace s on
> s.oid = c.relnamespace where s.nspname not in ('pg_toast','info
Antonin Houska writes:
> While reading XLogPageRead() I was surprised that readLen variable is set but
> not used in the read() call. Then I realized that it's declared static
> although no other function uses it. Maybe it was used earlier to exit early if
> sufficient amount of data was already r
Hi,
I reviewed 0001 in its own thread.
So I think that we generally want this patch and I think the design
decisions are right. Namely:
TRUNCATE being treated as DELETE in terms of DML filtering makes sense
to me as it is basically bulk delete, needs to be mentioned in release
notes though.
Add
On Wed, Jan 17, 2018 at 5:47 AM, Amit Kapila wrote:
> I could still reproduce it. I think the way you have fixed it has a
> race condition. In _bt_parallel_scan_and_sort(), the value of
> brokenhotchain is set after you signal the leader that the worker is
> done (by incrementing workersFinished)
On 1/2/18 10:35, Peter Eisentraut wrote:
> On 11/26/17 20:05, Andreas Karlsson wrote:
>> I have now implemented this in the attached patch (plus added support
>> for channel binding and rebased it) but I ran into one issue which I
>> have not yet solved. The script for the windows version takes t
В Wed, 17 Jan 2018 11:33:09 -0500
Tom Lane пишет:
> Attached is a draft patch to incorporate Victor's slimmed-down test
> into configure. If you have a chance, could you confirm it does
> the right thing on your Sparc machine?
>
Definitely. As soon as next work day begins in Moscow.
> BTW, it
Peter Eisentraut writes:
> Question for the group: We currently have a number of config settings
> named ssl_*. Some of these are specific to OpenSSL, some are not, namely:
> # general
> ssl
> ssl_dh_params_file
> ssl_cert_file
> ssl_key_file
> ssl_ca_file
> ssl_crl_file
> # OpenSSL
> ssl_ciph
On 1/17/18 10:14, Christoph Berg wrote:
> The difference is that when parsing version() (which is all my variant
> is changing), people already have to deal with extra stuff at the end
> (gcc version), while that would be new for "psql --version".
For me, having the package identifier in "psql -ve
On 1/17/18 12:39, Tom Lane wrote:
> I don't know too much about the internals here, so looking at your
> list, I wonder whether "ssl_dh_params_file" ought to be treated as
> implementation-specific too. The other four files seem essential
> to any feature-complete implementation, but is that one?
> I'm not sure what you mean by the "basic comparison ops" but I'm
> fine with the policy, handling each component values in the same
> way with float. So point_eq_point() is right and other functions
> should follow the same policy.
I mean <, >, <= and >= by basic comparison operators. Operator
Graham Leggett wrote:
> Hi all,
>
> I need to test whether a database is empty, in other words “createdb”
> has been executed but no data of any kind appears in that database.
Why do you want to know?
Depends on how you define empty. If a few functions exist but no
tables, is the database empty
+1 to the concept... A lot of user could benefit if we did this in a good
way.
On Wed, Jan 17, 2018 at 8:09 AM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
> Hi hackers,
>
> My recent experiments with pthread version of Postgres show that although
> pthread offers some performance adv
Peter Eisentraut writes:
> On 1/17/18 12:39, Tom Lane wrote:
>> I don't know too much about the internals here, so looking at your
>> list, I wonder whether "ssl_dh_params_file" ought to be treated as
>> implementation-specific too. The other four files seem essential
>> to any feature-complete i
On Wed, Jan 17, 2018 at 12:27 PM, Peter Geoghegan wrote:
> I think that both problems (the live _bt_parallel_scan_and_sort() bug,
> as well as the general issue with needing to account for parallel
> worker fork() failure) are likely solvable by not using
> tuplesort_leader_wait(), and instead cal
Ashutosh Sharma writes:
> While working on exclusion constraints for one of our internal
> project, I noticed that there is no test-case for exclusion
> constraints in alter_table.sql file. However, for other constraints i
> could see lots of test-cases in alter_table.sql. There are hardly 1-2
> t
On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 1/17/18 12:39, Tom Lane wrote:
> >> I don't know too much about the internals here, so looking at your
> >> list, I wonder whether "ssl_dh_params_file" ought to be treated as
> >> implementation-specific too. The
On Mon, Jan 15, 2018 at 7:54 PM, Peter Geoghegan wrote:
>> BufFileView() looks fairly pointless. It basically creates a copy of
>> the input and, in so doing, destroys the input, which is a lot like
>> returning the input parameter except that it uses more cycles. It
>> does do a few things.
>
>
Tom Lane wrote:
> Antonin Houska writes:
> but your patch also does this:
Yes, that should have been a separate diff.
> > *** retry:
> > *** 11648,11654
> > }
> >
> > pgstat_report_wait_start(WAIT_EVENT_WAL_READ);
> > ! if (read(readFile, readBuf, XLOG_BLCKSZ) !=
Etsuro Fujita writes:
> (2018/01/16 6:38), Tom Lane wrote:
>> I'm also still pretty unhappy with the amount of useless planning work
>> caused by doing GetExistingLocalJoinPath during path creation. It strikes
>> me that we could likely replace the entire thing with some code that just
>> reconst
On Wed, Jan 17, 2018 at 11:09:19AM -0500, Corey Huinker wrote:
> > > CREATE ROUTINE MAPPING local_routine_name
> > > > FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode ] [
> > argname ]
> > > > argtype [ { DEFAULT | = } default_expr ] [, ...] ] )
> > > >[ RETURNS rettype
> > > >
Magnus Hagander writes:
> On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane wrote:
>> What I don't want to end up with is an unholy mixture of both approaches.
>> Therefore, if we are going to use method #2, we must be certain that
>> the basic "ssl_" parameters are supported by every implementation,
>>
Antonin Houska writes:
> Tom Lane wrote:
>> At one time, I think, readLen told how much data in readBuf was
>> actually valid. It seems not to be used for that anymore, but
>> I don't much like the idea that readBuf is only partially filled
>> but there is *no* persistent state indicating how mu
Aleksandr Parfenov writes:
> The new status of this patch is: Ready for Committer
I don't feel particularly comfortable committing a patch that
was clearly labeled as a rushed draft by its author.
Peter, where do you stand on this work?
In a quick look at the patches, WIP-kludge-fix.patch seems
On Wed, Jan 17, 2018 at 8:53 AM, Simon Riggs wrote:
> At present, one major use of Cursors is in postgres_fdw.
>
> In that usage, the query executes and returns all the rows. No other
> side execution is possible.
True, although foreign tables using postgres_fdw can't be scanned in
parallel for o
Etsuro Fujita writes:
> (2018/01/15 11:35), Amit Langote wrote:
>> On 2018/01/15 11:28, Stephen Frost wrote:
>>> Seems like this has gotten a review (and quite a bit of down-stream
>>> discussion that seemed pretty positive), and the latest patch still
>>> applies cleanly and passes the regression
On Sat, Jan 6, 2018 at 7:33 PM, Stephen Frost wrote:
> Greetings Claudio,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > On Mon, Nov 27, 2017 at 2:39 PM, Jing Wang
> wrote:
> > > A few general comments.
> > >
> > > + FreeSpaceMapVacuum(onerel, 64);
> > >
> > > Just want to know w
On Mon, Jan 15, 2018 at 4:38 PM, Tom Lane wrote:
> There *is* a problem with GetExistingLocalJoinPath not honoring its
> API spec: it will sometimes return join nests that include remote
> joins at levels below the top, as I'd speculated to begin with.
> This turns out not to be a problem for post
On Sat, Jan 6, 2018 at 7:35 PM, Stephen Frost wrote:
> Greetings,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire
> wrote:
> > > They did apply at the time, but I think major work on vacuum was
> > > pushed since then, and also I was tr
On Wed, Jan 17, 2018 at 10:00 AM, Geoff Winkless wrote:
> On 17 January 2018 at 14:50, Tom Lane wrote:
>> (I'm still not very sure which of ^C and ^D have Windows equivalents.)
>
> Ctrl-C quits immediately for me no matter what input stage I'm at in
> Windows' psql.
Does it kill the whole progra
On 17 Jan 2018 20:12, "Robert Haas" wrote:
On Wed, Jan 17, 2018 at 10:00 AM, Geoff Winkless
wrote:
> On 17 January 2018 at 14:50, Tom Lane wrote:
>> (I'm still not very sure which of ^C and ^D have Windows equivalents.)
>
> Ctrl-C quits immediately for me no matter what input stage I'm at in
>
On Wed, Jan 17, 2018 at 5:02 PM, Claudio Freire
wrote:
>
>
> On Sat, Jan 6, 2018 at 7:35 PM, Stephen Frost wrote:
>
>> Greetings,
>>
>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> > On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire
>> wrote:
>> > > They did apply at the time, but I thi
Hello Fabien,
17/01/2018 10:52, Fabien COELHO пишет:
>> Here is a new version of patch. I've splitted it into two parts. The
>> first one is almost the same as v4 from [1] with some refactoring.
>> The second part introduces random_seed variable as you proposed.
>
> Patch 1 applies. Compilations
On 17 January 2018 at 15:00, I wrote:
> Ctrl-C quits immediately for me no matter what input stage I'm at in
> Windows' psql. Ctrl-Z (DOS EOF) only quits after enter is pressed and
> only at beginning-of-line, so I'd say suggesting the user uses Ctrl-C
> in windows makes sense. ^D doesn't appear to
On Wed, Jan 17, 2018 at 11:23 AM, Tom Lane wrote:
> Aleksandr Parfenov writes:
>> The new status of this patch is: Ready for Committer
>
> I don't feel particularly comfortable committing a patch that
> was clearly labeled as a rushed draft by its author.
> Peter, where do you stand on this work?
On Tue, Jan 16, 2018 at 2:00 AM, Yoshimi Ichiyanagi
wrote:
> Using pgbench which is a PostgreSQL general benchmark, the postgres server
> to which the patches is applied is about 5% faster than original server.
> And using my insert benchmark, it is up to 90% faster than original one.
> I will des
Peter Geoghegan writes:
> On Wed, Jan 17, 2018 at 11:23 AM, Tom Lane wrote:
>> I don't feel particularly comfortable committing a patch that
>> was clearly labeled as a rushed draft by its author.
>> Peter, where do you stand on this work?
> I would like to take another pass over
> WIP-tuplesort
Robert Haas writes:
> Thanks for the review. Updated patch attached.
Looks OK to me. Would it be worth annotating the added regression test
case with a comment that this once caused EPQ-related planning problems?
regards, tom lane
On Tue, Jan 16, 2018 at 2:00 AM, Yoshimi Ichiyanagi
wrote:
> C-5. Running the 2 benchmarks(1. pgbench, 2. my insert benchmark)
> C-5-1. pgbench
> # numactl -N 1 pgbech -c 32 -j 8 -T 120 -M prepared [DB_NAME]
>
> The averages of running pgbench three times are:
> wal_sync_method=fdatasync: tps =
On Wed, Jan 17, 2018 at 12:31 PM, Tom Lane wrote:
> Probably not very. It'd be nice to have it done by the next minor
> releases, ie before 5-Feb ... but given that these bugs are years
> old, missing that deadline would not be catastrophic.
Got it.
>> I'm not sure whether or not we should also
Hi!
This patch is part of a bigger patch I've offered before
https://www.postgresql.org/message-id/flat/2146419.veIEZdk4E4@x200m#2146419.veIEZdk4E4@x200m
as we agreed I am trying to commit it by smaller bits
This patch raises error if user tries o set or change toast.* option for a
table that doe
Peter Geoghegan writes:
> On Wed, Jan 17, 2018 at 12:31 PM, Tom Lane wrote:
>> +1. If the problem isn't known to be reproducible in those branches,
>> the risk of adding new bugs seems to outweigh any benefit.
> You could make the same objection to changing tuplesort_getdatum()
> outside of the
On 01/15/2018 07:24 PM, Andrew Dunstan wrote:
>
> On 01/10/2018 05:42 PM, Nikita Glukhov wrote:
>> Attached new 8th version of jsonpath related patches. Complete
>> documentation is still missing.
>>
>> The first 4 small patches are necessary datetime handling in jsonpath:
>> 1. simple refactorin
On Wed, Jan 17, 2018 at 3:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> Thanks for the review. Updated patch attached.
>
> Looks OK to me. Would it be worth annotating the added regression test
> case with a comment that this once caused EPQ-related planning problems?
I tend to think somebod
Robert Haas writes:
> On Wed, Jan 17, 2018 at 3:37 PM, Tom Lane wrote:
>> Looks OK to me. Would it be worth annotating the added regression test
>> case with a comment that this once caused EPQ-related planning problems?
> I tend to think somebody who is curious about the origin of any
> partic
Haribabu Kommi writes:
> [ pg_dump-and-pg_dumpall-database-handling-refactoring_v12.patch ]
I started to look through this, and almost immediately found that the
diff in t/002_pg_dump.pl doesn't seem necessary --- the test passes
for me without applying that hunk. Is that a leftover from a previ
В письме от 3 сентября 2017 11:45:43 пользователь Alvaro Herrera написал:
> The new checks around toast table creation look like they belong to a
> completely independent patch also ... the error message there goes
> against message style guidelines also.
Offered toast relation checks as a separa
On 15 January 2018 at 15:45, Andres Freund wrote:
> On January 14, 2018 5:44:01 PM PST, Edmund Horner wrote:
>>In psql if you have readline support and press TAB, psql will often
>>run a DB query to get a list of possible completions to type on your
>>current command line.
>>
>>It uses the curren
On 1/17/18 13:18, Tom Lane wrote:
>> The proposed GnuTLS patch does make use of ssl_dh_params_file.
>
> Right, but what happens if say macTLS doesn't?
The previously proposed patch for that also makes use of ssl_dh_params_file.
So while we can't guarantee that this will be the case for all TLS
i
1 - 100 of 129 matches
Mail list logo
