Hi,
On 27/01/14 11:44, Rajeev rastogi wrote:
I have checked the revised patch. It looks fine to me except one minor code
formatting issue.
In elog.c, two tabs are missing in the definition of function
errdetail_log_plural.
Please run pgindent tool to check the same.
I did, but this
On 01/24/2014 07:16 PM, Dean Rasheed wrote:
think recursively calling the rewriter
to expand view references in the new RLS qual, and
expand_security_qual() to expand any additional RLS quals in the
securityQuals list
With this, it'd be helpful if expand_security_qual(...) took a
I noticed a minor omission in the patch as committed. Attached patch
corrects this.
--
Peter Geoghegan
*** a/contrib/pg_stat_statements/pg_stat_statements.c
--- b/contrib/pg_stat_statements/pg_stat_statements.c
*** generate_normalized_query(pgssJumbleStat
*** 2726,2732
if
On Tue, Jan 28, 2014 at 6:11 AM, Amit Kapila amit.kapil...@gmail.comwrote:
On Tue, Jan 28, 2014 at 9:26 AM, Fujii Masao masao.fu...@gmail.com
wrote:
Hi,
The files in pg_stat_tmp directory don't need to be backed up because
they are
basically reset at the archive recovery. So I think
I observed below WIN32 compilation warnings in postmaster.c (seems introduced
by commit ea9df812d8502fff74e7bc37d61bdc7d66d77a7f Relax the requirement that
all lwlocks be stored in a single array.).
1.\src\backend\postmaster\postmaster.c(5625) : warning C4133:
'=' :
On 28/01/14, Christian Kruse wrote:
I have checked the revised patch. It looks fine to me except one
minor code formatting issue.
In elog.c, two tabs are missing in the definition of function
errdetail_log_plural.
Please run pgindent tool to check the same.
I did, but this reformats
As part of the below commit
36a35c550ac114caa423bcbe339d3515db0cd957 (Compress GIN posting
lists, for smaller index size.)
Function GinDataPageAddItemPointer definition was removed but corresponding
prototype was still there.
Attached is the patch to fix the same.
Thanks and
Hello, Thank you, and I' sorry to have kept you waiting.
Let's focus on type 3; Tom and I both found it most promising.
Agreed.
The attached two patches are rebased to current 9.4dev HEAD and
make check at the topmost directory and src/test/isolation are
passed without error. One bug was
On 28 January 2014 04:10, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
AFAICS the only area of objection is the handling of inherited
relations, which occurs within the planner in the current patch. I can
see that would be a cause for concern since the planner is pluggable
and it would then
(2014/01/28 15:17), Rajeev rastogi wrote:
On 27th January, Mitsumasa KONDO wrote:
2014-01-26 Simon Riggs si...@2ndquadrant.com
mailto:si...@2ndquadrant.com
On 21 January 2014 19:48, Simon Riggs si...@2ndquadrant.com
mailto:si...@2ndquadrant.com wrote:
On 21 January 2014
On 01/28/2014 04:39 PM, Craig Ringer wrote:
I'm looking for where I found the code that already does this so I can
point and say I'm not crazy, we already do it here. Will follow up
with a patch.
I spoke to soon. The code I'm talking about is
expand_inherited_tables(...) and it still uses
On 27/01/14 18:00, Simon Riggs wrote:
On 27 January 2014 17:44, Pavel Stehule pavel.steh...@gmail.com wrote:
This topic is interesting - we found very bad performance with hashing large
tables with high work_mem. MergeJoin with quicksort was significantly
faster.
I've seen this also.
I
On Tue, Jan 28, 2014 at 7:51 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
I didn't test it, but I worry that overhead might be high.
If it's true then it could be like constraint_exclusion option which id off
by default because of planning overhead.
I see, that makes sense.
I will try
Le lundi 27 janvier 2014 13:42:29 Christian Convey a écrit :
On Sun, Jan 26, 2014 at 5:47 AM, Craig Ringer cr...@2ndquadrant.com
wrote:
On 01/21/2014 07:43 PM, Christian Convey wrote:
Does anyone know if this has been done before with Postgres? I
would
have assumed yes, but I'm not
2013-11-01 Payal Singh pa...@omniti.com:
The post was made before I subscribed to the mailing list, so posting my
review separately. The link to the original patch mail is
http://www.postgresql.org/message-id/CAB8KJ=jS-Um4TGwenS5wLUfJK6K4rNOm_V6GRUj+tcKekL2=g...@mail.gmail.com
Hi,
This
Hello,
Currently there is no way user can keep the dsm
segments if he wants for postmaster lifetime, so I
have exposed a new API dsm_keep_segment()
to implement the same.
I had a short look on this patch.
- DSM implimentation seems divided into generic part (dsm.c) and
platform
On 2014-01-28 09:13:15 +, Rajeev rastogi wrote:
I observed below WIN32 compilation warnings in postmaster.c (seems introduced
by commit ea9df812d8502fff74e7bc37d61bdc7d66d77a7f Relax the requirement
that all lwlocks be stored in a single array.).
On 01/27/2014 09:20 PM, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I spent some time whacking this around, new patch version attached.
I moved the mmap() code into a new function, that leaves the
PGSharedMemoryCreate more readable.
Did this patch go anywhere?
Oh darn, I remembered we
Hi,
On 28/01/14 13:51, Heikki Linnakangas wrote:
Oh darn, I remembered we had already committed this, but clearly not. I'd
love to still get this into 9.4. The latest patch (hugepages-v5.patch) was
pretty much ready for commit, except for documentation.
I'm working on it. I ported it to HEAD
On Tue, Jan 28, 2014 at 5:42 AM, Cédric Villemain ced...@2ndquadrant.comwrote:
...
As written in the meeting notes, Tom Lane revealed an interest in
pluggable storage. So it might be interesting to check that.
https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting
Thanks. I just
(2014/01/27 21:49), Shigeru Hanada wrote:
2014-01-27 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/01/25 11:27), Shigeru Hanada wrote:
Yeah, the consistency is essential for its ease of use. But I'm not sure
that inherited stats ignoring foreign tables is actually useful for query
Hi,
On 15/11/13 15:17, Heikki Linnakangas wrote:
I spent some time whacking this around, new patch version attached. I moved
the mmap() code into a new function, that leaves the PGSharedMemoryCreate
more readable.
I think there's a bug in this version of the patch. Have a look at
this:
+
On 01/13/2014 07:17 PM, Alexander Korotkov wrote:
Here goes a desription of this patch same as in original thread.
KNN-GiST provides ability to get ordered results from index, but this order
is based only on index information. For instance, GiST index contains
bounding rectangles for polygons,
Hello Sawada,
- This patch is not patched to master branch
Sorry, My mistake
//new connections are not allowed
Corrected.
I hope now the patch in better state, if somthing left, I will be glad to fix
it
Regards
On Tuesday, January 28, 2014 4:17 AM, Sawada Masahiko sawada.m...@gmail.com
On Thu, Jan 9, 2014 at 11:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
On Thu, Jan 9, 2014 at 9:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In short then, I think we should just add this to EXPLAIN and be done.
-1 for sticking the info into PlannedStmt or anything
On Tue, Jan 28, 2014 at 5:54 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 01/13/2014 07:17 PM, Alexander Korotkov wrote:
Here goes a desription of this patch same as in original thread.
KNN-GiST provides ability to get ordered results from index, but this
order
is based only
Hello,
Today, I have noticed that ./configure does not return an error when bison and
flex are missing. Is this intended ?
OS: Ubuntu 13.04
Regards
On 01/28/2014 04:14 PM, salah jubeh wrote:
Today, I have noticed that ./configure does not return an error when bison and
flex are missing. Is this intended ?
Yes. Bison and flex are not required when building from a source
tarball, because the tarball includes the generated files. If
Yes. Bison and flex are not required when building from a source
tarball, because the tarball includes the generated files. If you're
building from a git checkout, however, then you need bison and flex. You
will get an error at make, and IIRC a warning at ./configure
Thanks for the quick
On Mon, Jan 27, 2014 at 9:43 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of patches for nested hstore and jsonb.
Because it's so large I've broken this into two patches and compressed
them. The jsonb patch should work
On 01/28/2014 04:28 PM, salah jubeh wrote:
Yes. Bison and flex are not required when building from a source
tarball, because the tarball includes the generated files. If you're
building from a git checkout, however, then you need bison and flex. You
will get an error at make, and IIRC a warning
On Mon, Jan 27, 2014 at 08:57:26PM +, Simon Riggs wrote:
We get the new behaviour by default and I expect we'll be very happy with it.
A second thought is that if we have problems of some kind in the field
as a result of the new lock modes then we will be able to turn them
off. I'm happy
Hello Heikki,
Thanks for sharing.
Reagrds
On Tuesday, January 28, 2014 3:48 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 01/28/2014 04:28 PM, salah jubeh wrote:
Yes. Bison and flex are not required when building from a source
tarball, because the tarball includes the
On 01/28/2014 09:38 AM, Merlin Moncure wrote:
On Mon, Jan 27, 2014 at 9:43 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of patches for nested hstore and jsonb.
Because it's so large I've broken this into two patches and
On 01/28/2014 05:55 AM, Ian Lawrence Barwick wrote:
Hi Payal
Many thanks for the review, and my apologies for not getting back to
you earlier.
Updated version of the patch attached with suggested corrections.
On a very quick glance, I see that you have still not made adjustments
to
On Tue, Jan 28, 2014 at 1:18 AM, Craig Ringer cr...@2ndquadrant.com wrote:
I'm about to have to add _another_ flag to RangeTblEntry, to track
row-security expansion.
In the process I noticed the comment:
/*
* XXX the fields applicable to only some rte kinds should be
* merged
Looks like this review is against jsonb-5, not jsonb-6.
oh yep -- shoot, sorry for the noise.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jan 25, 2014 at 2:33 AM, Magnus Hagander mag...@hagander.net wrote:
With that many options of hiding it, I would still argue for just picking
one of those.
For example, of Heroku wants to protect their customers against the
behaviour of the pg gem, you can for example set PGAPPNAME
2014-01-29 Andrew Dunstan and...@dunslane.net:
On 01/28/2014 05:55 AM, Ian Lawrence Barwick wrote:
Hi Payal
Many thanks for the review, and my apologies for not getting back to
you earlier.
Updated version of the patch attached with suggested corrections.
On a very quick glance, I see
Andrew Dunstan wrote:
para
+There are two JSON data types: typejson/type and typejsonb/type.
+Both accept identical sets of values as input. The difference is
primarily
+a matter of efficiency. The typejson/type data type stores an exact
+copy of the the input text, and
Greg Stark st...@mit.edu writes:
The problem with that is that it doesn't just hide it. It removes the
debugging information altogether. Even the administrator of the
application itself and the DBA won't have this information. The reason
the Gem is putting that information in application_name
Hi,
just a word of warning: it seems as if there is compiler bug in clang
regarding the ternary operator when used in ereport(). While working
on a patch I found that this code:
ereport(FATAL,
(errmsg(could not map anonymous shared memory:
%m),
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 28, 2014 at 1:18 AM, Craig Ringer cr...@2ndquadrant.com wrote:
In the process I noticed the comment:
/*
* XXX the fields applicable to only some rte kinds should be
* merged into a union. I didn't do this yet because the diffs
* would
Sorry, i can't receive mailing :(
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Christian Convey christian.con...@gmail.com writes:
On Tue, Jan 28, 2014 at 5:42 AM, Cédric Villemain
ced...@2ndquadrant.comwrote:
As written in the meeting notes, Tom Lane revealed an interest in
pluggable storage. So it might be interesting to check that.
On 2014-01-28 07:27:52 -0800, Greg Stark wrote:
And all of that without removing a valuable debugging/tracing tool from
other users.
Why is application_name useful for users who aren't the DBA and aren't
the user in question. The sql_query would probably be more useful than
On 01/20/2014 10:34 PM, Andrew Dunstan wrote:
On 01/20/2014 09:58 PM, Laurence Rowe wrote:
Following the discussion on pgsql-general, I thought I'd have a go
implementing json_array_elements_text following the same pattern as
json_each_text. The function makes it possible to join elements of
Hi,
when I remove the errno comparison and use a 1 it works:
ereport(FATAL,
(errmsg(could not map anonymous shared memory: %m),
1 ?
errhint(This error usually means that PostgreSQL's request
for a shared memory segment exceeded available memory
On 01/28/2014 10:50 AM, Alvaro Herrera wrote:
+ /indextermindexterm
+ primaryjsonb_each/primary
+ /indextermparaliteraljson_each(json)/literal
+ /paraparaliteraljsonb_each(jsonb)/literal
+ /para/entry
This SGML nesting is odd and hard to read. Please
Andrew Dunstan and...@dunslane.net writes:
On 01/28/2014 10:50 AM, Alvaro Herrera wrote:
+ /indextermindexterm
+ primaryjsonb_each/primary
+ /indextermparaliteraljson_each(json)/literal
+ /paraparaliteraljsonb_each(jsonb)/literal
+ /para/entry
This
Hi,
attached you will find a new version of the patch, ported to HEAD,
fixed the mentioned bug and - hopefully - dealing the the remaining
issues.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
diff --git
On Mon, Jan 27, 2014 at 02:51:59PM -0800, Kevin Grittner wrote:
So anyway, *I* would object to applying that; it was meant to
illustrate what the comment, if any, should cover; not to be an
actual code change. I don't think the change that was pushed helps
that comment carry its own weight,
On 2014-01-28 11:14:49 -0500, Bruce Momjian wrote:
On Mon, Jan 27, 2014 at 02:51:59PM -0800, Kevin Grittner wrote:
So anyway, *I* would object to applying that; it was meant to
illustrate what the comment, if any, should cover; not to be an
actual code change. I don't think the change that
Christian Kruse christ...@2ndquadrant.com writes:
just a word of warning: it seems as if there is compiler bug in clang
regarding the ternary operator when used in ereport(). While working
on a patch I found that this code:
...
did not emit a errhint when using clang, although errno == ENOMEM
On 01/28/2014 11:09 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/28/2014 10:50 AM, Alvaro Herrera wrote:
+ /indextermindexterm
+ primaryjsonb_each/primary
+ /indextermparaliteraljson_each(json)/literal
+
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/28/2014 10:50 AM, Alvaro Herrera wrote:
+ /indextermindexterm
+ primaryjsonb_each/primary
+ /indextermparaliteraljson_each(json)/literal
+ /paraparaliteraljsonb_each(jsonb)/literal
+
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Practically every existing use of indexterm is freer than this in its
use of whitespace. It sounds to me like maybe you are trying to put the
indexterm inside something it shouldn't go inside of.
FWIW I was just talking about
On 01/28/2014 11:27 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Practically every existing use of indexterm is freer than this in its
use of whitespace. It sounds to me like maybe you are trying to put the
indexterm inside something it shouldn't go
On 28 January 2014 14:55, Bruce Momjian br...@momjian.us wrote:
On Mon, Jan 27, 2014 at 08:57:26PM +, Simon Riggs wrote:
We get the new behaviour by default and I expect we'll be very happy with it.
A second thought is that if we have problems of some kind in the field
as a result of the
On Tue, Jan 28, 2014 at 09:42:37AM +, Rajeev rastogi wrote:
As part of the below commit
36a35c550ac114caa423bcbe339d3515db0cd957 (Compress GIN posting
lists, for smaller index size.)
Function GinDataPageAddItemPointer definition was removed but corresponding
Andrew Dunstan and...@dunslane.net writes:
The problem is not the indexterm element, it's the space that might
exist outside it. Are we using block level elements like para inside
entry elements anywhere else?
Probably not, and I wonder why you're trying to. Whole paras inside
a table entry
On 27 January 2014 16:20, Andres Freund and...@2ndquadrant.com wrote:
Hi,
Here's the next version of the patchset. The following changes have been
made:
* move xmin pegging and more logic responsibility to procarray.c
* split all support for changeset extraction from the initial slot patch
On 01/28/2014 11:29 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The problem is not the indexterm element, it's the space that might
exist outside it. Are we using block level elements like para inside
entry elements anywhere else?
Probably not, and I wonder why you're
On Mon, Jan 27, 2014 at 10:00 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 27 January 2014 17:44, Pavel Stehule pavel.steh...@gmail.com wrote:
This topic is interesting - we found very bad performance with hashing
large
tables with high work_mem. MergeJoin with quicksort was
On Tue, Jan 28, 2014 at 11:49 AM, Thom Brown t...@linux.com wrote:
On 27 January 2014 16:20, Andres Freund and...@2ndquadrant.com wrote:
Hi,
Here's the next version of the patchset. The following changes have been
made:
* move xmin pegging and more logic responsibility to procarray.c
*
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-28 11:14:49 -0500, Bruce Momjian wrote:
OK, so does anyone object to removing this comment line?
Let's just not do anything. This is change for changes sake. Not
improving anything the slightest.
Indeed. I'd actually request that you
On 01/27/2014 07:03 PM, Amit Kapila wrote:
I have tried to improve algorithm in another way so that we can get
benefit of same chunks during find match (something similar to lz).
The main change is to consider chunks at fixed boundary (4 byte)
and after finding match, try to find if there is a
On Tue, Jan 28, 2014 at 04:36:39PM +, Simon Riggs wrote:
For me, reducing the strength of DDL locking is a major change in
RDBMS behaviour that could both delight and surprise our users. Maybe
a few actually depend upon the locking behaviour, maybe. After some
years of various people
On Tue, Jan 28, 2014 at 11:20:39AM -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-28 11:14:49 -0500, Bruce Momjian wrote:
OK, so does anyone object to removing this comment line?
Let's just not do anything. This is change for changes sake. Not
improving
On 01/28/2014 07:15 PM, Bruce Momjian wrote:
On Tue, Jan 28, 2014 at 04:36:39PM +, Simon Riggs wrote:
For me, reducing the strength of DDL locking is a major change in
RDBMS behaviour that could both delight and surprise our users. Maybe
a few actually depend upon the locking behaviour,
On Tue, Jan 28, 2014 at 07:21:50PM +0200, Heikki Linnakangas wrote:
I have no problem removing the parameter if required to. In that case,
I would like to leave the parameter in until mid beta, to allow
greater certainty. In any case, I would wish to retain as a minimum an
extern bool variable
There are a couple of really huge issues that would have to be argued out
before any progress could be made.
Is this something that people want to spend time on right now? As I
mentioned earlier, I'm game. But it doesn't sound like I'll get very far
without adult supervision.
On Tue, Jan 28, 2014 at 02:25:51PM -0300, Alvaro Herrera wrote:
Bruce Momjian escribió:
On Tue, Jan 28, 2014 at 11:20:39AM -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-28 11:14:49 -0500, Bruce Momjian wrote:
OK, so does anyone object to removing this
On 2014-01-28 12:29:25 -0500, Bruce Momjian wrote:
On Tue, Jan 28, 2014 at 02:25:51PM -0300, Alvaro Herrera wrote:
Bruce Momjian escribió:
On Tue, Jan 28, 2014 at 11:20:39AM -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-28 11:14:49 -0500, Bruce
On 01/28/2014 07:26 PM, Bruce Momjian wrote:
On Tue, Jan 28, 2014 at 07:21:50PM +0200, Heikki Linnakangas wrote:
I have no problem removing the parameter if required to. In that case,
I would like to leave the parameter in until mid beta, to allow
greater certainty. In any case, I would wish to
On 01/28/2014 04:12 PM, Alexander Korotkov wrote:
On Tue, Jan 28, 2014 at 5:54 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
4. (as you mentioned in the other thread: ) It's a modularity violation
that you peek into the heap tuple from gist. I think the proper way to do
this would be
I think sort by string column is lower during merge join, maybe comparing
function in sort need be refined to save some cycle. It’s the hot function when
do sort.
Heikki Linnakangas hlinnakan...@vmware.com编写：
On 01/27/2014 07:03 PM, Amit Kapila wrote:
I have tried to improve algorithm in
Bruce Momjian escribió:
On Tue, Jan 28, 2014 at 11:20:39AM -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-28 11:14:49 -0500, Bruce Momjian wrote:
OK, so does anyone object to removing this comment line?
Let's just not do anything. This is change for
Peter Geoghegan p...@heroku.com writes:
I noticed a minor omission in the patch as committed. Attached patch
corrects this.
Duh. Thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hi all,
Application to Google Summer of Code 2014 can be made as of next
Monday (3rd Feb), and then there will be a 12 day window in which to
submit an application.
I'd like to gauge interest from both mentors and students as to
whether we'll want to do this.
And I'd be fine with being admin
On Tue, Jan 28, 2014 at 07:30:47PM +0200, Heikki Linnakangas wrote:
On 01/28/2014 07:26 PM, Bruce Momjian wrote:
On Tue, Jan 28, 2014 at 07:21:50PM +0200, Heikki Linnakangas wrote:
I have no problem removing the parameter if required to. In that case,
I would like to leave the parameter in
Christian Convey christian.con...@gmail.com writes:
There are a couple of really huge issues that would have to be argued out
before any progress could be made.
Is this something that people want to spend time on right now? As I
mentioned earlier, I'm game. But it doesn't sound like I'll
On Tue, Jan 28, 2014 at 06:30:40PM +0100, Andres Freund wrote:
OK, reverted. I have to question how well-balanced we are when a word
change in a C comment can cause so much contention.
The question is rather why to do such busywork changes in the first
place imo. Without ever looking at
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Honestly, I would prefer that we push a patch that has been thoroughly
reviewed and in which we have more confidence, so that we can push
without a GUC. This means mark in CF as needs-review, then some other
developer reviews it and marks it as
Bruce Momjian escribió:
I have no problem removing the parameter if required to. In that case,
I would like to leave the parameter in until mid beta, to allow
greater certainty.
Uhm. If we remove a GUC during beta we don't need to force an initdb.
At worst we will need to keep a no-op GUC
On 28 January 2014 17:15, Bruce Momjian br...@momjian.us wrote:
On Tue, Jan 28, 2014 at 04:36:39PM +, Simon Riggs wrote:
For me, reducing the strength of DDL locking is a major change in
RDBMS behaviour that could both delight and surprise our users. Maybe
a few actually depend upon the
On Tue, Jan 28, 2014 at 11:04 PM, Thom Brown t...@linux.com wrote:
Hi all,
Application to Google Summer of Code 2014 can be made as of next
Monday (3rd Feb), and then there will be a 12 day window in which to
submit an application.
I'd like to gauge interest from both mentors and students
On Tue, Jan 28, 2014 at 11:16 PM, Atri Sharma atri.j...@gmail.com wrote:
On Tue, Jan 28, 2014 at 11:04 PM, Thom Brown t...@linux.com wrote:
Hi all,
Application to Google Summer of Code 2014 can be made as of next
Monday (3rd Feb), and then there will be a 12 day window in which to
On 2014-01-27 15:25:22 -0500, Robert Haas wrote:
On Mon, Jan 27, 2014 at 12:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
This version adds a GUC called ddl_exclusive_locks which allows us to
keep the 9.3 behaviour if we wish it. Some people may be surprised
that their programs don't wait
On 28 January 2014 17:21, Heikki Linnakangas hlinnakan...@vmware.com wrote:
I don't understand why anyone would want to turn this feature off, ie.
require stronger locks than necessary for a DDL change.
Nobody would *want* to turn it off. They might need to, as explained.
If we're not
On Tue, Jan 28, 2014 at 10:46 AM, Andrew Dunstan and...@dunslane.net wrote:
On 01/28/2014 11:29 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The problem is not the indexterm element, it's the space that might
exist outside it. Are we using block level elements like para
On Tue, Jan 28, 2014 at 3:42 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Jan 25, 2014 at 3:19 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Jan 25, 2014 at 5:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 23, 2014 at 4:10 PM, Michael Paquier
Anybody knows about this patch?
http://www.postgresql.org/message-id/508dfec9.4020...@uptime.jp
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 01/28/2014 09:58 AM, Merlin Moncure wrote:
yeah. note: I think the json documentation needs *major* overhaul. too
much is going in inside the function listings where there really
should be a big breakout discussing the big picture of json/jsonb
with examples of various use cases. I want to
On 01/27/2014 01:06 PM, Alvaro Herrera wrote:
Andrew Dunstan escribió:
I'm not sure I understand the need. This is the difference between
the _text variants and their parents. Why would you call
json_object_field when you want the dequoted text?
Because I first need to know its type.
On windows, if the client gets terminated while sending data to the server,
in a COPY for example, it results in some rather head-scratcher messages in
the server log, for example:
LOG: could not receive data from client: No connection could be made
because the target machine actively refused
Josh Berkus wrote:
On 01/27/2014 01:06 PM, Alvaro Herrera wrote:
Andrew Dunstan escribió:
I'm not sure I understand the need. This is the difference between
the _text variants and their parents. Why would you call
json_object_field when you want the dequoted text?
Because I first
On Tue, Jan 28, 2014 at 12:09 PM, Josh Berkus j...@agliodbs.com wrote:
On 01/28/2014 09:58 AM, Merlin Moncure wrote:
yeah. note: I think the json documentation needs *major* overhaul. too
much is going in inside the function listings where there really
should be a big breakout discussing the
On Tue, Jan 28, 2014 at 12:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
TBH, I'd rather we waited till the commitfest is over. This is certainly
material for 9.5, if not even further out, so there's no pressing need for
a debate right now; and we have plenty of stuff we do need to deal with
On 01/28/2014 09:46 AM, Atri Sharma wrote:
I would like to bring up the addition to MADLIB algorithms again this year.
Also, some work on the foreign table constraints could be helpful.
We can only take MADLIB this year if we have confirmed mentors who are
MADLIB committers before the end of
1 - 100 of 176 matches
Mail list logo
