On Tue, May 20, 2014 at 5:10 AM, Jeff Janes wrote:
> What would be a good way of doing that? Mostly I've just been sharing it
> on google drive when I find something. Should I fork the mirror from
> github (https://github.com/postgres/postgres)? Forking the entire
> codebase just to have a 200
2014-05-21 3:22 GMT+02:00 Peter Geoghegan :
> On Tue, May 20, 2014 at 4:17 PM, Pavel Stehule
> wrote:
> > table dump is downloadable from http://pgsql.cz/data/data.dump.gz
>
> This looks like an over-zealous assertion, without any user-visible
> consequences. Mea culpa.
>
> Attached patch correct
On Tue, May 20, 2014 at 03:25:00PM -0600, Jeff Ross wrote:
> Here's a sample from a different database that failed with the same problem.
>
> Error: Mismatch of relation OID in database "UDB": old OID 1163225,
> new OID 22588
> postgres@vdev1commandprompt2:~$ psql "UDB"
> psql (9.3.4)
> Type "hel
On Tue, May 20, 2014 at 4:17 PM, Pavel Stehule wrote:
> table dump is downloadable from http://pgsql.cz/data/data.dump.gz
This looks like an over-zealous assertion, without any user-visible
consequences. Mea culpa.
Attached patch corrects the problem. I also noticed in passing that
there is ano
Hi!
create table xxx ( t text);
insert into xxx select 'x' || v::text from generate_series(1, 291) as v;
insert into xxx values ('');
create index xxxidx on xxx using spgist (t);
And postgres will eat memory forever. It seems to me that checkAllTheSame
wrongly decides that all tuples are the
"David E. Wheeler" writes:
> On May 20, 2014, at 4:39 PM, Andrew Dunstan wrote:
>> I have just noticed as I am preparing my slides well ahead of time :-) that
>> we haven't documented the inequality operators of jsonb. Is that deliberate
>> or an oversight?
> ThatÂs gotta be an oversight. The
On May 20, 2014, at 4:39 PM, Andrew Dunstan wrote:
> I have just noticed as I am preparing my slides well ahead of time :-) that
> we haven't documented the inequality operators of jsonb. Is that deliberate
> or an oversight?
That’s gotta be an oversight. The hash and btree index support is do
On 5/20/14, 2:22 PM, Bruce Momjian wrote:
On Tue, May 20, 2014 at 12:59:31PM -0600, Jeff Ross wrote:
Removing support functions from new cluster ok
Copying user relation files
/var/lib/postgresql/8.4/main/base/4275487/4278965
Mismatch of relation OID in database "FNBooking":
I have just noticed as I am preparing my slides well ahead of time :-)
that we haven't documented the inequality operators of jsonb. Is that
deliberate or an oversight?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 05/20/2014 03:59 PM, Gavin Flower wrote:
On 21/05/14 01:42, Tom Lane wrote:
Andrew Dunstan writes:
On 05/20/2014 07:09 AM, Tom Lane wrote:
Robert's got a point here. In my usage, the annoying thing is not animals
that take a long time to report in; it's the ones that lie about the
snapsh
Hello
I don't know a doc about jsonb indexes
"But in jsonb_path_ops, each index item is a hash of both the value and the
key(s) leading to it; for example to index {"foo": {"bar": "baz"}}, a
single index item would be created incorporating all three of foo, bar, and
baz into the hash value. Thus
On Tue, May 20, 2014 at 12:59:31PM -0600, Jeff Ross wrote:
> Removing support functions from new cluster ok
> Copying user relation files
> /var/lib/postgresql/8.4/main/base/4275487/4278965
> Mismatch of relation OID in database "FNBooking": old OID 4279499,
> new OID 19792
> Fail
2014-05-20 21:45 GMT+02:00 Peter Geoghegan :
> On Tue, May 20, 2014 at 12:38 PM, Pavel Stehule
> wrote:
> > NOTICE: a:>> {"type": "Feature", "geometry": null, "properties":
> {"TO_ST":
> > null, "BLKLOT": "1245063", "STREET": null, "FROM_ST": null, "LOT_NUM":
> > "063", "ST_TYPE": null, "ODD_EVE
On 21/05/14 01:42, Tom Lane wrote:
Andrew Dunstan writes:
On 05/20/2014 07:09 AM, Tom Lane wrote:
Robert's got a point here. In my usage, the annoying thing is not animals
that take a long time to report in; it's the ones that lie about the
snapshot time (which is how you get "512abc4 in the
On Tue, May 20, 2014 at 12:38 PM, Pavel Stehule wrote:
> NOTICE: a:>> {"type": "Feature", "geometry": null, "properties": {"TO_ST":
> null, "BLKLOT": "1245063", "STREET": null, "FROM_ST": null, "LOT_NUM":
> "063", "ST_TYPE": null, "ODD_EVEN": null, "BLOCK_NUM": "1245", "MAPBLKLOT":
> "1245061"}}<
NOTICE: a:>> {"type": "Feature", "geometry": null, "properties": {"TO_ST":
null, "BLKLOT": "1245063", "STREET": null, "FROM_ST": null, "LOT_NUM":
"063", "ST_TYPE": null, "ODD_EVEN": null, "BLOCK_NUM": "1245", "MAPBLKLOT":
"1245061"}}<<<
NOTICE: b:>> {"type": "Feature", "geometry": {"type": "Polyg
On Tue, May 20, 2014 at 12:03 PM, Pavel Stehule wrote:
> va.type is zero .. jbvNull
Thanks...any luck with identifying the two JSON documents?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
Hi all,
I'm trying to pg_upgrade an 8.4.21 to 9.3.4.
The is on Debian 7--both versions were installed from apt.postgresql.org
and are encoding "UTF8" and locale "C".
Here's the error:
/usr/lib/postgresql/9.3/bin/pg_upgrade \
-b /usr/lib/postgresql/8.4/bin/ \
-B /usr/lib/post
2014-05-20 20:40 GMT+02:00 Peter Geoghegan :
> On Tue, May 20, 2014 at 11:23 AM, Pavel Stehule
> wrote:
> > TRAP: FailedAssertion("!(va.type == jbvArray || va.type == jbvObject)",
> > File: "jsonb_util.c", Line: 208)
>
> So, what type is va.type, if not one of those two?
>
va.type is zero .. jbv
On Tue, May 20, 2014 at 11:40 AM, Peter Geoghegan wrote:
>
> So, what type is va.type, if not one of those two?
You should be able to figure out which pair of JSON documents are
being compared by printing JsonbIterator.dataProper within GDB (that
is, you should do so for both ita and itb within
c
On Tue, May 20, 2014 at 11:23 AM, Pavel Stehule wrote:
> TRAP: FailedAssertion("!(va.type == jbvArray || va.type == jbvObject)",
> File: "jsonb_util.c", Line: 208)
So, what type is va.type, if not one of those two?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
Hello
I created relative large (about 200K lines) simple table (one jsonb column):
It works, but I got a errors:
TRAP: FailedAssertion("!(va.type == jbvArray || va.type == jbvObject)",
File: "jsonb_util.c", Line: 208)
LOG: server process (PID 3851) was terminated by signal 6: Aborted
DETAIL: F
On Tue, 2014-05-20 at 09:52 -0700, Jeff Davis wrote:
> 2. Why would any tuple have 2 nodes? If there are some non-empty ranges,
> why not make a centroid and have 4 or 5 nodes?
This is slightly more complicated than I thought, because we need to do
something about the root node if a bunch of empty
On Mon, May 19, 2014 at 11:30:48AM -0400, David Johnston wrote:
> On Mon, May 19, 2014 at 10:23 AM, Bruce Momjian wrote:
>
> On Thu, May 15, 2014 at 06:08:47PM -0700, David G Johnston wrote:
> > Some errors and suggestions - my apologizes for the format as I do not
> have
> > a pr
Josh Berkus wrote:
> On 05/20/2014 12:38 PM, Andres Freund wrote:
> > On 2014-05-20 12:33:20 -0400, Josh Berkus wrote:
> >> On 05/20/2014 12:07 PM, Alvaro Herrera wrote:
> >>> Josh Berkus wrote:
> I can't find the thread now, but I'm pretty sure that we decided to
> change the name of pg_
I am trying to understand the rangetypes spgist code and its interaction
with empty ranges. (Slightly embarrassing, because I reviewed the code.)
I see an old email here:
http://www.postgresql.org/message-id/50145a9c.7080...@enterprisedb.com
But still don't have a clear picture.
What I don't und
On 05/20/2014 12:38 PM, Andres Freund wrote:
> On 2014-05-20 12:33:20 -0400, Josh Berkus wrote:
>> On 05/20/2014 12:07 PM, Alvaro Herrera wrote:
>>> Josh Berkus wrote:
I can't find the thread now, but I'm pretty sure that we decided to
change the name of pg_recvlogical, because its incons
On 2014-05-20 12:33:20 -0400, Josh Berkus wrote:
> On 05/20/2014 12:07 PM, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> >> I can't find the thread now, but I'm pretty sure that we decided to
> >> change the name of pg_recvlogical, because its inconsistent with other
> >> client utils? No?
> >
>
On 05/20/2014 12:07 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> I can't find the thread now, but I'm pretty sure that we decided to
>> change the name of pg_recvlogical, because its inconsistent with other
>> client utils? No?
>
> There are others who think this has already happened.
>
We
Josh Berkus wrote:
> I can't find the thread now, but I'm pretty sure that we decided to
> change the name of pg_recvlogical, because its inconsistent with other
> client utils? No?
There are others who think this has already happened.
--
Álvaro Herrerahttp://www.2ndQuadrant.com
On 05/20/2014 08:48 AM, Josh Berkus wrote:
I can't find the thread now, but I'm pretty sure that we decided to
change the name of pg_recvlogical, because its inconsistent with other
client utils? No?
This thread, perhaps??
http://www.postgresql.org/message-id/20130923084634.ga15...@awork2.an
I can't find the thread now, but I'm pretty sure that we decided to
change the name of pg_recvlogical, because its inconsistent with other
client utils? No?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
On Fri, May 16, 2014 at 1:22 PM, Peter Geoghegan wrote:
>
> I have performed a new benchmark related to my ongoing experimentation
> around caching and buffer manager scalability. The benchmark tests a
> minor refinement of the prototype patch previously posted [1]. The
> patch itself is still ver
Andrew Dunstan writes:
> On 05/20/2014 07:09 AM, Tom Lane wrote:
>> Robert's got a point here. In my usage, the annoying thing is not animals
>> that take a long time to report in; it's the ones that lie about the
>> snapshot time (which is how you get "512abc4 in the middle of a bunch of
>> ef9a
On 05/20/2014 07:09 AM, Tom Lane wrote:
Robert Haas writes:
On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan wrote:
Well, the original code was put in for a reason, presumably that we were
getting some stale data and wanted to exclude it. So I'm unwilling to throw
it out altogether. If someon
On 2014-05-19 13:45:15 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-05-19 11:25:04 -0400, Tom Lane wrote:
> >> No, we'd have two independent entries, each with its own correct refcount.
> >> When the refcount on the no-longer-linked-in-the-hashtable entry goes to
> >> zero, it'd be l
On Mon, Mar 17, 2014 at 1:16 PM, Haribabu Kommi
wrote:
> On Fri, Feb 21, 2014 at 12:02 PM, Haribabu Kommi
> wrote:
>> On Thu, Feb 20, 2014 at 10:06 PM, Ashutosh Bapat
>> wrote:
>>>
>>> On Thu, Feb 20, 2014 at 10:23 AM, Haribabu Kommi
>>> wrote:
On Thu, Feb 20, 2014 at 2:26 PM, Amit Ka
David Rowley writes:
> I'm also now wondering if I need to do some extra tests in the existing
> code to ensure that the subquery would have had no side affects.
You should probably at least refuse the optimization if the subquery's
tlist contains volatile functions.
Functions that return sets m
Robert Haas writes:
> On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan wrote:
>> Well, the original code was put in for a reason, presumably that we were
>> getting some stale data and wanted to exclude it. So I'm unwilling to throw
>> it out altogether. If someone can propose a reasonable sanity
On Tue, May 20, 2014 at 4:50 AM, Alexander Korotkov wrote:
> I found that sometimes larger maintenance_work_mem leads to larger GIN
> index. That is quite strange. ISTM that it's related to posting lists
> compression but I can't figure out how exactly it is.
>
It appears to be not related to pos
On Mon, May 19, 2014 at 9:22 PM, Dilip kumar wrote:
> On 19 May 2014 12:15 David Rowley Wrote,
>
>
>
>
>
> May be we can convert my above example like below à in this case we
> have unique index on field a and we are limiting it by first 100 tuple
> (record are already order because of index)
Hi hackers,
I found a bug that causes a crash when assertion is enabled and LWLOCK_STATS is
defined.
I've tested with Debian 7.5 (3.2.0-4-amd64) on VMware fusion 6, but this bug
seems to be platform-independent and should reproduce in other environments.
A patch to fix the bug is also attached.
On Tue, May 20, 2014 at 9:57 AM, Andrew Dunstan wrote:
>
> On 05/20/2014 03:39 AM, Rohit Goyal wrote:
>
>> Hi All,
>>
>> Just adding the actual error again.
>>
>> I run the the *dbt2-pgsql-build-db -w 1 *
>>
>>
>> Output directory of data files: current directory
>>
>> *Generating data files for
On 05/20/2014 03:39 AM, Rohit Goyal wrote:
Hi All,
Just adding the actual error again.
I run the the *dbt2-pgsql-build-db -w 1 *
Output directory of data files: current directory
*Generating data files for 1 warehouse(s)...*
*Generating item table data...*
*BEGIN*
*ERROR: invalid byte seque
Hi All,
Just adding the actual error again.
I run the the *dbt2-pgsql-build-db -w 1 *
Output directory of data files: current directory
*Generating data files for 1 warehouse(s)...*
*Generating item table data...*
*BEGIN*
*ERROR: invalid byte sequence for encoding "UTF8": 0xf9*
*CONTEXT: COPY
Hi All,
On Tue, May 13, 2014 at 9:44 PM, Peter Geoghegan wrote:
>
> On Tue, May 13, 2014 at 12:36 PM, Rohit Goyal wrote:
>
>> This pattern the above found many times. Please guide me through!!!
>>
>
> IIRC, people have been working around this by setting
> standard_conforming_strings to "off"
46 matches
Mail list logo
