On 29 October 2015 at 15:35, Amit Langote
wrote:
> errmsg_plural() function determines whether to output the singular version
> or the plural
>
Duh. Thanks Amit!
Should have noticed the function-name change.
--
Robins Tharakan
On Tue, Oct 27, 2015 at 6:29 AM, Rajeev rastogi
wrote:
> On 23 October 2015 01:58, Robert Haas [mailto:robertmh...@gmail.com] Wrote:
>>Well, I'm not buying this extra PostmasterIsAlive() call on every pass
>>through the main loop. That seems more expensive than we can really
>>justify. Checking t
Some of you might have seen that the Greenplum database source code has
been published:
https://adtmag.com/articles/2015/10/28/greenplum-open-sourced.aspx
under the Apache 2.0 license:
http://www.apache.org/licenses/LICENSE-2.0
The source code has known patents owned by Pivotal/
Hi,
I don't really want to discuss patent issues publically.
On 2015-10-30 04:47:35 -0400, Bruce Momjian wrote:
> However, while the license defines and uses "Derivative Works", it does
> not mention that in the patent grant clause. I assume this means that
> patent grants do not apply to derive
On Fri, Oct 30, 2015 at 09:56:48AM +0100, Andres Freund wrote:
> Hi,
>
> I don't really want to discuss patent issues publically.
While we don't want to discuss patented ideas, the patent terms are an
imporant topic here.
> On 2015-10-30 04:47:35 -0400, Bruce Momjian wrote:
> > However, while th
On Wed, Oct 28, 2015 at 5:50 PM, Marko Tiikkaja wrote:
> Here's a patch for the aggregate function outlined by Corey Huinker in
> CADkLM=foA_oC_Ri23F9PbfLnfwXFbC3Lt8bBzRu3=cb77g9...@mail.gmail.com . I
> called it "onlyvalue", which is a horrible name, but I have nothing better
> to offer. (Corey
On Thu, Oct 22, 2015 at 9:21 AM, Andres Freund wrote:
>> Among the five patches marked as ready for committer, one is a bug fix
>> that should be back-patched (ahem). Shouldn't we move on with those
>> entries first?
>
> I think at this point we essentially can just move all entries to the
> next.
On Wed, Oct 28, 2015 at 5:59 PM, Fabio Oliveira De Mendonca
wrote:
> I 've a process with 600.000 rows, for insert on table "A" with 130 columns
> and I'm received the "Exclusivelock" error message, making lost some
> rows during transaction. The insert of transaction occurs on each 2 min.
>
If there is a collate clause in the ORDER BY, the server crashes with
assertion
+Assert(loc_cxt.state == FDW_COLLATE_NONE ||
+loc_cxt.state == FDW_COLLATE_SAFE);
The assertion is fine as long as is_foreign_expr() tests only boolean
expressions (appearing in quals). This patch uses
While testing last night, I discovered a serious case of brain fade in
parallel.c; the same conceptual mistake has also spread to
nodeGather.c. parallel.c creates an array of ParallelWorkerInfo
structures, which are defined like this:
typedef struct ParallelWorkerInfo
{
BackgroundWorkerHa
On Thu, Oct 29, 2015 at 5:41 PM, Fujii Masao wrote:
> I found another strange behavior on track_commit_timestamp.
> Here are the steps to reproduce it.
>
> 1. Start the master and standby servers with track_commit_timestamp enabled.
> Since committs is activated in standby, pg_last_committed_x
2015-10-19 9:52 GMT+02:00 Pavel Stehule :
> Hi,
>
> We cannot to declare variable with referenced type on other composite
> variable. This limit is probably artificial, because any composite type is
> any type too in PostgreSQL.
>
> The issue:
>
> referencing on composite variables doesn't work
>
On Wed, Oct 28, 2015 at 3:55 PM, Kouhei Kaigai wrote:
> At PGconf.EU, I could have a talk with Robert about this topic,
> then it became clear we have same idea.
>
>> ++
>> |sub-plan | * Sub-Plan 1 ... Index Scan on p1
>> |index on *-> * Sub-Plan 2 ... PartialSeqScan on p2
>> |sh
On Thu, Oct 29, 2015 at 6:02 AM, Haribabu Kommi
wrote:
> The security_barrier view option is classified as string in the create
> view documentation.
> But it is actually a boolean. The type is mentioned correctly in alter
> view. Here I attached
> the patch with the correction.
>
> -secur
On Thu, Oct 29, 2015 at 3:29 PM, Oleksii Kliukin wrote:
> Could it be a consequence of how REPEATABLE READ transactions handle
> snapshots? With REPEATABLE READ the snapshot is acquired only once at the
> beginning of a transaction; a READ COMMITTED transaction re-evaluates its
> snapshot with eac
> 30 окт. 2015 г., в 14:30, Robert Haas написал(а):
>
> On Thu, Oct 29, 2015 at 3:29 PM, Oleksii Kliukin wrote:
>> Could it be a consequence of how REPEATABLE READ transactions handle
>> snapshots? With REPEATABLE READ the snapshot is acquired only once at the
>> beginning of a transaction; a R
Heikki Linnakangas writes:
> On 11/25/2014 05:11 PM, Heikki Linnakangas wrote:
>> On 11/24/2014 06:05 PM, Alex Shulgin wrote:
>>> Heikki Linnakangas writes:
>
> It appears that replication connection doesn't support URI but only the
> traditional conninfo string.
>
> src/back
On Fri, Oct 30, 2015 at 12:40 PM, Vladimir Borodin wrote:
> On Thu, Oct 29, 2015 at 3:29 PM, Oleksii Kliukin wrote:
>> Could it be a consequence of how REPEATABLE READ transactions handle
>> snapshots? With REPEATABLE READ the snapshot is acquired only once at the
>> beginning of a transaction; a R
On 2015-10-30 13:42:19 +0100, Michael Paquier wrote:
> On Fri, Oct 30, 2015 at 12:40 PM, Vladimir Borodin wrote:
> > On Thu, Oct 29, 2015 at 3:29 PM, Oleksii Kliukin wrote:
> >> Could it be a consequence of how REPEATABLE READ transactions handle
> >> snapshots? With REPEATABLE READ the snapshot is
On Fri, Oct 30, 2015 at 10:47 AM, Michael Paquier
wrote:
> On Thu, Oct 22, 2015 at 9:21 AM, Andres Freund wrote:
>>> Among the five patches marked as ready for committer, one is a bug fix
>>> that should be back-patched (ahem). Shouldn't we move on with those
>>> entries first?
>>
>> I think at th
On Fri, Oct 30, 2015 at 12:40 PM, Vladimir Borodin wrote:
> I still don’t fully understand why is it so (the problem occurs while
> running only one SELECT-statement in READ COMMITED so only one snapshot is
> taken), but if is expected behavior shouldn’t the documentation mention that
> using READ
I'm still unclear on how to write regression tests for a connectivity bug.
Are they necessary in this case?
On Sun, Oct 25, 2015 at 5:55 PM, Zeus Kronion wrote:
> Parallel workers were failing to connect to the database when running
> pg_dump with a connection string. The first of the following
On Thu, Oct 29, 2015 at 8:29 PM, Peter Eisentraut wrote:
> On 10/28/15 4:18 AM, Victor Wagner wrote:
>> On Mon, 26 Oct 2015 16:25:57 -0400
>> Peter Eisentraut wrote:
>>
>>> Also, this assumes that all the components other than host and port
>>> are the same. Earlier there was a discussion about
On Thu, Oct 29, 2015 at 8:18 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Sep 24, 2015 at 6:36 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Thu, Sep 24, 2015 at 6:32 PM, Andres Freund
>> wrote:
>>
>>> On 2015-09-15 20:16:10 +0300, YUriy Zhuravlev wr
On 30-10-2015 10:04, Zeus Kronion wrote:
I'm still unclear on how to write regression tests for a connectivity
bug. Are they necessary in this case?
There aren't regression tests for pg_dump. However, your instructions
are sufficient to demonstrate the bug.
You could continue the thread in -b
> 30 окт. 2015 г., в 16:04, Robert Haas написал(а):
>
> On Fri, Oct 30, 2015 at 12:40 PM, Vladimir Borodin wrote:
>> I still don’t fully understand why is it so (the problem occurs while
>> running only one SELECT-statement in READ COMMITED so only one snapshot is
>> taken), but if is expected
Robert Haas writes:
> Hmm. ProcessInterrupts() signals some FATAL errors while the
> connection is idle, and rumor has it that that works: the client
> doesn't immediately read the FATAL error, but the next time it sends a
> query, it tries to read from the connection and sees the FATAL error
> a
[2015082503-pgconfig_controldata.diff]
I tried to build this, and the patch applies cleanly but then a ld error
emerges:
(The first four lines (about gram.y) are standard warnings; the error
starts from the ld line)
In file included from gram.y:14908:0:
scan.c: In function ‘yy_try_NUL_t
On 10/29/2015 03:51 PM, Tom Lane wrote:
> We don't need hasty patches. What we need is a re-think of the division
> of labor between pg_dump and pg_dumpall. Up to now, pg_dump has only been
> charged with dumping/restoring the data "inside" an individual database,
> not with handling any databa
On Fri, 30 Oct 2015 14:26:45 +0100
Robert Haas wrote:
> On Thu, Oct 29, 2015 at 8:29 PM, Peter Eisentraut
> wrote:
>
> That's true, but doesn't allowing every parameter to be multiply
> specified greatly increase the implementation complexity for a pretty
> marginal benefit? I think host and
Hi,
Thanks for benchmarking!
On 2015-10-30 16:28:22 +0300, Alexander Korotkov wrote:
> pinunpin-cas-original-fix.patch is just original patch by Andres Freund
> with fixed bug which causes hang.
> Performance comparison on 72-cores Intel server in attached. On this
> machine we see no regression
On Fri, Sep 18, 2015 at 10:21 AM, Fabien COELHO wrote:
>
> Hello Kyotaro-san,
>
> My description should have been obscure. Indeed the call tree is
>> finite for *sane* expression node. But it makes infinit call for
>> a value of expr->etype unknown by both evalDouble and
>> evalInt.
>>
>
> Such i
On Thu, Oct 29, 2015 at 5:31 PM, Colin 't Hart wrote:
> Hi,
>
> I've been reading
>
> wiki.postgresql.org/images/2/25/Full-text_search_in_PostgreSQL_in_milliseconds-extended-version.pdf
> with interest and am wondering if these patches ever made it in to the
> "official" version of Postgresql?
>
On 2015-10-30 09:48:33 -0400, Tom Lane wrote:
> Robert Haas writes:
> > Hmm. ProcessInterrupts() signals some FATAL errors while the
> > connection is idle, and rumor has it that that works: the client
> > doesn't immediately read the FATAL error, but the next time it sends a
> > query, it tries
Hi!
On Fri, Oct 30, 2015 at 5:12 PM, Andres Freund wrote:
> On 2015-10-30 16:28:22 +0300, Alexander Korotkov wrote:
> > pinunpin-cas-original-fix.patch is just original patch by Andres Freund
> > with fixed bug which causes hang.
> > Performance comparison on 72-cores Intel server in attached. O
On Fri, Oct 30, 2015 at 2:42 PM, Euler Taveira wrote:
> On 30-10-2015 10:04, Zeus Kronion wrote:
>>
>> I'm still unclear on how to write regression tests for a connectivity
>> bug. Are they necessary in this case?
>>
> There aren't regression tests for pg_dump. However, your instructions are
> suf
Andres Freund writes:
> adding a parseInput(conn) into the loop yields the expected
> FATAL: 57P01: terminating connection due to unexpected postmaster exit
> Is there really any reason not to do that?
Might work, but it probably needs some study:
(a) is it safe
(b) is this the right place / are
On 2015-10-30 10:57:45 -0400, Tom Lane wrote:
> Andres Freund writes:
> > adding a parseInput(conn) into the loop yields the expected
> > FATAL: 57P01: terminating connection due to unexpected postmaster exit
> > Is there really any reason not to do that?
>
> Might work, but it probably needs so
Thanks Robert.
I read the material link and did help me to take a new decision
thank you.
att.
Fabio Mendonça
De: Robert Haas
Enviado: sexta-feira, 30 de outubro de 2015 07:49
Para: Fabio Oliveira De Mendonca
Cc: k...@it.is.rice.edu; gsst...@mit.e
On 30 October 2015 at 09:26, Robert Haas wrote:
>
> On Thu, Oct 29, 2015 at 8:29 PM, Peter Eisentraut wrote:
> > On 10/28/15 4:18 AM, Victor Wagner wrote:
> >> On Mon, 26 Oct 2015 16:25:57 -0400
> >> Peter Eisentraut wrote:
> >>
> >>> Also, this assumes that all the components other than host an
On Fri, Oct 30, 2015 at 11:29:09AM -0400, Christopher Browne wrote:
> On 30 October 2015 at 09:26, Robert Haas wrote:
> >
> > On Thu, Oct 29, 2015 at 8:29 PM, Peter Eisentraut wrote:
> > > On 10/28/15 4:18 AM, Victor Wagner wrote:
> > >> On Mon, 26 Oct 2015 16:25:57 -0400
> > >> Peter Eisentraut
> On Wed, Oct 28, 2015 at 3:55 PM, Kouhei Kaigai wrote:
> > At PGconf.EU, I could have a talk with Robert about this topic,
> > then it became clear we have same idea.
> >
> >> ++
> >> |sub-plan | * Sub-Plan 1 ... Index Scan on p1
> >> |index on *-> * Sub-Plan 2 ... PartialSeqSca
Here is a v12 which implements the suggestions below.
Should we not allow for functions taking 0 arguments? Since we're already
into some math here, how about pi()? ;-)
Hmmm, why not.
I understand requiring at least 1 arg simplifies the code a bit, but right
now it reports syntax error for
On 10/30/2015 08:29 AM, Christopher Browne wrote:
> I think it makes the feature WORSE. I am getting more and more convinced
> that the Correct Solution is for this feature to be handled by submitting
> multiple URIs, and my argument isn't even based on any aspects of
> implementation complexity.
Now I received the authorization to give you an answer to the WHY question!
Because basicly, this project is classified TOP SECTRET.
Well, we know then we have no real avantage to use UTF-32 in comparaison to
UTF-8.
But we need to establish a gateway between two huge networks.
One network is Int
Currently, config/missing isn't being installed. This can lead to
confusing error messages, such as if Perl isn't found and something
needs it [1]. Attached patch adds it to install and uninstall recipes.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data
Andreas, can you please weigh in here since your voice is important to
this process?
Robbie Harwood writes:
> Andres Freund writes:
>
>> On 2015-10-22 16:47:09 +0900, Michael Paquier wrote:
>>> Hm, and that's why you chose this way of going. My main concern about
>>> this patch is that it adds
Idle hanging transactions from poorly written applications are the
bane of my existence. Several months back one of them took down one
of hour production websites for several hours.
Unfortunately, the only way to deal with them is to terminate the
backend which is heavy handed and in some cases c
Please take it as a very naive and basic approach :-)
What could go wrong here?
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 36863df..57a50b5 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -5169,9 +5169,9 @@ getTables(Archive *fout, DumpO
On Thu, Oct 29, 2015 at 10:31 PM, David Fetter wrote:
> Had this been part of the original ALTER DEFAULT PRIVILEGES patch,
> those privileges would simply have been applied. Since it wasn't, I'm
> ass-u-me'ing that changing the default behavior to that is going to
> cause (possibly legitimate) an
On Fri, Oct 30, 2015 at 2:02 PM, Robert Haas wrote:
> On Fri, Oct 30, 2015 at 10:47 AM, Michael Paquier wrote:
>> On Thu, Oct 22, 2015 at 9:21 AM, Andres Freund wrote:
Among the five patches marked as ready for committer, one is a bug fix
that should be back-patched (ahem). Shouldn't we m
On 2015-10-31 00:42:54 +0100, Michael Paquier wrote:
> On Fri, Oct 30, 2015 at 2:02 PM, Robert Haas wrote:
> > On Fri, Oct 30, 2015 at 10:47 AM, Michael Paquier wrote:
> >> On Thu, Oct 22, 2015 at 9:21 AM, Andres Freund wrote:
> Among the five patches marked as ready for committer, one is a bu
Andres Freund writes:
> On 2015-10-31 00:42:54 +0100, Michael Paquier wrote:
>> On Fri, Oct 30, 2015 at 2:02 PM, Robert Haas wrote:
>>> Gosh, that's a lot of stuff that didn't get reviewed. :-(
>> Yep.
> Yea, this is probably one of the worst commitfests ever from the point
> of reviewer partic
On Wed, Oct 28, 2015 at 01:04:12AM +0100, Robert Haas wrote:
> Well, OK. That's not strictly a correctness issue, but here's an
> updated patch along the lines you suggested.
> Finally, have setup_param_list set a new ParamListInfo field,
> paramMask, to the parameters actually used in the expre
On Sat, Oct 31, 2015 at 2:50 AM, Merlin Moncure wrote:
>
> Idle hanging transactions from poorly written applications are the
> bane of my existence. Several months back one of them took down one
> of hour production websites for several hours.
>
> Unfortunately, the only way to deal with them is
On Thu, Oct 8, 2015 at 11:05 PM, Simon Riggs wrote:
>
> On 1 October 2015 at 23:30, Josh Berkus wrote:
>>
>> On 10/01/2015 07:43 AM, Robert Haas wrote:
>> > On Thu, Oct 1, 2015 at 9:44 AM, Fujii Masao
wrote:
>> >> I wonder how much it's worth renaming only the file extension while
>> >> there ar
On Sat, Oct 31, 2015 at 12:55 AM, Andres Freund wrote:
> On 2015-10-31 00:42:54 +0100, Michael Paquier wrote:
>> On Fri, Oct 30, 2015 at 2:02 PM, Robert Haas wrote:
>> > On Fri, Oct 30, 2015 at 10:47 AM, Michael Paquier wrote:
>> >> On Thu, Oct 22, 2015 at 9:21 AM, Andres Freund wrote:
>> Amo
On Fri, Oct 30, 2015 at 11:24 AM, Robert Haas wrote:
> The other way to fix this is to pass down the index
> that the leader assigns to any given worker, and have the worker use
> that index instead of allocating its own separate index after
> connecting to the DSM segment. Unfortunately, there's
On Thu, Sep 10, 2015 at 3:52 PM, Костя Кузнецов wrote:
> Hello. I am student from gsoc programm.
> My project is sequantial access in vacuum of gist.
>
> New vacuum has 2 big step:
> physical order scan pages and cleaning after 1 step.
>
>
> 1 scan - scan all pages and create information map(hashm
59 matches
Mail list logo