Re: [HACKERS] proposal: new long psql parameter --on-error-stop

2014-02-28 22:52 GMT+01:00 Erik Rijkers : > e.g.: -v ON_ERROR_STOP=1 I checked it and it is not the most long line there, so it can be a good solution. Pavel

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

On Fri, Feb 28, 2014 at 9:43 AM, Heikki Linnakangas wrote: > Hmm, I wonder if that could now be misunderstood to have something to do > with the PostgreSQL page size? Maybe add the word "memory" or "operating > system" in the first sentence in the docs, like this: "Enables/disables the > use of hu

Re: [HACKERS] Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements

On Fri, Feb 28, 2014 at 5:05 PM, Alvaro Herrera wrote: > > Pavel Stehule escribió: > > > I agree with Tom proposal - CINE - where object holds data, COR everywhere > > else. > > > > But it means, so all functionality from this patch have to be rewritten :( > > So we return this patch with feedback

Re: [HACKERS] Patch to add support of "IF NOT EXISTS" to others "CREATE" statements

On Sat, Jan 18, 2014 at 11:12 PM, Stephen Frost wrote: > > Fabrízio, can you clarify the use-case for things like CREATE AGGREGATE > to have IF NOT EXISTS rather than OR REPLACE, or if there is a reason > why both should exist? Complicating our CREATE options is not something > we really wish to

[HACKERS] Securing "make check" (CVE-2014-0067)

As announced with last week's releases, use of trust authentication in the "make check" temporary database cluster makes it straightforward to hijack the OS user account involved. The prerequisite is another user account on the same system. The solution we discussed on secur...@postgresql.org was

[HACKERS] Query cancel in regex library

We have a couple of open bug reports in which the regex library takes unreasonable amounts of time and/or memory to process a regexp. While I have hopes that both of the known issues can be improved, it seems likely that there will always be cases where sufficiently complicated regexps just take t

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

2014-03-01 0:36 GMT+09:00 Stephen Frost : > * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote: >> * Stephen Frost (sfr...@snowman.net) wrote: >> > I don't see how you can be when there hasn't been any discussion that I've >> > seen about how parallel query execution is going to change things for us. >>

Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 28, 2014 at 2:40 PM, Christophe Pettus wrote: > On Feb 28, 2014, at 2:12 PM, Peter Geoghegan wrote: > >> AFAICT, we have these >> operator classes that work fine with jsonb for the purposes of >> hstore-style indexing (the hstore operator classes). > > That assumes that it is acceptab

Re: [HACKERS] jsonb and nested hstore

On Feb 28, 2014, at 2:12 PM, Peter Geoghegan wrote: > AFAICT, we have these > operator classes that work fine with jsonb for the purposes of > hstore-style indexing (the hstore operator classes). That assumes that it is acceptable that jsonb be packaged in the hstore extension. To put it mild

Re: [HACKERS] patch: option --if-exists for pg_dump

This patch has redesigned implementation --if-exists for pg_dumpall. Now it is not propagated to pg_dump, but used on pg_dumpall level. Regards Pavel 2014-02-28 23:18 GMT+01:00 Pavel Stehule : > > > > 2014-02-28 23:13 GMT+01:00 Pavel Stehule : > > Hi >> >> >>> However, I don't think this is be

Re: [HACKERS] patch: option --if-exists for pg_dump

2014-02-28 23:13 GMT+01:00 Pavel Stehule : > Hi > > >> However, I don't think this is behaving sanely in pg_dumpall. AFAICT, >> pg_dumpall does not pass --clean to pg_dump (in other words it only >> emits DROP for the global objects, not the objects contained inside >> databases), so passing --if

Re: [HACKERS] patch: option --if-exists for pg_dump

Hi > However, I don't think this is behaving sanely in pg_dumpall. AFAICT, > pg_dumpall does not pass --clean to pg_dump (in other words it only > emits DROP for the global objects, not the objects contained inside > databases), so passing --if-exists results in failures. Therefore I > think th

Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 28, 2014 at 1:38 PM, Christophe Pettus wrote: > jsonb is significantly faster than json even without indexing; there are > plenty of reasons to have jsonb even if we don't initially have indexing > operations for it. That may be true, although I think that that's still very disappoi

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

2014-02-28 23:01 GMT+01:00 Andrew Dunstan : > > On 02/28/2014 04:38 PM, Tom Lane wrote: > >> Andrew Dunstan writes: >> >>> Well, then we just have to add more info to --help >>> +1 for at least doing that. I found it annoying just the other day not >>> to find it in plsql's --help output, in

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

On 02/28/2014 04:38 PM, Tom Lane wrote: Andrew Dunstan writes: Well, then we just have to add more info to --help +1 for at least doing that. I found it annoying just the other day not to find it in plsql's --help output, in a moment of brain fade when I forgot how to spell it. So it's not ju

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

2014-02-28 22:52 GMT+01:00 Erik Rijkers : > On Fri, February 28, 2014 22:38, Tom Lane wrote: > > Andrew Dunstan writes: > >>> Well, then we just have to add more info to --help > > > >> +1 for at least doing that. I found it annoying just the other day not > >> to find it in plsql's --help output

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

On Fri, February 28, 2014 22:38, Tom Lane wrote: > Andrew Dunstan writes: >>> Well, then we just have to add more info to --help > >> +1 for at least doing that. I found it annoying just the other day not >> to find it in plsql's --help output, in a moment of brain fade when I >> forgot how to spe

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

2014-02-28 22:38 GMT+01:00 Tom Lane : > Andrew Dunstan writes: > >> Well, then we just have to add more info to --help > > > +1 for at least doing that. I found it annoying just the other day not > > to find it in plsql's --help output, in a moment of brain fade when I > > forgot how to spell it.

Re: [HACKERS] jsonb and nested hstore

On Feb 28, 2014, at 1:34 PM, Peter Geoghegan wrote: > Amazon RDS Postgres has hstore. Just observing that putting something in -contrib does not mean every installation can automatically adopt it. -- -- Christophe Pettus x...@thebuild.com -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

Andrew Dunstan writes: >> Well, then we just have to add more info to --help > +1 for at least doing that. I found it annoying just the other day not > to find it in plsql's --help output, in a moment of brain fade when I > forgot how to spell it. So it's not just beginners who can benefit, it'

Re: [HACKERS] jsonb and nested hstore

On Feb 28, 2014, at 1:35 PM, Peter Geoghegan wrote: > I don't think hstore-style indexing is "advanced"; it's the main > reason for there being a jsonb, in my view. jsonb is significantly faster than json even without indexing; there are plenty of reasons to have jsonb even if we don't initiall

Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 28, 2014 at 1:25 PM, Andrew Dunstan wrote: > The only "dependency" is if you want to be able to use some advanced > indexing and other functionality, for which we don't currently have jsonb > equivalents of the new hstore operators, because we ran out of time. Then > you can get this f

Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 28, 2014 at 1:31 PM, Christophe Pettus wrote: > I'll also mention that an increasingly large number of people are running > PostgreSQL in an environment where they don't get to pick what packages are > installed on their server (RDS, for example). Telling them that something is > i

Re: [HACKERS] jsonb and nested hstore

On Feb 28, 2014, at 1:03 PM, Josh Berkus wrote: > However, the problems with admins not wanting to install -contrib aren't > really about what's in or not in -contrib. I'll also mention that an increasingly large number of people are running PostgreSQL in an environment where they don't get to

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

On 02/28/2014 01:27 PM, Pavel Stehule wrote: > > three chars is not important > > important is a placing in --help output > Well, then we just have to add more info to --help it can be solution +1 for at least doing that. I found it annoying just the other day

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 03:19 PM, Tom Lane wrote: Andrew Dunstan writes: That hasn't been the way we've done things in the past. We're frequently incremental. New features sometimes take several releases to mature. That's perfectly fair. What I don't want to see is a user-visible dependency from jsonb

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 11:19 AM, Greg Stark wrote: > On Fri, Feb 28, 2014 at 7:12 PM, Josh Berkus wrote: >> * As cited, many sysadmins block the install of the -contrib package. > > Of course the more you put things in core the more you make this logic > sound reasonable. Touche'! However, the problems

Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 28, 2014 at 1:45 PM, Andrew Dunstan wrote: > Well, the jsonb portion of this is arguably the most ready, certainly it's > had a lot more on-list review. That is definitely true. Also, the jsonb type does not introduce any new patterns that are not already covered by json -- it just

Re: [HACKERS] extension_control_path

Stephen Frost writes: > Yeah, default_version was the other one that looked like it might be > possible to include, but folks might decide to try and use 'comment' in > that way too. Basically, there's a chance that they'd want to use any > string in there. Actually, I think that $default_value

Re: [HACKERS] jsonb and nested hstore

Andrew Dunstan writes: > That hasn't been the way we've done things in the past. We're frequently > incremental. New features sometimes take several releases to mature. That's perfectly fair. What I don't want to see is a user-visible dependency from jsonb to hstore. I think that'll be a mess

Re: [HACKERS] Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements

Pavel Stehule escribió: > I agree with Tom proposal - CINE - where object holds data, COR everywhere > else. > > But it means, so all functionality from this patch have to be rewritten :( So we return this patch with feedback, right? I don't think it's reasonable to continue waiting this late.

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 02:46 PM, Tom Lane wrote: Josh Berkus writes: ... This requires larger changes to the existing patch, which likely means missing the bus for 9.4 (and you've seen my blog about that) Yeah. I realize you're gung-ho about getting jsonb into 9.4 in some form, and I recognize that g

Re: [HACKERS] jsonb and nested hstore

On 2014-02-28 14:45:29 -0500, Andrew Dunstan wrote: > Well, the jsonb portion of this is arguably the most ready, certainly it's > had a lot more on-list review. Having crossread both patches I tend to agree with this. I don't think it's unrealistic to get jsonb committable, but the hstore bits ar

Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 28, 2014 at 11:12 AM, Josh Berkus wrote: > I think Robert and Christophe are right: we're building a Berkeley BART > Curve. I think there's two courses of action from here which make sense: > > A) We move *all* of the important HStore libraries and operators into > core, and make the

Re: [HACKERS] jsonb and nested hstore

Josh Berkus writes: > ... This requires larger changes to the existing patch, which likely means > missing the bus for 9.4 (and you've seen my blog about that) Yeah. I realize you're gung-ho about getting jsonb into 9.4 in some form, and I recognize that getting better JSON support is important.

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 02:00 PM, Tom Lane wrote: Peter Geoghegan writes: On Fri, Feb 28, 2014 at 5:01 AM, Andrew Dunstan wrote: But anyway, I think we've seen enough of these to conclude that the casts from hstore to jsonb and back should not be implicit. I am fairly confident that changing that woul

Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 28, 2014 at 7:12 PM, Josh Berkus wrote: > * As cited, many sysadmins block the install of the -contrib package. Of course the more you put things in core the more you make this logic sound reasonable. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 06:27 AM, Robert Haas wrote: > Taken individually, none of those decisions seem crazy, but taken > together it's pretty weird. Instead of inventing a new type (jsonb) > designed from the ground up to do what we want, we're, well, we're > doing what Christophe says: creating our own p

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

2014-02-28 19:55 GMT+01:00 Fabrízio de Royes Mello : > > On Fri, Feb 28, 2014 at 3:44 PM, Alvaro Herrera > wrote: > > > > Fabrízio de Royes Mello escribió: > > > On Fri, Feb 28, 2014 at 3:17 PM, Pavel Stehule < > pavel.steh...@gmail.com> > > > wrote: > > > > > > important is a placing in --help

Re: [HACKERS] patch: option --if-exists for pg_dump

2014-02-28 19:31 GMT+01:00 Alvaro Herrera : > Pavel Stehule escribió: > > > It is irony, so this is death code - it is not used now. So I removed it > > from patch. > > > > Reduced, fixed patch attached + used tests > > Nice, thanks. > > Here's a new version in which I reworded some comments and d

Re: [HACKERS] jsonb and nested hstore

Peter Geoghegan writes: > On Fri, Feb 28, 2014 at 5:01 AM, Andrew Dunstan wrote: >> But anyway, I think we've seen enough of these to conclude that the casts >> from hstore to jsonb and back should not be implicit. I am fairly confident >> that changing that would fix your complaint and the simil

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

On Fri, Feb 28, 2014 at 3:44 PM, Alvaro Herrera wrote: > > Fabrízio de Royes Mello escribió: > > On Fri, Feb 28, 2014 at 3:17 PM, Pavel Stehule > > wrote: > > > > important is a placing in --help output > > > > Well, then we just have to add more info to --help > > I think psql could do with som

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

Fabrízio de Royes Mello escribió: > On Fri, Feb 28, 2014 at 3:17 PM, Pavel Stehule > wrote: > > important is a placing in --help output > > Well, then we just have to add more info to --help I think psql could do with some lines for the possible options for --pset (14) and --variable (13). No

Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 28, 2014 at 5:01 AM, Andrew Dunstan wrote: > But anyway, I think we've seen enough of these to conclude that the casts > from hstore to jsonb and back should not be implicit. I am fairly confident > that changing that would fix your complaint and the similar one that Peter > Geoghegan

Re: [HACKERS] Equivalence Rules

"where" means, which function or which part of source code. I want to use that(function or part of source code), to produce the equivalence (based on equivalence rules in attachment) Relational Algebra for a given SQL query(Relational Algebra).

Re: [HACKERS] patch: option --if-exists for pg_dump

Pavel Stehule escribió: > It is irony, so this is death code - it is not used now. So I removed it > from patch. > > Reduced, fixed patch attached + used tests Nice, thanks. Here's a new version in which I reworded some comments and docs, and also inverted the sense of some if/else so that the

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

2014-02-28 19:25 GMT+01:00 Fabrízio de Royes Mello : > > On Fri, Feb 28, 2014 at 3:17 PM, Pavel Stehule > wrote: > > > > 2014-02-28 19:13 GMT+01:00 Tom Lane : > > > >> Pavel Stehule writes: > >> > for beginners is relative difficult to set psql variable from command > line > >> > and option > >

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

On Fri, Feb 28, 2014 at 3:17 PM, Pavel Stehule wrote: > > 2014-02-28 19:13 GMT+01:00 Tom Lane : > >> Pavel Stehule writes: >> > for beginners is relative difficult to set psql variable from command line >> > and option >> > -v ON_ERROR_STOP=1 is little bit unclean. >> > and for any user it is not

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

2014-02-28 19:13 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > for beginners is relative difficult to set psql variable from command > line > > and option > > -v ON_ERROR_STOP=1 is little bit unclean. > > and for any user it is not comfortable. So I propose a new psql option > > --on-error-sto

Re: [HACKERS] proposal: new long psql parameter --on-error-stop

Pavel Stehule writes: > for beginners is relative difficult to set psql variable from command line > and option > -v ON_ERROR_STOP=1 is little bit unclean. > and for any user it is not comfortable. So I propose a new psql option > --on-error-stop That saves a whole three characters ... not sure i

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 07:39 AM, Joshua D. Drake wrote: > > This is an old and currently false argument. It is true that once upon a > time, contrib was a banished heart, weeping for the attention of a true > prince. Now? Not so much. She is a full on passion flower with the > princes of all the kingdoms w

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

On 02/27/2014 09:34 AM, Christian Kruse wrote: Hi, On 26/02/14 13:13, Alvaro Herrera wrote: There's one thing that rubs me the wrong way about all this functionality, which is that we've named it "huge TLB pages". That is wrong -- the TLB pages are not huge. In fact, as far as I understand,

[HACKERS] proposal: new long psql parameter --on-error-stop

Hello for beginners is relative difficult to set psql variable from command line and option -v ON_ERROR_STOP=1 is little bit unclean. and for any user it is not comfortable. So I propose a new psql option --on-error-stop It is clean, and it will be mentioned in psql --help. Comments, ideas?

Re: [HACKERS] jsonb and nested hstore

On Feb 28, 2014, at 6:27 AM, Robert Haas wrote: > Taken individually, none of those decisions seem crazy, but taken > together it's pretty weird. Instead of inventing a new type (jsonb) > designed from the ground up to do what we want, we're, well, we're > doing what Christophe says: creating o

Re: [HACKERS] Equivalence Rules

Ali Piroozi wrote > Hi > Which equivalence rule from those are listed in > email's attachment are implemented in postgresql? > where are them? What do you mean by "where"? The various JOINS and UNION/INTERSECT/DIFFERENCE are all defined capabilities. SQL is not purely relational in nature so som

Re: [HACKERS] jsonb and nested hstore

+v.size += VARSIZE_ANY(v.numeric) +sizeof(JEntry) /* alignment */ ; Why does + sizeof(JEntry) change anything about alignment? If it was aligned before, adding a statically sized value doesn't give any new guarantees about alignment? Teodor, please comment. Because numeric type wil

Re: [HACKERS] GiST support for inet datatypes

2014-02-28 17:30, Florian Pflug : > Hm, what if we put the new opclass into an extension of its own, say > inet_gist, > instead of into core? It will work but I do not think it is better than adding it in core as not default. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 28, 2014 at 8:57 AM, Stephen Frost wrote: > The specific issues mentioned on this thread look more like bugs to be > addressed or additional operators which need to be implemented for > jsonb (imv, that should really be done for 9.4, but we have this > deadline looming...) along with p

Re: [HACKERS] GSoC proposal

On Feb28, 2014, at 05:29 , Tan Tran wrote: > I'm applying for GSoC 2014 with Postgresql and would appreciate your comments > on my proposal (attached). > First, please include your proposal as plain, inline text next time. That makes it easier to quote the relevant parts when replying, and also

Re: [HACKERS] jsonb and nested hstore

On 02/27/2014 11:02 PM, Christophe Pettus wrote: On Feb 27, 2014, at 9:59 PM, Peter Geoghegan wrote: I don't find that very reassuring. Obviously, we have to try it, and that will decide it. I don't understand why an extension is seen as not befitting of a more important feature. cont

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote: > * Stephen Frost (sfr...@snowman.net) wrote: > > I don't see how you can be when there hasn't been any discussion that I've > > seen about how parallel query execution is going to change things for us. > > > If parallel query execution changes whole o

Re: [HACKERS] GiST support for inet datatypes

On Feb28, 2014, at 15:45 , Emre Hasegeli wrote: > The problem is that pg_dump --binary-upgrade dumps objects in the extension > on the old cluster, not just the CREATE EXTENSION statement. pg_upgrade > fails to restore them, if the new operator class already exists on the new > cluster as the defa

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

On Thu, Feb 27, 2014 at 4:14 PM, Christian Kruse wrote: > Hi, > > On 25/02/14 16:11, Robert Haas wrote: >> On Mon, Feb 24, 2014 at 10:13 AM, Christian Kruse >> wrote: >> > To be honest, I don't like the idea of setting up this error context >> > only for log_lock_wait messages. This sounds unnece

Re: [HACKERS] UNION ALL on partitioned tables won't use indices.

On Fri, Feb 28, 2014 at 02:35:50PM +0900, Kyotaro HORIGUCHI wrote: > At Thu, 27 Feb 2014 21:53:52 -0500, Noah Misch wrote > > On Thu, Feb 27, 2014 at 05:33:47PM -0500, Tom Lane wrote: > > > I wonder whether we should consider adding a pass to flatten any nested > > > appendrels after we're done cre

Re: [HACKERS] [pgsql-advocacy] GSoC 2014 - mentors, students and admins

W dniu 27.02.2014 22:25, Thom Brown pisze: > On 27 February 2014 21:08, David Fetter > wrote: > > For MADlib, no. Are you asking for mentors in general? > > > Ah yes, I should clarify. Yes, mentors in general. In general I can help but I'm not sure if I'm not too fre

Re: [HACKERS] jsonb and nested hstore

* Robert Haas (robertmh...@gmail.com) wrote: > Taken individually, none of those decisions seem crazy, but taken > together it's pretty weird. Instead of inventing a new type (jsonb) > designed from the ground up to do what we want, we're, well, we're > doing what Christophe says: creating our own

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 09:27 AM, Robert Haas wrote: On Thu, Feb 27, 2014 at 8:55 PM, Christophe Pettus wrote: On Feb 27, 2014, at 5:31 PM, Peter Geoghegan wrote: Now, it's confusing that it has to go through hstore, perhaps, but that's hardly all that bad in and of itself. Yes, it is. It strikes me

Re: [HACKERS] GiST support for inet datatypes

2014-02-27 18:15, Florian Pflug : >> It can be possible to update the new operator class in the new cluster >> as not default, before restore. After the restore, pg_upgrade can upgrade >> the btree_gist extension and reset the operator class as the default. >> pg_upgrade suggests to re-initdb the n

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 8:55 PM, Christophe Pettus wrote: > On Feb 27, 2014, at 5:31 PM, Peter Geoghegan wrote: >> Now, it's confusing that it has to go through hstore, perhaps, but >> that's hardly all that bad in and of itself. > > Yes, it is. It strikes me as irrational to have jsonb depend o

Re: [HACKERS] jsonb and nested hstore

* Peter Geoghegan (p...@heroku.com) wrote: > On Thu, Feb 27, 2014 at 8:07 PM, Peter Geoghegan wrote: > > I'm not advocating authoring two extensions. I am tentatively > > suggesting that we look at one extension for everything. That may well > > be the least worst thing. > > (Not that it's clear

Re: [HACKERS] GSoC 2014 - mentors, students and admins

On Tue, Jan 28, 2014 at 5:34 PM, Thom Brown wrote: > Who would be up for mentoring this year? And are there any project > ideas folk would like to suggest? I mentored in the past and felt I didn't do a very good job because I didn't really understand the project the student was working on. Ther

Re: Fwd: [HACKERS] patch: make_timestamp function

Pavel Stehule escribió: > so still I prefer to allow numeric time zones. > > What I can: > > a) disallow numeric only timezone without prefix "+" or "-" > > or > > b) add "+" prefix to time zone, when number is possitive. > > I prefer @a. I can live with (a) too. But I wonder if we should r

Re: [HACKERS] GiST support for inet datatypes

On Thu, Feb 27, 2014 at 5:30 PM, Tom Lane wrote: > Indeed. The root of the problem here is that we've never really thought > about changing a type's default opclass before. I don't think that a > two-line change in pg_dump fixes all the issues this will bring up. I think we did actually do this

Re: [HACKERS] Request improve pg_stat_statements module

Thanks for your patch! On Fri, Feb 28, 2014 at 4:18 PM, wrote: > I patched to add one column in pg_stat_statements module. > and sent to author but > I need a last time of query, because I want to analyse order by recent time. Hm... I am not sure that this brings much to pg_stat_statements, whic

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 07:19 AM, Thom Brown wrote: On 28 February 2014 08:12, Andres Freund > wrote: On 2014-02-27 15:06:33 -0500, Andrew Dunstan wrote: > You realize that this API dates from 9.3 and has been used in numerous > extensions, right? So the nam

Re: [HACKERS] jsonb and nested hstore

On 28 February 2014 13:01, Andrew Dunstan wrote: > > On 02/28/2014 07:19 AM, Thom Brown wrote: > > On 28 February 2014 08:12, Andres Freund > and...@2ndquadrant.com>> wrote: >> >> On 2014-02-27 15:06:33 -0500, Andrew Dunstan wrote: >> > You realize that this API dates from 9.3 and has be

Re: [HACKERS] extension_control_path

* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > Peter Eisentraut writes: > > I think we should get rid of the module_pathname business, and > > extensions' SQL files should just refer to the base file name and rely > > on the dynamic library path to find the files. What would we lose if we >

[HACKERS] Equivalence Rules

Hi Which equivalence rule from those are listed in email's attachment are implemented in postgresql? where are them? Thanks equivalenceRules.pdf Description: Adobe PDF document -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www

Re: [HACKERS] extension_control_path

* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > Stephen Frost writes: > >># hstore extension > >>comment = 'data type for storing sets of (key, value) pairs' > >>default_version = '1.3' > >>directory = 'local/hstore-new' > >>module_pathname = '$directory/hstore' > >>re

Re: [HACKERS] [PATCH] Store Extension Options

On Fri, Feb 28, 2014 at 5:08 AM, Abhijit Menon-Sen wrote: > > Hi Fabrízio. > > Here are a few comments based on a quick look at your updated patch. > > At 2014-02-13 22:44:56 -0200, fabriziome...@gmail.com wrote: > > > > diff --git a/doc/src/sgml/ref/alter_index.sgml b/doc/src/sgml/ref/alter_index

Re: [HACKERS] Hot standby doesn't come up on some situation.

On 02/28/2014 11:51 AM, Kyotaro HORIGUCHI wrote: Hello, 2014/02/28 18:07 "Andres Freund" : On 2014-02-28 17:55:21 +0900, Kyotaro HORIGUCHI wrote: The recovery process stays on 'incosistent' state forever when the server has crashed before any wal record is inserted after the last checkpoint.

Re: [HACKERS] jsonb and nested hstore

On 28 February 2014 08:12, Andres Freund wrote: > On 2014-02-27 15:06:33 -0500, Andrew Dunstan wrote: > > You realize that this API dates from 9.3 and has been used in numerous > > extensions, right? So the names are pretty well fixed, for good or ill. > > Sure. Doesn't prevent adding a couple mo

Re: [HACKERS] pgbench help message fix

On 2/27/14, 12:53 PM, Fabien COELHO wrote: A very minor fix to "pgbench --help" which is missing the expected argument for the -t option. done Thanks! -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgre

Re: [HACKERS] Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?

On 2014-02-28 10:44:14 +, Greg Stark wrote: > On 28 Feb 2014 06:19, "Andres Freund" wrote: > > Generally the LSN is computed when writing, not when a buffer is > > modified, so that's not particularly surprising. It'd be interesting to > > see what the records are that end on those LSNs. > >

Re: [HACKERS] Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?

On 28 Feb 2014 06:19, "Andres Freund" wrote: > > On 2014-02-27 23:41:08 +, Greg Stark wrote: > > Though I notice something I can't understand here. > > > > After activating the new clone subsequent attempts to select rows from > > the page bump the LSN, presumably due to touching hint bits (si

Re: Fwd: [HACKERS] patch: make_timestamp function

2014-02-27 20:10 GMT+01:00 Alvaro Herrera : > Pavel Stehule escribió: > > Hello > > > > updated patch without timetz support > > Great, thanks. > > While testing, I noticed something strange regarding numeric timezone > specification. Basically the way any particular value is handled is > undersp

Re: [HACKERS] extension_control_path

Stephen Frost writes: >># hstore extension >>comment = 'data type for storing sets of (key, value) pairs' >>default_version = '1.3' >>directory = 'local/hstore-new' >>module_pathname = '$directory/hstore' >>relocatable = true > > Interesting idea. I'm a *little* concerned

Re: [HACKERS] extension_control_path

Peter Eisentraut writes: > I think we should get rid of the module_pathname business, and > extensions' SQL files should just refer to the base file name and rely > on the dynamic library path to find the files. What would we lose if we > did that? Control over *which* mylib.so file gets loaded

Re: [HACKERS] Hot standby doesn't come up on some situation.

Hello, 2014/02/28 18:07 "Andres Freund" : > > On 2014-02-28 17:55:21 +0900, Kyotaro HORIGUCHI wrote: > > The recovery process stays on 'incosistent' state forever when > > the server has crashed before any wal record is inserted after > > the last checkpoint. > > > # killall postgres > > # rm -rf

Re: [HACKERS] Hot standby doesn't come up on some situation.

On 2014-02-28 17:55:21 +0900, Kyotaro HORIGUCHI wrote: > The recovery process stays on 'incosistent' state forever when > the server has crashed before any wal record is inserted after > the last checkpoint. > # killall postgres > # rm -rf $PGDATA/* > initdb > pg_ctl start -w > sleep 1 > pg_ctl st

Re: [HACKERS] Hot standby doesn't come up on some situation.

Ouch. this is the same issue to the mail below, http://www.postgresql.org/message-id/53104595.6060...@lab.ntt.co.jp regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http:/

[HACKERS] Hot standby doesn't come up on some situation.

Hello, we found that hot standby doesn't came up under certain condition. This occurs for 9.3 and 9.4dev. The recovery process stays on 'incosistent' state forever when the server has crashed before any wal record is inserted after the last checkpoint. This seems to be because EndRecPtr is set to

Re: [HACKERS] Backup throttling

On 02/27/2014 11:04 PM, Alvaro Herrera wrote: > I pushed this patch with a few further tweaks. In your changes to > address the above point, you made the suffix mandatory in the > pg_basebackup -r option. This seemed a strange restriction, so I > removed it. It seems more user-friendly to me to

Re: [HACKERS] jsonb and nested hstore

On 2014-02-27 15:06:33 -0500, Andrew Dunstan wrote: > You realize that this API dates from 9.3 and has been used in numerous > extensions, right? So the names are pretty well fixed, for good or ill. Sure. Doesn't prevent adding a couple more comments tho. I've only noticed this because I opened th

Re: [HACKERS] What behavior is in this loop?

(2014/02/27 20:19), Heikki Linnakangas wrote: On 02/27/2014 12:38 PM, KONDO Mitsumasa wrote: I found interesting "for" and "while" loop in WaitForWALToBecomeAvailable() in xlog.c. Can you tell me this behavior? for (;;) { ~ } while (StanbyMode) I confirmed this code is no problem in gcc compil

Re: [HACKERS] [PATCH] Store Extension Options

Hi Fabrízio. Here are a few comments based on a quick look at your updated patch. At 2014-02-13 22:44:56 -0200, fabriziome...@gmail.com wrote: > > diff --git a/doc/src/sgml/ref/alter_index.sgml > b/doc/src/sgml/ref/alter_index.sgml > index d210077..5e9ee9d 100644 > --- a/doc/src/sgml/ref/alter_i

Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 28, 2014 at 12:01 AM, Andres Freund wrote: > On 2014-02-27 23:54:47 -0800, Peter Geoghegan wrote: >> In any case, as I say, if that's the patch that Andres or Oleg or >> Teodor really want to submit, then by all means let them submit it. > > Just to make that clear, I am not one of the

Re: [HACKERS] jsonb and nested hstore

On 2014-02-27 23:54:47 -0800, Peter Geoghegan wrote: > In any case, as I say, if that's the patch that Andres or Oleg or > Teodor really want to submit, then by all means let them submit it. Just to make that clear, I am not one of the authors, I just did a couple of light review passes. Greeting