Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 11:36 PM, Christophe Pettus wrote: > There was no technical reason that json couldn't have been an extension, > either, but there were very compelling presentational reasons to have it in > core. jsonb has exactly the same presentational issues. There were also no compe

Re: [HACKERS] Unfortunate choice of short switch name in pgbench

(2014/02/28 2:39), Tom Lane wrote: > Fabien COELHO writes: >>> Yeah, but they don't make -P take an integer argument. It's that >>> little frammish that makes this problem significant. > >> I do not see a strong case to make options with arguments case insensitive >> as a general rule. If this i

Re: [HACKERS] jsonb and nested hstore

On Feb 27, 2014, at 11:15 PM, Peter Geoghegan wrote: > I don't think that's obvious at all. Anyone is free to spend their > time however they please, but personally I don't think that that's a > wise use of anyone's time. I believe you are misunderstanding me. If there are actual technical pro

[HACKERS] Request improve pg_stat_statements module

I patched to add one column in pg_stat_statements module. and sent to author but I recived a reject mail because unknown user :( so I am posting to this mailling. I need a last time of query, because I want to analyse order by recent time. this patch code below, review please and I wish to apply

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 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 think that's obvious at all. Anyone is free to spend their time however they p

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 09:02 AM, Christophe Pettus wrote: contrib/ is considered a secondary set of features; I routinely get pushback from clients about using hstore because it's not in core, and they are thus suspicious of it. The educational project required to change that far exceeds any technical

Re: [HACKERS] jsonb and nested hstore

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. contrib/ is considered a secondary set of features; I r

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

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 (since the > prune xid hasn't changed). But the checksum has

Re: [HACKERS] jsonb and nested hstore

On 2014-02-27 22:10:22 -0500, Peter Eisentraut wrote: > On 2/26/14, 10:42 PM, Andrew Dunstan wrote: > > Extensions can't call each other's code. > > That's not necessarily so. I don't think we have portable infrastructure to it properly yet, without a detour via the fmgr. If I am wrong, what's th

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 9:35 PM, Christophe Pettus wrote: >> The only problem with that is now you have to move the implementation >> of ||, plus a bunch of other hstore operators into core. That seems >> like a more difficult direction to move in from a practical >> perspective, and I'm not sure

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

Sorry, I did wrong test. > > > Noah Misch writes: > > > > If the attached patch version looks reasonable, I will commit it. > > > > > > The test case is completely bogus, as the query explained is significantly > > > different from the query executed. I'm not sure whether you can just > > > rem

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

Hello, 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: > > Noah Misch writes: > > > If the attached patch version looks reasonable, I will commit it. > > > > The test case is completely bogus, as the query explained is significantl

Re: [HACKERS] jsonb and nested hstore

On Feb 27, 2014, at 9:28 PM, Peter Geoghegan wrote: > The only problem with that is now you have to move the implementation > of ||, plus a bunch of other hstore operators into core. That seems > like a more difficult direction to move in from a practical > perspective, and I'm not sure that you

Re: [HACKERS] jsonb and nested hstore

On Feb 27, 2014, at 9:12 PM, Craig Ringer wrote: > On 02/28/2014 12:43 PM, Christophe Pettus wrote: >> My proposal is that we break the dependencies of jsonb (at least, at the >> user-visible level) on hstore2, thus allowing it in core successfully. jsonb >> || jsonb returning hstore seems lik

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 8:43 PM, Christophe Pettus wrote: >> I'm not the one opposed to putting jsonb stuff in the hstore module! > > My proposal is that we break the dependencies of jsonb (at least, at the > user-visible level) on > hstore2, thus allowing it in core successfully. jsonb || jsonb

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 12:43 PM, Christophe Pettus wrote: > My proposal is that we break the dependencies of jsonb (at least, at the > user-visible level) on hstore2, thus allowing it in core successfully. jsonb > || jsonb returning hstore seems like a bug to me, not a feature we should be > supporting.

Re: [HACKERS] extension_control_path

* Peter Eisentraut (pete...@gmx.net) wrote: > On 2/27/14, 6:04 AM, Dimitri Fontaine wrote: > > What about allowing a control file like this: > > > ># hstore extension > >comment = 'data type for storing sets of (key, value) pairs' > >default_version = '1.3' > >directory = 'local/hs

Re: [HACKERS] jsonb and nested hstore

On Feb 27, 2014, at 8:31 PM, Peter Geoghegan wrote: > On Thu, Feb 27, 2014 at 8:23 PM, Christophe Pettus wrote: >> Surely, the answer is to define a jsonb || jsonb (and likely the other >> combinatorics of json and jsonb), along with the appropriate GIN and GiST >> interfaces for jsonb. Why

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 8:23 PM, Christophe Pettus wrote: > On Feb 27, 2014, at 8:04 PM, Peter Geoghegan wrote: > >> I'm hearing a lot about how important jsonb is, but not much on how to >> make the simple jsonb cases that are currently broken (as illustrated >> by my earlier examples [1], [2])

Re: [HACKERS] jsonb and nested hstore

On Feb 27, 2014, at 8:04 PM, Peter Geoghegan wrote: > I'm hearing a lot about how important jsonb is, but not much on how to > make the simple jsonb cases that are currently broken (as illustrated > by my earlier examples [1], [2]) work. Surely, the answer is to define a jsonb || jsonb (and lik

Re: [HACKERS] jsonb and nested hstore

On 02/27/2014 05:54 PM, Josh Berkus wrote: And it's not just that "broadly speaking most people would prefer the interface to speak JSON"; it's that a JSONish interface for indexed heirachical data is a Big Feature which will drive adoption among web developers, and hstore2 without JSON sup

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 8:07 PM, Peter Geoghegan wrote: > On Thu, Feb 27, 2014 at 8:05 PM, Stephen Frost wrote: >> And, for my 2c, I'd like to see jsonb as a built-in type *anyway*. Even >> if it's possible to fight with things and make inter-extension >> dependency work, it's not trivial and wo

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 8:05 PM, Stephen Frost wrote: > And, for my 2c, I'd like to see jsonb as a built-in type *anyway*. Even > if it's possible to fight with things and make inter-extension > dependency work, it's not trivial and would likely discourage new > developers trying to use it. I'm

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 7:27 PM, Andrew Dunstan wrote: > On 02/27/2014 10:09 PM, Peter Geoghegan wrote: > >> * It hardly makes any sense to have an in-core jsonb if it comes with >> no batteries included. You need to install hstore for this jsonb >> implementation to be of *any* use anyway. > > >

Re: [HACKERS] jsonb and nested hstore

Peter, * Peter Eisentraut (pete...@gmx.net) wrote: > On 2/27/14, 9:08 PM, Stephen Frost wrote: > > Extensions can't depend on other extensions directly- hence you can't > > write an extension that depends on hstore, which sucks. > > Sure they can, see transforms. > > (Or if you disagree, downloa

Re: [HACKERS] extension_control_path

On 2/27/14, 6:04 AM, Dimitri Fontaine wrote: > What about allowing a control file like this: > ># 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: [HACKERS] jsonb and nested hstore

On 02/27/2014 10:09 PM, Peter Geoghegan wrote: * It hardly makes any sense to have an in-core jsonb if it comes with no batteries included. You need to install hstore for this jsonb implementation to be of *any* use anyway. This is complete nonsense. Right out of the box today a considerable

Re: [HACKERS] jsonb and nested hstore

On 2/27/14, 9:08 PM, Stephen Frost wrote: > Extensions can't depend on other extensions directly- hence you can't > write an extension that depends on hstore, which sucks. Sure they can, see transforms. (Or if you disagree, download that patch and demo it, because I'd like to know. ;-) ) -- S

Re: [HACKERS] extension_control_path

* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > Stephen Frost writes: > > me as a terrible idea to ship absolute object file names (which I assume > > you mean to include path, given you say 'absolute') unless you're an > > I agree, that's why my current design also needs cooperation on the

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 5:54 PM, Josh Berkus wrote: > And it's not just that "broadly speaking most people would prefer > the interface to speak JSON"; it's that a JSONish interface for indexed > heirachical data is a Big Feature which will drive adoption among web > developers, and hstore2 withou

Re: [HACKERS] jsonb and nested hstore

On 2/26/14, 10:42 PM, Andrew Dunstan wrote: > Extensions can't call each other's code. That's not necessarily so. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] jsonb and nested hstore

On 2/27/14, 2:11 PM, Josh Berkus wrote: > This means that, if we have jsonb as an extension, we'll > eventually be in the position where the recommended json type with all > the features is an extension, whereas the legacy json type is in core. Well that wouldn't be a new situation. Compare geome

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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsq

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

On Thu, Feb 27, 2014 at 05:33:47PM -0500, Tom Lane wrote: > Noah Misch writes: > > If the attached patch version looks reasonable, I will commit it. > > The test case is completely bogus, as the query explained is significantly > different from the query executed. I'm not sure whether you can ju

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

On Thu, Feb 27, 2014 at 05:47:16PM -0500, Tom Lane wrote: > BTW, isn't the proposed change to the comments for adjust_appendrel_attrs > just wrong? If it's correct, why doesn't the Assert(!IsA(node, SubLink)) > therein fire? (AFAICS, the existing comment is correct: we don't use > this function u

Re: [HACKERS] tests for client programs

Updated patch. Changes: - added documentation - avoid port conflicts with running instances - added tests for pg_basebackup -T - removed TODO tests for rejected pg_basebackup feature A test on Windows would be nice. Otherwise we'll let the buildfarm do it. >From 8205e58442720965c98794cb2f234c46

Re: [HACKERS] jsonb and nested hstore

* Peter Geoghegan (p...@heroku.com) wrote: > On Thu, Feb 27, 2014 at 6:08 PM, Stephen Frost wrote: > > Extensions can't depend on other extensions directly- hence you can't > > write an extension that depends on hstore, which sucks. It'd be > > preferrable to not have that issue w/ json/jsonb/wha

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 6:08 PM, Stephen Frost wrote: >> On Thu, Feb 27, 2014 at 6:02 PM, Craig Ringer wrote: >> > It's also make it a lot harder to use in other extensions, something >> > that's already an issue with hstore. >> >> What do you mean? > > Extensions can't depend on other extensions

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

On 02/18/2014 12:19 AM, Andres Freund wrote: > On 2014-02-16 21:26:47 -0500, Robert Haas wrote: >> I don't think anyone objected to increasing the defaults for work_mem >> and maintenance_work_mem by 4x, and a number of people were in favor, >> so I think we should go ahead and do that. If you'd l

Re: [HACKERS] jsonb and nested hstore

* Peter Geoghegan (p...@heroku.com) wrote: > On Thu, Feb 27, 2014 at 6:02 PM, Craig Ringer wrote: > > It's also make it a lot harder to use in other extensions, something > > that's already an issue with hstore. > > What do you mean? Extensions can't depend on other extensions directly- hence yo

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 6:02 PM, Craig Ringer wrote: > It's also make it a lot harder to use in other extensions, something > that's already an issue with hstore. What do you mean? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to yo

Re: [HACKERS] jsonb and nested hstore

On 02/28/2014 09:54 AM, Josh Berkus wrote: > On 02/27/2014 01:28 PM, Merlin Moncure wrote: >> How we got here is not the point. All that matters is what's going to >> happen from here. Here are the facts as I see them: > > Well, it certainly matters if we want it in this release. > > As far as

Re: [HACKERS] jsonb and nested hstore

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 on hstore. Let's be honest with ourselves: if we were starting

Re: [HACKERS] jsonb and nested hstore

On 02/27/2014 01:28 PM, Merlin Moncure wrote: > How we got here is not the point. All that matters is what's going to > happen from here. Here are the facts as I see them: Well, it certainly matters if we want it in this release. As far as I can tell, moving jsonb to contrib basically requires

[HACKERS] Proposal/design feedback needed: "Providing catalog view to pg_hba.conf file"

Hi All, I would like to propose an implementation of creating new catalog view for pg_hba.conf file contents. Aim of this proposal is to present a new view "pg_settings_hba" to database administrator, for viewing pg_hba.conf file contents. Currently, to view the pg_hba.conf file contents,

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 1:28 PM, Merlin Moncure wrote: > 3) In it's current state jsonb is not very useful and we have to > recognize that; it optimizes text json but OTOH covers, maybe 30-40% > of what hstore offers. In particular, it's missing manipulation and > GIST/GIN. The stuff it does off

Re: [HACKERS] pg_dump reporing version of server & pg_dump as comments in the output

Sorry for missing the patch file in the original email. Enclosed please find it. Jing Wang Fujitsu Australia From: Arulappan, Arul Shaji Sent: Friday, 28 February 2014 11:21 AM To: Wang, Jing Subject: RE: [HACKERS] pg_dump reporing version of server & pg_dump as comments in the output

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 3:54 AM, Robert Haas wrote: > So I tried to tease it out from looking at the patches. As nearly as > I can tell, the reason for making jsonb use hstore's binary format is > because then we can build indexes on jsonbfield::hstore, and the > actual type conversion will be a

[HACKERS] Windows exit code 128 ... it's baaack

I looked at the postmaster log for the ongoing issue on narwhal (to wit, that the contrib/dblink test dies the moment it tries to do anything dblink-y), and looky here what the postmaster has logged: 530fc965.bac:2] LOG: server process (PID 2144) exited with exit code 128 [530fc965.bac:3] DETAIL:

[HACKERS] pg_dump reporing version of server & pg_dump as comments in the output

Enclosed is the patch to implement the requirement that pg_dump should report version of server & pg_dump as comments in the output. [Benefit] By running "head" on pg_dump output, you can readily discover what version of PostgreSQL was used to generate that dump. Very useful especially for "m

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

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 (since the prune xid hasn't changed). But the checksum hasn't changed even after running CHECKPOINT. How is it poss

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

BTW, isn't the proposed change to the comments for adjust_appendrel_attrs just wrong? If it's correct, why doesn't the Assert(!IsA(node, SubLink)) therein fire? (AFAICS, the existing comment is correct: we don't use this function until after expression preprocessing is complete.)

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

Noah Misch writes: > If the attached patch version looks reasonable, I will commit it. The test case is completely bogus, as the query explained is significantly different from the query executed. I'm not sure whether you can just remove the extra ORDER BY column without getting machine-dependen

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

On Thu, Feb 27, 2014 at 2:34 PM, Alvaro Herrera wrote: > Greg, Peter, if you could update your standbys to the current HEAD of > REL9_3_STABLE for the affected apps and verify the problem no longer > shows up in a reasonable timeframe, it would be great. (I'm assuming > you saw this happen repeat

Re: [HACKERS] Backup throttling

Antonin Houska escribió: > > Why did you choose "bytes per second" as a valid rate which we can specify? > > Since the minimum rate is 32kB, isn't it better to use "KB per second" for > > that? > > If we do that, we can easily increase the maximum rate from 1GB to very > > large > > number in th

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 11:11 AM, Josh Berkus wrote: > Because the course Andrew is following is the one which *this list* > decided on in CF3, no matter that people who participated in that > discussion seem to have collective amnesia. There was a considerable > amount of effort involved in impl

Re: [HACKERS] jsonb and nested hstore

On Thu, Feb 27, 2014 at 1:11 PM, Josh Berkus wrote: > However, we had this discussion already in November-December, which > resulted in the current patch. Now you and Robert want to change the > rules on Andrew, which means Andrew is ready to quit, and we go another > year without JSON indexing.

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

On 27 February 2014 21:08, David Fetter wrote: > On Thu, Feb 27, 2014 at 07:54:13PM +, Thom Brown wrote: > > On 25 February 2014 13:28, Andreas 'ads' Scherbaum < > adsm...@wars-nicht.de>wrote: > > > I've spoken with the MADlib team at goivotal and they are ok to > > > support this proposal. T

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

On Thu, Feb 27, 2014 at 07:54:13PM +, Thom Brown wrote: > On 25 February 2014 13:28, Andreas 'ads' Scherbaum > wrote: > > I've spoken with the MADlib team at goivotal and they are ok to > > support this proposal. Therefore I offer to mentor this. > > Are there any more prospective mentors? W

[HACKERS] pglz_decompress()

Hello, The comments in pg_lzcompress.c say that: * If VARSIZE(x) == rawsize + sizeof(PGLZ_Header), then the data * is stored uncompressed as plain bytes. Thus, the decompressor * simply copies rawsize bytes from the location after the * header to the destination. But pg_lzdecompress doesn't

Re: [HACKERS] jsonb and nested hstore

On 02/26/2014 05:45 PM, Andres Freund wrote: On 2014-02-26 16:23:12 -0500, Andrew Dunstan wrote: On 02/10/2014 09:11 PM, Andres Freund wrote: Is it just me or is jsonapi.h not very well documented? What about it do you think is missing? In any case, it's hardly relevant to this patch, so I'l

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

On 25 February 2014 13:28, Andreas 'ads' Scherbaum wrote: > > Hi, > > > On 01/28/2014 06:46 PM, Atri Sharma wrote: > >> On Tue, Jan 28, 2014 at 11:04 PM, Thom Brown > > wrote: >> >> Hi all, >> >> Application to Google Summer of Code 2014 can be made as of next >>

Re: Fwd: [HACKERS] patch: make_timestamp function

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 underspecified, or maybe just completely wacko. Consider the attache

Re: [HACKERS] jsonb and nested hstore

On 02/27/2014 01:56 AM, Peter Geoghegan wrote: > I don't understand why you'd consider it to be a matter of shoehorning > jsonb into hstore (and yes, that is what I was suggesting). Because the course Andrew is following is the one which *this list* decided on in CF3, no matter that people who par

[HACKERS] VACUUM FULL/CLUSTER doesn't update pg_class's pg_class.relfrozenxid

Hi, As Robert previously complained a database wide VACUUM FULL now (as of 3cff1879f8d03) reliably increases the relfrozenxid for all tables but pg_class itself. That's a bit sad because it means doing a VACUUM FULL won't help in a anti-wraparound scenario. The reason for that is explained by the

[HACKERS] pgbench help message fix

A very minor fix to "pgbench --help" which is missing the expected argument for the -t option. -- Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench/pgbench.c index a836acf..7c1e59e 100644 --- a/contrib/pgbench/pgbench.c +++ b/contrib/pgbench/pgbench.c @@ -368,7 +368,7 @@ usage(vo

Re: [HACKERS] Unfortunate choice of short switch name in pgbench

Fabien COELHO writes: >> Yeah, but they don't make -P take an integer argument. It's that >> little frammish that makes this problem significant. > I do not see a strong case to make options with arguments case insensitive > as a general rule. If this is done for -p/-P, why not -t/-T? I have n

Re: [HACKERS] jsonb and nested hstore

On Feb 27, 2014, at 3:54 AM, Robert Haas wrote: > It's not very clear to me why we think it's a good idea to share the > tree-ish representation between json and hstore. In deference to your > comments that this has been very publicly discussed over quite a > considerable period, I went back and

Re: [HACKERS] Unfortunate choice of short switch name in pgbench

ISTM that this is an unfortunate but unlikely mistake, as "-p" is used in all postgresql commands to signify the port number (psql, pg_dump, pg_basebackup, createdb, ...). Plus other tools already use -P for progress, such as rsync. Yeah, but they don't make -P take an integer argument. It

Re: [HACKERS] GiST support for inet datatypes

Florian Pflug writes: > On Feb27, 2014, at 17:56 , Tom Lane wrote: >> That's not a bug, it's a feature, for much the same reasons that pg_dump >> tries to minimize explicit schema-qualification. > I fail to see the value in this for opclasses. It's certainly nice for > schema qualifications, bec

Re: [HACKERS] GiST support for inet datatypes

On Feb27, 2014, at 17:56 , Tom Lane wrote: > Florian Pflug writes: >> Maybe I'm missing something, but isn't the gist of the problem here that >> pg_dump won't explicitly state the operator class if it's the default? > > That's not a bug, it's a feature, for much the same reasons that pg_dump >

Re: [HACKERS] Changeset Extraction v7.8

On 27 February 2014 16:56, Andres Freund wrote: > Hi, > > Attached you can find version 7.8 of this patcheset. Changes since 7.7 > include: Try again? :) -- Thom

Re: [HACKERS] GiST support for inet datatypes

Florian Pflug writes: > Maybe I'm missing something, but isn't the gist of the problem here that > pg_dump won't explicitly state the operator class if it's the default? That's not a bug, it's a feature, for much the same reasons that pg_dump tries to minimize explicit schema-qualification. At l

Re: [HACKERS] Changeset Extraction v7.8

Hi, Attached you can find version 7.8 of this patcheset. Changes since 7.7 include: * Signature changes of the SQL changeset SRFs to support limits based on LSN and/or number of returned rows (pg_logical_slot_get_changes() et al) and to make parameter passing optional (by adding a DEFAULT '{}'

Re: [HACKERS] Changeset Extraction v7.6.1

On Thu, Feb 27, 2014 at 11:06 AM, Andres Freund wrote: > On 2014-02-24 12:50:03 -0500, Robert Haas wrote: >> On Mon, Feb 24, 2014 at 9:48 AM, Andres Freund >> wrote: >> > On 2014-02-15 17:29:04 -0500, Robert Haas wrote: >> >> On Fri, Feb 14, 2014 at 4:55 AM, Andres Freund >> >> wrote: >> > >>

Re: [HACKERS] GiST support for inet datatypes

On Feb27, 2014, at 11:39 , Emre Hasegeli wrote: > 2014-02-24 17:55, Bruce Momjian : > >> pg_upgrade has _never_ modified the old cluster, and I am hesitant to do >> that now. Can we make the changes in the new cluster, or in pg_dump >> when in binary upgrade mode? > > It can be possible to upda

Re: [HACKERS] Changeset Extraction v7.6.1

On 2014-02-24 12:50:03 -0500, Robert Haas wrote: > On Mon, Feb 24, 2014 at 9:48 AM, Andres Freund wrote: > > On 2014-02-15 17:29:04 -0500, Robert Haas wrote: > >> On Fri, Feb 14, 2014 at 4:55 AM, Andres Freund > >> wrote: > > > >> + /* > >> +* XXX: It's impolite to ignore our argum

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

On Thu, Feb 27, 2014 at 07:30:57PM +0900, Kyotaro HORIGUCHI wrote: > Thank you for the labor for polishing this patch. > > I have no obvious objection at a glance on this new patch. > > I agree to commit this if you this is pertinent to commit except > for the issue newly revealed by this patch.

Re: [HACKERS] Unfortunate choice of short switch name in pgbench

Alvaro Herrera writes: > Fabien COELHO wrote: >>> I just wasted some time puzzling over strange results from pgbench. >>> I eventually realized that I'd been testing against the wrong server, >>> because rather than "-p 65432" I'd typed "-P 65432", thereby invoking >>> the recently added --progres

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

Andres Freund wrote: > On 2014-02-26 18:18:05 -0300, Alvaro Herrera wrote: > > Andres Freund wrote: > > > > > static void > > > heap_xlog_lock(XLogRecPtr lsn, XLogRecord *record) > > > { > > > ... > > > HeapTupleHeaderClearHotUpdated(htup); > > > HeapTupleHeaderSetXmax(htup, xlrec->locking

Re: [HACKERS] Unfortunate choice of short switch name in pgbench

Fabien COELHO wrote: > >I just wasted some time puzzling over strange results from pgbench. > >I eventually realized that I'd been testing against the wrong server, > >because rather than "-p 65432" I'd typed "-P 65432", thereby invoking > >the recently added --progress option. pgbench has no way

[HACKERS] Defining macro LSNOID for pg_lsn in pg_type.h

Hi all, When working on the datatype pg_lsn, we actually did not create a define macro for its oid in pg_type.h and this could be useful for extension developers. The simple patch attached corrects that by naming this macro LSNOID. Regards, -- Michael diff --git a/src/include/catalog/pg_type.h b/

Re: [HACKERS] Dump pageinspect to 1.2: page_header with pg_lsn datatype

On Wed, Feb 26, 2014 at 5:45 AM, Alvaro Herrera wrote: > Robert Haas escribió: >> On Mon, Feb 24, 2014 at 9:34 AM, Alvaro Herrera >> wrote: >> > Yeah, erroring out seems good enough. Particularly if you add a hint >> > saying "please upgrade the extension". >> >> In past instances where this has

Re: [HACKERS] jsonb and nested hstore

On Wed, Feb 26, 2014 at 10:42 PM, Andrew Dunstan wrote: >>> Why can't this whole thing be shipped as an extension? It might well >>> be more convenient to have the whole thing packaged as an extension >>> than to have parts of it in core and parts of it not in core. >> >> That's a good question.

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

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 compiler:) Oh wow :-). That's clearly a thinko, alt

Re: [HACKERS] jsonb and nested hstore

On 02/26/2014 09:17 AM, Christophe Pettus wrote: > On Feb 25, 2014, at 1:57 PM, Hannu Krosing wrote: > >> It is not in any specs, but nevertheless all major imlementations do it and >> some code depends on it. > I have no doubt that some code depends on it, but "all major implementations" > is >

Re: [HACKERS] extension_control_path

Stephen Frost writes: > I'm a bit confused here- above you '+1'd packagers/sysadmins, but then > here you are saying that hackers will be setting it? Also, it strikes Well I was then talking about how it works today, as in PostgreSQL 9.1, 9.2 and 9.3, and most certainly 9.4 as we're not trying t

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

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 unnecessary complex to me > > and I think that in the few cases where th

Re: [HACKERS] GiST support for inet datatypes

2014-02-24 17:55, Bruce Momjian : > pg_upgrade has _never_ modified the old cluster, and I am hesitant to do > that now. Can we make the changes in the new cluster, or in pg_dump > when in binary upgrade mode? It can be possible to update the new operator class in the new cluster as not default,

[HACKERS] What behavior is in this loop?

Hi, 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 compiler:) Regards, -- Mitsumasa KONDO NTT Open Source Software Center -- Sent via pgsql-hack

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

Thank you for the labor for polishing this patch. I have no obvious objection at a glance on this new patch. I agree to commit this if you this is pertinent to commit except for the issue newly revealed by this patch. Though could you let me have some more time to examine this by myself and fully

Re: [HACKERS] jsonb and nested hstore

On Wed, Feb 26, 2014 at 7:42 PM, Andrew Dunstan wrote: > The jsonb set will get larger as time goes on. I don't think either of you > are thinking very clearly about how we would do this. Extensions can't call > each other's code. So the whole notion we have here of sharing the tree-ish > data rep

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On 26 February 2014 15:25, Andres Freund wrote: > On 2014-02-26 15:15:00 +, Simon Riggs wrote: >> On 26 February 2014 13:38, Andres Freund wrote: >> > Hi, >> > >> > On 2014-02-26 07:32:45 +, Simon Riggs wrote: >> >> > * This definitely should include isolationtester tests actually >> >> >

Re: [HACKERS] Unfortunate choice of short switch name in pgbench

Hello Tom, Meh. A progress-reporting feature has use when the tool is working towards completion of a clearly defined task. In the case of pgbench, if you told it to run for -T 60 seconds rather than -T 10 seconds, that's probably because you don't trust a 10-second average to be sufficiently

Re: [HACKERS] Unfortunate choice of short switch name in pgbench

Hello Tom. I just wasted some time puzzling over strange results from pgbench. I eventually realized that I'd been testing against the wrong server, because rather than "-p 65432" I'd typed "-P 65432", thereby invoking the recently added --progress option. pgbench has no way to know that that

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On 26 February 2014 15:25, Andres Freund wrote: >> >> > * Why does ChangeOwner need AEL? >> >> >> >> Ownership affects privileges, which includes SELECTs, hence AEL. >> > >> > So? >> >> That reply could be added to any post. Please explain your concern. > > I don't understand why that means it ne

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

Hi, On 27/02/14 08:35, Christian Kruse wrote: > Hi Peter, Sorry, Stephen of course – it was definitely to early. Best regards, -- Christian Kruse http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services pgpm6lYpan4Df.pgp Description: PGP signatur

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On 26 February 2014 07:32, Simon Riggs wrote: >> * Are you sure AlterConstraint is generally safe without an AEL? It >> should be safe to change whether something is deferred, but not >> necessarily whether it's deferrable? > > We change the lock levels for individual commands. This patch pro