(2014/03/07 16:02), KONDO Mitsumasa wrote:
And other cases are classified under following.
\setrandom var min max gaussian #hoge --> uniform
Oh, it's wrong... It will be..
\setrandom var min max gaussian #hoge --> ERROR
Regards,
--
Mitsumasa KONDO
NTT Open Source Software Center
--
Sent vi
Hi,
(2014/03/04 17:42), KONDO Mitsumasa wrote:> (2014/03/04 17:28), Fabien COELHO
wrote:
>>> OK. I'm not sure which idia is the best. So I wait for comments in
community:)
>> Hmmm. Maybe you can do what Tom voted for, he is the committer:-)
> Yeah, but he might change his mind by our disscuttio
Hi all,
In the documentation, particularly the doc index, syslog_ident is
incorrectly mentioned as syslog_identify. The attached patch fixes
that. This error is in the docs since 8.0.
Regards,
--
Michael
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 3743,3749 *
On 03/06/2014 02:58 AM, Tom Lane wrote:
> Craig Ringer writes:
>> One of the remaining issues with row security is how to pass plan
>> invalidation information generated in the rewriter back into the planner.
>
>> With row security, it's necessary to set a field in PlannerGlobal,
>> tracking the
Noah Misch writes:
> On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote:
>> I'm inclined to suggest that we should put the socket under $CWD by
>> default, but provide some way for the user to override that choice.
>> If they want to put it in /tmp, it's on their head as to how secure
>> tha
On Fri, Mar 7, 2014 at 2:03 AM, Tom Lane wrote:
> In the bug thread I proposed making atexit_callback check whether getpid()
> still matches MyProcPid. If it doesn't, then presumably we inherited the
> atexit callback list, along with the value of MyProcPid, from some parent
> backend process who
Back in commit 249a899f7, we introduced an atexit callback that forced
backend process cleanup to occur if some random backend plugin
(I'm looking at you, plperl and plpython) executed exit(). While that
seemed like a great safety feature at the time, bug #9464
http://www.postgresql.org/message-id
On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > Thanks. To avoid socket path length limitations, I lean toward placing the
> > socket temporary directory under /tmp rather than placing under the CWD:
>
> I'm not thrilled with that; it's totally insecure on plat
On Thu, Mar 6, 2014 at 04:33:08PM +0100, Ronan Dunklau wrote:
> > I'm not sure what the constraints of json that you might want to break
> > are. Perhaps you'd like to specify.
>
> I haven't followed the whole thread, but json is really restrictive on the
> supported types: a hierarchical hstore
On Thu, Mar 6, 2014 at 09:50:56PM +0400, Oleg Bartunov wrote:
> Hi there,
>
> Looks like consensus is done. I and Teodor are not happy with it, but
> what we can do :) One thing I want to do is to reserve our
> contribution to the flagship feature (jsonb), particularly, "binary
> storage for n
On Fri, Mar 7, 2014 at 09:07:24AM +0530, Amit Kapila wrote:
> One reason could be that as we are already returning special exit code
> for 'status' option of pg_ctl (exit(3)), this seems to be inline with it as
> this
> also get called during status command.
>
> Also in the link sent by you in a
On Thu, Mar 6, 2014 at 10:43:01PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Mar 6, 2014 at 12:17:55PM -0300, Alvaro Herrera wrote:
> >> Bruce Momjian escribi�:
> >>> Technically, you are right, but I tried a while ago to assign meaningful
> >>> values to all the exit locations a
On Fri, Mar 7, 2014 at 12:36 AM, Tom Lane wrote:
>
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
writes:
> > Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED"
too?
> > Thinking in a scope of one GSoC, of course.
>
> I think it's basically the same thing. You might hope to opti
Bruce Momjian writes:
> On Thu, Mar 6, 2014 at 12:17:55PM -0300, Alvaro Herrera wrote:
>> Bruce Momjian escribió:
>>> Technically, you are right, but I tried a while ago to assign meaningful
>>> values to all the exit locations and the community feedback I got was
>>> that we didn't want that.
>
On Thu, Mar 6, 2014 at 7:46 PM, Bruce Momjian wrote:
> On Thu, Mar 6, 2014 at 09:54:57AM +0530, Amit Kapila wrote:
>> > If they haven't passed us a data directory, we don't really know if the
>> > server is running or not, so the patch just returns '1'.
>>
>> But for such cases, isn't the status
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
> Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED" too?
> Thinking in a scope of one GSoC, of course.
I think it's basically the same thing. You might hope to optimize it;
but you have to create (rather than remove) an init
On Thu, Mar 6, 2014 at 5:04 PM, Robert Haas wrote:
>
> On Thu, Mar 6, 2014 at 2:52 PM, Fabrízio de Royes Mello
> wrote:
> > On Thu, Mar 6, 2014 at 4:42 PM, Robert Haas
wrote:
> >> I think this isn't a good design. Per the discussion between Andres
> >> and I, I think that I think you should do
On Thu, Mar 6, 2014 at 12:17:55PM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
>
> > Technically, you are right, but I tried a while ago to assign meaningful
> > values to all the exit locations and the community feedback I got was
> > that we didn't want that.
>
> That sounds odd. Do
On Thu, Mar 6, 2014 at 08:34:29AM +0100, Antonin Houska wrote:
> >>> You're right. I missed the fact that Postgres (unlike another DBMS that
> >>> I worked with) allows for tablespace to be shared across databases.
> >>
> >> I have update the C comment:
> >>
> >> < * Notice that relNode i
Clustering Summit
-
We will be holding the fourth annual Cluster-Hacker meeting on Tuesday
May 20th, just before pgCon 2014. Everyone with a serious interest in
clustering, replication, and scale-out technologies is welcome and
encouraged to attend.
This meeting will take place f
On Thu, Mar 6, 2014 at 5:05 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Thu, Mar 6, 2014 at 5:04 PM, Robert Haas wrote:
> >
> > On Thu, Mar 6, 2014 at 2:52 PM, Fabrízio de Royes Mello
> > wrote:
> > > On Thu, Mar 6, 2014 at 4:42 PM, Robert Haas
wrote:
> > >> I think th
> I was thinking more like
>
> typedef struct CustomPathFuncs {
> const char *name; /* used for debugging purposes only */
> NodeCopy_function node_copy;
> NodeTextOut_function node_textout;
> ... etc etc etc ...
> } CustomPathFuncs;
>
> typedef struct CustomPath {
>
On 03/06/2014 12:58 PM, Daniele Varrazzo wrote:
> On Thu, Mar 6, 2014 at 6:54 PM, Josh Berkus wrote:
>>
>> The actual storage upgrade of hstore-->hstore2 is fairly painless from
>> the user perspective; they don't have to do anything. The problem is
>> that the input/output strings are different,
On Thu, Mar 6, 2014 at 11:14 PM, Robert Haas wrote:
>> I've been tempted to implement a new type of hash index that allows both WAL
>> and high concurrency, simply by disallowing bucket splits. At the index
>> creation time you use a storage parameter to specify the number of buckets,
>> and that
On 6 March 2014 22:43, Noah Misch wrote:
> Good analysis. The hazards arise when pg_dump uses one of the ruleutils.c
> deparse worker functions.
Ah, good. We're thinking along the same lines. I was already working
on this analysis also. I'll complete mine and then compare notes.
> One thing no
On Thu, Mar 6, 2014 at 3:44 PM, Jeff Janes wrote:
> On Thu, Mar 6, 2014 at 11:34 AM, Robert Haas wrote:
>> Putting the split-in-progress flag in the new bucket's primary page
>> makes a lot of sense. I don't have any problem with dumping the rest
>> of it for a first cut if we have a different l
On Tue, Mar 04, 2014 at 06:50:17PM +0100, Andres Freund wrote:
> On 2014-03-04 11:40:10 -0500, Tom Lane wrote:
> > Robert Haas writes: > I think this is all too
> > late for 9.4, though.
> >
> > I agree with the feeling that a meaningful fix for pg_dump isn't going
> > to get done for 9.4. So th
Etsuro Fujita writes:
> Maybe I'm missing something. But I don't think
> postgresGetForeignPaths() marks the parameterized path with the correct
> row estimate. Also, that function doesn't seem to estimate the cost of
> the parameterized path correctly. Please find attached a patch.
[ looks at
On Thu, Mar 6, 2014 at 9:10 PM, Peter Geoghegan wrote:
> On Thu, Mar 6, 2014 at 12:58 PM, Daniele Varrazzo
> wrote:
>> Hello, psycopg developer here. Not following the entire thread as it's
>> quite articulated and not of my direct interest (nor comprehension).
>> But if you throw at me a few tes
On Thu, Mar 6, 2014 at 12:58 PM, Daniele Varrazzo
wrote:
> Hello, psycopg developer here. Not following the entire thread as it's
> quite articulated and not of my direct interest (nor comprehension).
> But if you throw at me a few test cases I can make sure psycopg can
> parse them much before hs
On Thu, Mar 6, 2014 at 6:54 PM, Josh Berkus wrote:
>
> The actual storage upgrade of hstore-->hstore2 is fairly painless from
> the user perspective; they don't have to do anything. The problem is
> that the input/output strings are different, something which I didn't
> think to check for (and Pe
On Thu, Mar 6, 2014 at 11:34 AM, Robert Haas wrote:
>
> Putting the split-in-progress flag in the new bucket's primary page
> makes a lot of sense. I don't have any problem with dumping the rest
> of it for a first cut if we have a different long-term plan for how to
> improve concurrency, but I
2014-03-06 21:06 GMT+01:00 Robert Haas :
> On Thu, Mar 6, 2014 at 1:26 AM, Pavel Stehule
> wrote:
> > 2014-03-05 16:22 GMT+01:00 Alvaro Herrera :
> >
> >> Pavel Stehule escribió:
> >> > Hi
> >> >
> >> > I hope, so this patch fix it
> >>
> >> wtf?
> >
> >
> > I tried to fix
> >
> http://git.postgr
On Thu, Mar 6, 2014 at 5:04 PM, Robert Haas wrote:
>
> On Thu, Mar 6, 2014 at 2:52 PM, Fabrízio de Royes Mello
> wrote:
> > On Thu, Mar 6, 2014 at 4:42 PM, Robert Haas
wrote:
> >> I think this isn't a good design. Per the discussion between Andres
> >> and I, I think that I think you should do
On Thu, Mar 6, 2014 at 1:26 AM, Pavel Stehule wrote:
> 2014-03-05 16:22 GMT+01:00 Alvaro Herrera :
>
>> Pavel Stehule escribió:
>> > Hi
>> >
>> > I hope, so this patch fix it
>>
>> wtf?
>
>
> I tried to fix
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f1ba94bcd9717b94b36868d
On Thu, Mar 6, 2014 at 2:52 PM, Fabrízio de Royes Mello
wrote:
> On Thu, Mar 6, 2014 at 4:42 PM, Robert Haas wrote:
>> I think this isn't a good design. Per the discussion between Andres
>> and I, I think that I think you should do is make ALTER TABLE .. SET
>> LOGGED work just like VACUUM FULL,
On Thu, Mar 6, 2014 at 4:42 PM, Robert Haas wrote:
>
>
> I think this isn't a good design. Per the discussion between Andres
> and I, I think that I think you should do is make ALTER TABLE .. SET
> LOGGED work just like VACUUM FULL, with the exception that it will set
> a different relpersistence
On 03/05/2014 10:57 PM, Andres Freund wrote:
On 2014-03-05 18:26:13 +0200, Heikki Linnakangas wrote:
The logic was the same before the patch, but I added the XXX comment above.
Why do we sleep in increments of 1/10 of wal_sender_timeout? Originally, the
code calculated when the next wakeup shoul
On 6 March 2014 19:42, Robert Haas wrote:
> On Wed, Mar 5, 2014 at 7:42 PM, Fabrízio de Royes Mello
> wrote:
> > On Tue, Mar 4, 2014 at 5:00 PM, Fabrízio de Royes Mello
> > wrote:
> >> On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund
> >> wrote:
> >> >
> >> > On 2014-03-04 12:54:02 -0500, Robert
On Wed, Mar 5, 2014 at 7:42 PM, Fabrízio de Royes Mello
wrote:
> On Tue, Mar 4, 2014 at 5:00 PM, Fabrízio de Royes Mello
> wrote:
>> On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund
>> wrote:
>> >
>> > On 2014-03-04 12:54:02 -0500, Robert Haas wrote:
>> > > On Tue, Mar 4, 2014 at 9:50 AM, Andres Fr
On Thu, Mar 6, 2014 at 8:11 AM, Heikki Linnakangas
wrote:
> I don't think it's necessary to improve concurrency just to get WAL-logging.
> Better concurrency is a worthy goal of its own, of course, but it's a
> separate concern.
To some extent, I agree, but only to some extent. To make hash
inde
On Thu, Mar 6, 2014 at 10:54 PM, Josh Berkus wrote:
g?
>
> On 03/06/2014 09:50 AM, Oleg Bartunov wrote:> Looks like consensus is
> done. I and Teodor are not happy with it, but
>> what we can do :) One thing I want to do is to reserve our
>> contribution to the flagship feature (jsonb), particu
On 03/06/2014 07:00 AM, Bruce Momjian wrote:
> What can we do to help people migrate to an hstore type that supports
> data types? Is there a function we can give them to flag possible
> problem data, or give them some function to format things the old way
> for migrations, etc. If they are going
I meant in Release Notes for 9.4
On Thu, Mar 6, 2014 at 10:26 PM, Andrew Dunstan wrote:
>
>
>
>
>
> On 03/06/2014 12:50 PM, Oleg Bartunov wrote:
>>
>> Hi there,
>>
>> Looks like consensus is done. I and Teodor are not happy with it, but
>> what we can do :) One thing I want to do is to reserve
On 03/06/2014 12:50 PM, Oleg Bartunov wrote:
Hi there,
Looks like consensus is done. I and Teodor are not happy with it, but
what we can do :) One thing I want to do is to reserve our
contribution to the flagship feature (jsonb), particularly, "binary
storage for nested structures and in
Kouhei Kaigai writes:
> I expected to include simple function pointers for copying and text-output
> as follows:
> typedef struct {
> Planplan;
> :
> NodeCopy_functionnode_copy;
> NodeTextOut_function node_textout;
> } Custom;
I was thinking more like
typed
Hi there,
Looks like consensus is done. I and Teodor are not happy with it, but
what we can do :) One thing I want to do is to reserve our
contribution to the flagship feature (jsonb), particularly, "binary
storage for nested structures and indexing. Their work was sponsored
by Engine Yard".
A
On Thu, Mar 6, 2014 at 11:28 AM, Heikki Linnakangas
wrote:
> So here my opinion on what we should do:
>
> 1. Forget about hstore2
> 2. Add GIN and GIST operator classes to jsonb, if they're ready for commit
> pretty darn soon. If not, punt them to next release.
For #2, would we maintain the hstor
Noah Misch writes:
> Thanks. To avoid socket path length limitations, I lean toward placing the
> socket temporary directory under /tmp rather than placing under the CWD:
I'm not thrilled with that; it's totally insecure on platforms where /tmp
isn't "sticky", so it doesn't seem like an appropri
On 03/06/2014 05:46 PM, Tom Lane wrote:
Magnus Hagander writes:
However, if the new hstore type (compatible with the old one) is the
wrapper around jsonb, rather than the other way around, I don't see any
problem with it at all. Most future users are almost certainly going to use
the json inter
mohsencs wrote
> I want use CREATE TYPE to create one type similar to char.
> I want to when I create type, then my type behave similar to char:
>
> CREATE TABLE test (oneChar char);
>
> when I want insert one column with length>1 to it, so it gets this error:
> ERROR: value too long for type ch
On 03/06/2014 10:46 AM, Tom Lane wrote:
Magnus Hagander writes:
However, if the new hstore type (compatible with the old one) is the
wrapper around jsonb, rather than the other way around, I don't see any
problem with it at all. Most future users are almost certainly going to use
the json inte
Magnus Hagander writes:
> However, if the new hstore type (compatible with the old one) is the
> wrapper around jsonb, rather than the other way around, I don't see any
> problem with it at all. Most future users are almost certainly going to use
> the json interfaces, but we don't want to leave u
On Thu, Mar 6, 2014 at 4:25 PM, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, just to summarize:
>
> > JSONB and everything it shares with hstore will be in core
> > hstore-specific code stays in contrib
> > hstore contrib will create an hstore type to call contrib and core
>
Le jeudi 6 mars 2014 09:33:18 Andrew Dunstan a écrit :
> On 03/06/2014 08:16 AM, Oleg Bartunov wrote:
> > On Thu, Mar 6, 2014 at 12:43 PM, Peter Geoghegan wrote:
> >> On Thu, Mar 6, 2014 at 12:23 AM, Teodor Sigaev wrote:
> >>> That's possible to introduce GUC variable for i/o functions which will
On Wed, Mar 5, 2014 at 10:49 PM, Tom Lane wrote:
>
> [ shrug... ] They can see whether the Window plan node is where the time
> is going. It's not apparent to me that the extra numbers you propose to
> report will edify anybody.
Perhaps just saying "Incremental Window Function" versus "Iterated
Alvaro Herrera writes:
> Bruce Momjian escribió:
>> Technically, you are right, but I tried a while ago to assign meaningful
>> values to all the exit locations and the community feedback I got was
>> that we didn't want that.
> That sounds odd. Do you have a link?
FWIW, I recall that in my for
Bruce Momjian writes:
> OK, just to summarize:
> JSONB and everything it shares with hstore will be in core
> hstore-specific code stays in contrib
> hstore contrib will create an hstore type to call contrib and core code
> 9.4 hstore has some differences from pre-9.4
I'v
Bruce Momjian escribió:
> Technically, you are right, but I tried a while ago to assign meaningful
> values to all the exit locations and the community feedback I got was
> that we didn't want that.
That sounds odd. Do you have a link?
--
Álvaro Herrerahttp://www.2ndQuadrant.co
On Mar6, 2014, at 00:08 , Bruce Momjian wrote:
> I have addressed this issue with the attached patch:
>
> $ pg_ctl -D /lkjasdf status
> pg_ctl: directory "/lkjasdf" does not exist
> $ pg_ctl -D / status
> pg_ctl: directory "/" is not a database cluster directory
>
> One o
On Thu, Mar 6, 2014 at 09:33:18AM -0500, Andrew Dunstan wrote:
> I hear you, and largely agree, as long as the compatibility issue is
> solved. If it's not, I think inventing a new hstore2 type is
> probably a lousy way to go.
>
> For good or ill, the world has pretty much settled on wanting to u
On 03/06/2014 08:16 AM, Oleg Bartunov wrote:
On Thu, Mar 6, 2014 at 12:43 PM, Peter Geoghegan wrote:
On Thu, Mar 6, 2014 at 12:23 AM, Teodor Sigaev wrote:
That's possible to introduce GUC variable for i/o functions which will
control old "bug-to-bug" behavior. IMHO, this is much better optio
On Thu, Mar 6, 2014 at 09:54:57AM +0530, Amit Kapila wrote:
> > If they haven't passed us a data directory, we don't really know if the
> > server is running or not, so the patch just returns '1'.
>
> But for such cases, isn't the status 4 more appropriate?
> As per above link "4 program or servi
On Thu, Mar 6, 2014 at 12:43 PM, Peter Geoghegan wrote:
> On Thu, Mar 6, 2014 at 12:23 AM, Teodor Sigaev wrote:
>> That's possible to introduce GUC variable for i/o functions which will
>> control old "bug-to-bug" behavior. IMHO, this is much better option that
>> stopping hstore development or s
(de-CC'ing pgsql-advocacy)
On 03/06/2014 04:03 AM, Greg Stark wrote:
On Mon, Mar 3, 2014 at 4:12 PM, Robert Haas wrote:
Unfortunately, I don't believe that it's possible to do this easily
today because of the way bucket splits are handled. I wrote about
this previously here, with an idea for
Hi all,
There are some place with the next commitfest deadlines (2014/06 and
2014/09) ?
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fab
On 6 March 2014 11:24, Mohsen SM wrote:
> I want use CREATE TYPE to create one type similar to char.
> I want to when I create type, then my type behave similar to char:
>
> CREATE TABLE test (oneChar char);
>
> when I want insert one column with length>1 to it, so it gets this error:
> ERROR: v
I want use CREATE TYPE to create one type similar to char.
I want to when I create type, then my type behave similar to char:
CREATE TABLE test (oneChar char);
when I want insert one column with length>1 to it, so it gets this error:
ERROR: value too long for type character(1)
I want my type be
2014-03-06 18:17 GMT+09:00 Haribabu Kommi :
>
> On Tue, Mar 4, 2014 at 3:07 PM, Kouhei Kaigai wrote:
>>
>> > > 4. + cchunk = ccache_vacuum_tuple(ccache, ccache->root_chunk, &ctid);
>> > > + if (pchunk != NULL && pchunk != cchunk)
>> > >
>> > > + ccache_merge_chunk(ccache, pchunk);
>> > >
>> > > +
On Thu, Mar 6, 2014 at 1:32 AM, Teodor Sigaev wrote:
> It's true for perl. Syntax of hstore is close to hash/array syntax and it's
> easy serialize/deserialize hstore to/from perl. Syntax of hstore was
> inspired by perl.
I understand that. There is a module on CPAN called Pg::hstore that
will do
On 5 March 2014 09:28, Simon Riggs wrote:
> So that returns us to solving the catalog consistency problem in
> pg_dump and similar applications.
No answer, guys, and time is ticking away here.
I'd like to get a communal solution to this rather than just punting
the whole patch.
If we have to s
In what sense are we really stopping hstore development if hstore2
lives as jsonb? I have a hard time imagining someone dealing with the
incompatibility that a user-facing hstore2 would introduce, while
still preferring hstore syntax over json syntax given the choice.
There are very rich facilit
On Tue, Mar 4, 2014 at 3:07 PM, Kouhei Kaigai wrote:
> > > 4. + cchunk = ccache_vacuum_tuple(ccache, ccache->root_chunk, &ctid);
> > > + if (pchunk != NULL && pchunk != cchunk)
> > >
> > > + ccache_merge_chunk(ccache, pchunk);
> > >
> > > + pchunk = cchunk;
> > >
> > >
> > > The merge_chunk is
On Thu, Mar 6, 2014 at 12:23 AM, Teodor Sigaev wrote:
> That's possible to introduce GUC variable for i/o functions which will
> control old "bug-to-bug" behavior. IMHO, this is much better option that
> stopping hstore development or split hstore to two branches.
A GUC that controls i/o function
Thank you for checking that. Teodor's goal was that new-hstore be 100%
backwards-compatible with old-hstore. If we're breaking APIs, then it
That's true. Binary format is fully compatible unless old hstore value has more
than 2^28 key-value pairs (256 mln which is far from reachable by memor
On 06/03/14 02:56, Craig Ringer wrote:
On 03/06/2014 04:56 AM, Yeb Havinga wrote:
If you state it like that, it sounds like a POLA violation. But the
complete story is: "A user is allowed to UPDATE a set of rows from a
table that is not a subsect of the set of rows he can SELECT from the
table,
Le mercredi 5 mars 2014 22:36:44 Noah Misch a écrit :
> Agreed. More specifically, I see only two scenarios for retrieving tuples
> from the tuplestore. Scenario one is that we need the next tuple (or pair
> of tuples, depending on the TriggerEvent). Scenario two is that we need
> the tuple(s) m
77 matches
Mail list logo
