> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
> Sent: Tuesday, September 29, 2015 12:15 PM
> To: Kaigai Kouhei(海外 浩平); Robert Haas
> Cc: PostgreSQL-development; 花田茂
> Subject: Re: [HACKERS] Foreign
Stephen Frost writes:
> * Jim Nasby (jim.na...@bluetreble.com) wrote:
>> 2 years ago is when they first released the enterprise edition,
>> which according to [1] had "The most important new feature is that
>> you can now add members to groups of projects."
> It needed a lot
On 2015/09/12 4:26, Robert Haas wrote:
On Fri, Sep 11, 2015 at 6:22 AM, Etsuro Fujita
wrote:
The comments for create_foreignscan_path says as follows, but that it's
now possible that the function is called by GetForeignJoinPaths, which
was added in 9.5.
1450 /*
(Note: I've not read the patch, so this is not an opinion about its
correctness.)
As Fabien anayzed the problem was that pgbench simply uses wrong
variable: nthreads (number of threads, specified by "-j" option)
vs. nclients (number of clients, specified by "-c" option).
@@ -2616,7 +2616,7
Good morning
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Stephen Frost
> Sent: Montag, 28. September 2015 21:16
> To: Peter Eisentraut ; Robert Haas
> Cc: pgsql-hackers
On Sun, Sep 27, 2015 at 1:39 AM, Robert Haas wrote:
>
> I intend to commit this patch (but not the crappy test code, of
> course) pretty soon, and then I'm going to start working on the
> portion of the patch that actually adds the Funnel node, which I think
> you are
Hi
now, isn't possible to raise rich exception from plpython or plperl. Should
be fixed.
Regards
Pavel
* Noah Misch (n...@leadboat.com) wrote:
> On Thu, Sep 10, 2015 at 03:23:13PM -0400, Stephen Frost wrote:
> > First off, thanks again for your review and comments on RLS. Hopefully
> > this addresses the last remaining open item from that review.
>
> Item (3a), too, remains open.
Provided I
I have spent sometime to investigate the issue, it is reproduciable. In
case of Windows, when pqsecure_raw_read() function error code
WSAEWOULDBLOCK (EWOULDBLOCK) when no data queued to be read from the non
blocking socket there is a need to log retry flag. Related error code can
be retrieved via
On Mon, Sep 28, 2015 at 7:09 PM, Pavel Stehule
wrote:
>
> 2015-09-28 12:37 GMT+02:00 Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de>:
>
>>
>>> I didn't propose too different solution. There is only one difference -
>>> sharing DSM for smaller data. It is similar to
On Mon, Sep 28, 2015 at 2:05 AM, Haribabu Kommi
wrote:
> I got the following way to get the whether data file is present in the
> DISK or SSD.
>
> 1. Get the device file system that table data file is mapped using the
> following or similar.
>
> df -P "filename" | awk
On 2015-09-28 18:59, Robert Haas wrote:
The patch looks good to me except the following minor points.
* or not. Normal path through RecordTransactionCommit() will be related
* to a transaction commit XLog record, and so should pass "false" here.
The above source comment of
On 09/28/2015 08:10 AM, Robert Haas wrote:
> -1 on that idea. I really don't think that we should categorically
> decide we don't support higher optimization levels. If the compiler
> has a bug, then the compiler manufacturer should fix it, and it's not
> our fault. If the compiler doesn't have
* Peter Eisentraut (pete...@gmx.net) wrote:
> I see. But it is a bit odd to hide this very fundamental behavior
> somewhere in a paragraph that starts out with something about roles.
I'm happy to change that. You're right, it should be a paragraph by
itself.
> There is also a mistake, I
On Mon, Sep 28, 2015 at 3:15 PM, Stephen Frost wrote:
> I listed out the various alternatives but didn't end up getting any
> responses to it. I'm still of the opinion that the documentation is the
> main thing which needs improving here, but we can also change CREATE
>
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> None of this renaming seems like an improvement to me.
I have to admit that I'm not entirely sure it's improving things either.
Certainly, we shouldn't be dumping out the withCheckOptions node and
perhaps we should move its place in Query and
2015-09-28 12:37 GMT+02:00 Shulgin, Oleksandr
:
> On Mon, Sep 28, 2015 at 12:05 PM, Pavel Stehule
> wrote:
>
>>
>> 2015-09-28 12:01 GMT+02:00 Shulgin, Oleksandr <
>> oleksandr.shul...@zalando.de>:
>>
>>> On Sun, Sep 27, 2015 at 8:05 AM,
2015-09-28 19:13 GMT+02:00 Shulgin, Oleksandr
:
> On Mon, Sep 28, 2015 at 7:09 PM, Pavel Stehule
> wrote:
>
>>
>> 2015-09-28 12:37 GMT+02:00 Shulgin, Oleksandr <
>> oleksandr.shul...@zalando.de>:
>>
>>>
I didn't propose too different
On 2015-09-28 09:41:18 -0700, David Fetter wrote:
> Since you're convinced that this is an unqualified win, please put
> together a project plan for switching from our current system to
> Github.
Err, no. That's a waste of all our time.
It has been stated pretty clearly in this thread by a
Alvaro Herrera writes:
> Yup. However I notice that there are a few other callers of
> expression_planner() that do not involve the optimizer for anything
> else. Maybe it makes sense to have a separate header file that's just
> #include "nodes/primnodes.h"
> extern
On Mon, Sep 28, 2015 at 2:07 PM, Petr Jelinek wrote:
> Sorry, missed your reply.
To be clear, that was actually Fujii Masao's reply, not mine. I hope
he can have a look at this version.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On Mon, Sep 28, 2015 at 2:34 PM, Josh Berkus wrote:
> On 09/28/2015 08:10 AM, Robert Haas wrote:
>> -1 on that idea. I really don't think that we should categorically
>> decide we don't support higher optimization levels. If the compiler
>> has a bug, then the compiler
On Mon, Sep 28, 2015 at 07:14:40PM +0300, YUriy Zhuravlev wrote:
> On Monday 28 September 2015 08:23:46 David Fetter wrote:
> > They may well be, but until we decide it's worth the switching
> > costs to move to a totally different way of doing things, that
> > system will stay in place.
> Until
On 09/28/2015 05:50 AM, YUriy Zhuravlev wrote:
On Thursday 24 September 2015 12:10:07 Ryan Pedela wrote:
Kam Lasater wrote:
I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Alvaro Herrera writes:
> > > I noticed that COPY calls planner() (this was introduced in 85188ab88).
> > > I think it should be calling pg_plan_query() instead.
> >
> > +1 --- AFAICS, this is the *only*
On Fri, Sep 18, 2015 at 12:53 AM, Fujii Masao wrote:
> On Sat, Sep 5, 2015 at 7:48 PM, Petr Jelinek wrote:
>> On 2015-09-02 16:14, Fujii Masao wrote:
>>>
>>> On Wed, Aug 5, 2015 at 2:16 AM, Robert Haas wrote:
On Mon,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Sep 15, 2015 at 10:22 AM, Stephen Frost wrote:
> > Unless there are other concerns or issues raised, I'll push this later
> > today.
>
> So does this mean that the first RLS open item is addressed? If so,
> can it be
Asif Naeem wrote:
> I have spent sometime to investigate the issue, it is reproduciable. In
> case of Windows, when pqsecure_raw_read() function error code
> WSAEWOULDBLOCK (EWOULDBLOCK) when no data queued to be read from the non
> blocking socket there is a need to log retry flag. Related error
On Mon, Sep 28, 2015 at 3:34 AM, Kouhei Kaigai wrote:
> The attached patch allows FDW driver to handle EPQ recheck by its own
> preferable way, even if it is alternative local join or ExecQual to
> the expression being pushed down.
Thanks. I was all set to commit this, or
Asif Naeem writes:
> I have spent sometime to investigate the issue, it is reproduciable. In
> case of Windows, when pqsecure_raw_read() function error code
> WSAEWOULDBLOCK (EWOULDBLOCK) when no data queued to be read from the non
> blocking socket there is a need to log
I wrote:
> ... and the reassignment to errno at the
> bottom of my_sock_read needs to be SOCK_ERRNO_SET(); and why doesn't
> my_sock_write have a reassignment at all?
Comparison to the backend versions of these routines, which have been
through quite a few releases, suggests that the reassignment
On 2015-09-28 17:28:48 -0400, Tom Lane wrote:
> > What I do find curious is that afaics before 680513ab79 the code also
> > looked at errno, not SOCK_ERRNO. And apparently things worked back then?
>
> No; AFAICS, before that commit, libpq did not use a custom BIO at all.
> That commit cloned the
Andres Freund writes:
> We now probably could remove
> * XXX OpenSSL 1.0.1e considers many more errcodes than just EINTR as reasons
> * to retry; do we need to adopt their logic for that?
> since we now actually check for more tahn just EINTR.
Well, that comment is cloned
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Sep 22, 2015 at 10:38:53AM -0400, Stephen Frost wrote:
> > This would lead to trivial to cause (and likely hard to diagnose)
> > referential integrity data corruption issues. I find that a very hard
> > pill to swallow in favor of a theoretical
On 9/27/15 2:25 PM, Andres Freund wrote:
On 2015-09-27 14:21:08 -0500, Jim Nasby wrote:
IMHO doing just a log of something this serious; it should at least be a
WARNING.
In postgres LOG, somewhat confusingly, is more severe than WARNING.
Ahh, right. Which in this case stinks, because
Has anyone ever run cachegrind [1] against Postgres? I see little about
it on the mailing list so I'm guessing no...
[1] http://valgrind.org/docs/manual/cg-manual.html
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in
Andres Freund writes:
> On 2015-09-28 16:57:24 -0400, Tom Lane wrote:
>> Great detective work! But if that's broken, then surely the identical
>> code in my_sock_write is as well; and the reassignment to errno at the
>> bottom of my_sock_read needs to be SOCK_ERRNO_SET(); and
Stephen Frost writes:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> Also, these were added in 9.4, so introducing this many differences
>> between 9.4 and 9.5+ will make back-patching harder.
> That's certainly true, but we don't want current or future hackers to be
>
On 2015-09-28 16:57:24 -0400, Tom Lane wrote:
> Asif Naeem writes:
> > I have spent sometime to investigate the issue, it is reproduciable. In
> > case of Windows, when pqsecure_raw_read() function error code
> > WSAEWOULDBLOCK (EWOULDBLOCK) when no data queued to be read
On Thu, Sep 24, 2015 at 4:21 PM, Noah Misch wrote:
> On Fri, Jun 26, 2015 at 09:09:15AM -0400, Robert Haas wrote:
>> On Tue, Jun 23, 2015 at 1:31 AM, Michael Paquier
>> wrote:
>> >> I tracked the dangerous -rf to come from Makefile.global and it's
On Tue, Sep 15, 2015 at 10:22 AM, Stephen Frost wrote:
> Dean,
>
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> A minor point -- this comment isn't quite right:
>
> Fixed.
>
>> because the policies that are fetched there are only used for
>> add_security_quals(), not
On 27 September 2015 at 02:15, Jinyu Zhang wrote:
>
> BRIN Scan: Optimize memory allocation in function 'bringetbitmap'.
> We can allocate memory for some pointer before do long loop instead of
> allocating
> memory in long loop.
>
> Before optimizing code (warm run)
>
On Sat, Sep 26, 2015 at 7:24 AM, Michael Paquier
wrote:
> On Sat, Sep 26, 2015 at 7:18 AM, Jeff Janes wrote:
>> If I have "alter table foo alter COLUMN bar SET STATISTICS" in the line
>> buffer,
>> it tab completes to add " TO", which is not
On Sat, Sep 26, 2015 at 9:46 PM, Peter Eisentraut wrote:
> On 9/23/15 3:41 PM, Stephen Frost wrote:
> I see. But it is a bit odd to hide this very fundamental behavior
> somewhere in a paragraph that starts out with something about roles.
>
> There is also a mistake, I believe:
Fabien COELHO writes:
>> Yeah, that's definitely a bug but I'm afraid the fix will change the
>> TPS number and may break the backward compatibility. Since we have
>> lived with bug for years, I hesitate to back port to older stable
>> branches...
> My 2¥: I do not think of
Hi Gavin
Note that Alexander Korotkov already started work in 2013 on a
somewhat similar feature called partial sort:
http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com
In particular, see the 2nd patch for KNN sort -- it uses known
bounding
On Sat, Sep 26, 2015 at 3:27 AM, Fabien COELHO wrote:
> Here is a v10, which is a rebase because of the "--progress-timestamp"
> option addition.
I do not see it attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent
On Thu, Sep 24, 2015 at 10:24 PM, Thomas Munro
wrote:
> While studying lmgr code, I noticed that there are a couple of places
> that use 1 << x to convert a LOCKMODE to a LOCKMASK instead of the
> macro that is used elsewhere. Should that be changed for
On Thu, Sep 24, 2015 at 9:19 PM, Kouhei Kaigai wrote:
> Then, let's look back a bit. Next issue is how to reproduce
> the "methods" pointer from the text representation.
> I try to lookup the methods table using a pair of library
> and symbol name; probably, it is a
On Thu, Sep 24, 2015 at 11:47 AM, Teodor Sigaev wrote:
> Hi!
>
> After reading thread
> http://www.postgresql.org/message-id/flat/CAMkU=1xalflhuuohfp5v33rzedlvb5aknnujceum9knbkrb...@mail.gmail.com#CAMkU=1xalflhuuohfp5v33rzedlvb5aknnujceum9knbkrb...@mail.gmail.com
>
> I agree,
Hello Tom,
FWIW, I vote with Tatsuo-san. Such a change will break comparability of
results
I would not classify a performance measure as a "result compatibility"
issue. What matters is the *correction* of the results.
When a bug is fixed anywhere in pg it may change performance
On Thu, Sep 24, 2015 at 8:37 AM, Masahiko Sawada wrote:
> When we run "VACUUM;", the all tables of current database will be vacuumed.
> So pg_stat_vacuum_progress should have these oid in order to show
> which table is vacuumed now.
Hmm, I would tend to instead show the
On Mon, Sep 28, 2015 at 03:50:29PM +0300, YUriy Zhuravlev wrote:
> On Thursday 24 September 2015 12:10:07 Ryan Pedela wrote:
> > Kam Lasater wrote:
> > > I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably
> > > in that order). There are tens to hundreds of other great ones
> > > out
On 09/28/2015 05:28 PM, Marti Raudsepp wrote:
Note that Alexander Korotkov already started work in 2013 on a
somewhat similar feature called partial sort:
http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com
In particular, see the 2nd patch for
On Fri, Sep 25, 2015 at 7:13 PM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
>
> Some implementation details:
>
> For every backend that might be running (MaxBackends) we reserve a
> dsm_handle slot in the addins shared memory. When the new option is turned
> on, the ExecutorRun
Sorry, I forgot attaching patch. But I have send path in another thread.
Please see this thread "Patch: Optimize memory allocation in function
'bringetbitmap' ".
--
View this message in context:
On Monday 28 September 2015 08:23:46 David Fetter wrote:
> They may well be, but until we decide it's worth the switching costs
> to move to a totally different way of doing things, that system will
> stay in place.
Until we decide we're wasting time
>Neither magic wands nor a green field project
В письме от 26 сентября 2015 20:57:25 Вы написали:
> >> Thanks! I just had a short look at it:
> >> - I am not convinced that it is worth declaring 3 versions of
> >> tuple_data_split.
> >
> > How which of them should we leave?
>
> The one with the most arguments. Now perhaps we could have as
Here is a v10, which is a rebase because of the "--progress-timestamp"
option addition.
I do not see it attached.
Indeed. Here it is.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 0ac40f1..e3a90e5 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++
Hi list
The attached patch changes the behavior of multiple ALTER x SET SCHEMA
commands, to skip, rather than fail, when the old and new schema is
the same.
The advantage is that it's now easier to write DDL scripts that are indempotent.
This already matches the behavior of ALTER EXTENSION SET
Yes, I forgot disable-c-assert last test.
The following show the test result when disable-c-assert.
I think it's still worthwhile.
*After optimize code (warm run)*
postgres=# select count(*) from lineitem where l_orderkey=1;
count
---
6
(1 row)
Time: 327.143 ms
*Before optimizing
On Fri, Sep 25, 2015 at 3:41 AM, Andreas Seltenreich
wrote:
> I think the intention was to make configure complain if there's a -O > 2
> in CFLAGS.
-1 on that idea. I really don't think that we should categorically
decide we don't support higher optimization
On 2015/09/28 13:31, David Rowley wrote:
> I've been spending time working on allowing the planner to perform
> aggregation before the final join relation is created.
>
...
>
> The patch is however so far capable of giving us extremely nice performance
> improvements for some (likely artificial)
Hello Tatsuo-san,
I think that the degree of parallelism to consider is nclients, not
nthreads: while connection time is accumulated in conn_time, other
clients are possibly doing their transactions, in parallel,
I'm not sure about this. I think pgbench will not start transactions
until all
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Saturday, September 12, 2015 1:39 AM
> To: Etsuro Fujita
> Cc: Kaigai Kouhei(海外 浩平); PostgreSQL-development; 花田茂
> Subject: Re: [HACKERS] Foreign
> I have tested your patch. It seems the tolerance is much better than
> before with your patch.
[snip]
> I'm going to commit your patch if there's no objection.
I think we should commit this to master and 9.5 stable branch only
because the fix significantly changes the benchmark result of
>> I'm not sure about this. I think pgbench will not start transactions
>> until all clients establish connections to PostgreSQL.
>
> I think that is true if "!is_connect", all client connections are
> performed at the beginning of threadRun, but under -C each client has
> its own
On 28 September 2015 at 20:36, Amit Langote
wrote:
>
> Did you perhaps attach a version of the patch you didn't intend to?
>
Oops. It seems so.
Please find the correct version attached.
Thanks for checking and letting me know.
--
David Rowley
On Tue, Aug 4, 2015 at 2:18 AM, Jeff Janes wrote:
> On Mon, Jul 27, 2015 at 1:40 PM, Simon Riggs wrote:
>>
>> On 22 July 2015 at 17:11, Jeff Janes wrote:
>>>
>>> On Wed, Jul 22, 2015 at 6:59 AM, Robert Haas
> I think that the degree of parallelism to consider is nclients, not
> nthreads: while connection time is accumulated in conn_time, other
> clients are possibly doing their transactions, in parallel,
I'm not sure about this. I think pgbench will not start transactions
until all clients
On 28 September 2015 at 23:17, Amit Langote
wrote:
> On 2015/09/28 17:04, David Rowley wrote:
> > On 28 September 2015 at 20:36, Amit Langote <
> langote_amit...@lab.ntt.co.jp>
> > wrote:
> >
> >>
> >> Did you perhaps attach a version of the patch you didn't intend
On Mon, Sep 28, 2015 at 12:05 PM, Pavel Stehule
wrote:
>
> 2015-09-28 12:01 GMT+02:00 Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de>:
>
>> On Sun, Sep 27, 2015 at 8:05 AM, Pavel Stehule
>> wrote:
>>
>> the preparing of content before
On Sun, Sep 27, 2015 at 8:05 AM, Pavel Stehule
wrote:
the preparing of content before execution is interesting idea, that can be
> used more. The almost queries and plans are not too big, so when the size
> of content is not too big - less than 1MB, then can be used one
#5 0x00402b2b in doConnect () at pgbench.c:650
#6 0x00404591 in doCustom (thread=0x25c2f40, st=0x25c2770,
conn_time=0x25c2f90, logfile=0x0, agg=0x7fffba224260) at pgbench.c:1353
#7 0x0040a1d5 in threadRun (arg=0x25c2f40) at pgbench.c:3581
#8 0x00409ab4 in
>> Yeah, that's definitely a bug but I'm afraid the fix will change the
>> TPS number and may break the backward compatibility. Since we have
>> lived with bug for years, I hesitate to back port to older stable
>> branches...
>
> My 2¥: I do not think of a good argument to keep wrong tps numbers
2015-09-28 12:01 GMT+02:00 Shulgin, Oleksandr
:
> On Sun, Sep 27, 2015 at 8:05 AM, Pavel Stehule
> wrote:
>
> the preparing of content before execution is interesting idea, that can be
>> used more. The almost queries and plans are not too
On 2015/09/28 17:04, David Rowley wrote:
> On 28 September 2015 at 20:36, Amit Langote
> wrote:
>
>>
>> Did you perhaps attach a version of the patch you didn't intend to?
>>
>
> Oops. It seems so.
>
> Please find the correct version attached.
Thanks, this one
Thom Brown writes:
> With 9.5 alpha 2 on Windows 8 (64-bit), trying to require SSL results
> in a blocking error:
I've pushed a patch for this; can you verify it on Windows?
regards, tom lane
--
Sent via pgsql-hackers mailing list
On 9/18/15 5:05 AM, Shulgin, Oleksandr wrote:
It should not be true - the data sender create DSM and fills it.
Then set caller slot and send signal to caller. Caller can free DSM
any time, because data sender send newer touch it.
But the requester can timeout on waiting for reply
Jim Nasby writes:
> On 9/28/15 11:43 AM, Andres Freund wrote:
>> It has been stated pretty clearly in this thread by a number of senior
>> community people that we're not going to use a closed source system.
> GitLab OTOH is released under a MIT license, so it is an
On Mon, Sep 28, 2015 at 4:09 PM, Jim Nasby wrote:
> On 9/28/15 11:43 AM, Andres Freund wrote:
>
>> On 2015-09-28 09:41:18 -0700, David Fetter wrote:
>>
>>> Since you're convinced that this is an unqualified win, please put
>>> together a project plan for switching from
On 09/28/2015 03:40 PM, Alvaro Herrera wrote:
Tom Lane wrote:
Now, running gitlab on community-owned hardware would potentially be an
option, if we find gitlab attractive from a functionality standpoint.
The question I'd have about that is whether it has a real development
community, or is
Josh Berkus writes:
> The infra team seems to be good with debbugs, and several committers
> seem to like it, why not go with it?
It certainly seems like debbugs is the proposal to beat at this point.
In the end though, what matters is somebody doing the dogwork to make
it
On 9/28/15 5:34 PM, Tom Lane wrote:
Now, running gitlab on community-owned hardware would potentially be an
option, if we find gitlab attractive from a functionality standpoint.
The question I'd have about that is whether it has a real development
community, or is open-source in name only. If
Matt Newell writes:
> 1. When a connection issues it's first LISTEN command, in
> Exec_ListenPreCommit
> QUEUE_BACKEND_POS(MyBackendId) = QUEUE_TAIL;
> this causes the connection to iterate through every notify queued in the
> slru,
> even though at that point I
On 9/28/15 6:06 PM, Tom Lane wrote:
Josh Berkus writes:
The infra team seems to be good with debbugs, and several committers
seem to like it, why not go with it?
It certainly seems like debbugs is the proposal to beat at this point.
In the end though, what matters is
This morning with our production database I began receiving reports
of the database being "down".
I checked the log and was surprised to see extremely long durations for a
LISTEN that happens after each connection is made by our database library.
This coincided with many(approx 600) new
On 29/09/15 11:54, Joshua D. Drake wrote:
On 09/28/2015 03:40 PM, Alvaro Herrera wrote:
Tom Lane wrote:
Now, running gitlab on community-owned hardware would potentially be an
option, if we find gitlab attractive from a functionality standpoint.
The question I'd have about that is whether it
On 9/28/15 11:43 AM, Andres Freund wrote:
On 2015-09-28 09:41:18 -0700, David Fetter wrote:
Since you're convinced that this is an unqualified win, please put
together a project plan for switching from our current system to
Github.
Err, no. That's a waste of all our time.
It has been stated
Tom Lane wrote:
> Now, running gitlab on community-owned hardware would potentially be an
> option, if we find gitlab attractive from a functionality standpoint.
> The question I'd have about that is whether it has a real development
> community, or is open-source in name only. If github did go
Fujii Masao wrote:
> +if (replorigin_sesssion_origin == InvalidRepOriginId ||
>
> This is not the problem of the patch, but I started wondering what
> "sesssion" in the variable name "replorigin_sesssion_origin" means.
> Is it just a typo and it should be "session"? Or it's the abbreviation
On 09/28/2015 03:40 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>
>> Now, running gitlab on community-owned hardware would potentially be an
>> option, if we find gitlab attractive from a functionality standpoint.
>> The question I'd have about that is whether it has a real development
>>
On 09/28/2015 04:08 PM, Gavin Flower wrote:
JD
Linux kernel project uses bugzilla (https://bugzilla.kernel.org)
and so does LibreOffice (https://bugs.documentfoundation.org)
I think they are both fairly big projects in for the long haul.
I am not anti-bugzilla, just not all that familiar
On Mon, Sep 28, 2015 at 5:47 PM, Jim Nasby wrote:
> There was discussion about making this a PANIC instead of a LOG, which I
> think is a good idea... but then there'd need to be some way to not PANIC if
> you were doing an upgrade.
I think you're worrying about a
* Ryan Pedela (rped...@datalanche.com) wrote:
> I haven't used Gitlab extensively, but it has a feature set similar to
> Github and then some [1]. The OSS project does seem active [2], but it is
> still relatively new.
I've set it up and used it for a relatively small environment and was
*not*
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Josh Berkus writes:
> > The infra team seems to be good with debbugs, and several committers
> > seem to like it, why not go with it?
>
> It certainly seems like debbugs is the proposal to beat at this point.
Agreed.
> In the end
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 09/28/2015 03:40 PM, Alvaro Herrera wrote:
> >We already made a similar choice some years ago when we started
> >depending on the then-recently open sourced SourceForge code for
> >pgFoundry. That didn't turn out all that well in the
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Tuesday, September 29, 2015 5:46 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Etsuro Fujita; PostgreSQL-development; 花田茂
> Subject: Re: [HACKERS] Foreign
On 2015/09/28 20:58, David Rowley wrote:
> On 28 September 2015 at 23:17, Amit Langote
> wrote:
>> Moreover, would partial aggregation work below Append?
>>
>
> Do you mean for cases like:
>
> create table a as select x.x a from generate_series(1,100) x(x);
>
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Tuesday, September 29, 2015 12:08 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Amit Kapila; Andres Freund; pgsql-hackers
> Subject: Re: [HACKERS] CustomScan
1 - 100 of 112 matches
Mail list logo