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
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,
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 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
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
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 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
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
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);
>> > >
>> > > +
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
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
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
(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
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
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 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: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 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
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
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
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
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
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 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
>
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 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
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 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
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 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
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
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
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
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 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
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 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 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 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 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 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 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 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 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
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 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
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 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 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
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 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
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 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 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 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,
> 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 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
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 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
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 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
=?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 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
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 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
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 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 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 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 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
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 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
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 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
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 *
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
(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
77 matches
Mail list logo
