Hi All,
On Tue, May 13, 2014 at 9:44 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, May 13, 2014 at 12:36 PM, Rohit Goyal rhtgyl...@gmail.com wrote:
This pattern the above found many times. Please guide me through!!!
IIRC, people have been working around this by setting
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
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
On Tue, May 20, 2014 at 9:57 AM, Andrew Dunstan and...@dunslane.net 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 1
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 Mon, May 19, 2014 at 9:22 PM, Dilip kumar dilip.ku...@huawei.com 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
On Tue, May 20, 2014 at 4:50 AM, Alexander Korotkov aekorot...@gmail.comwrote:
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
Robert Haas robertmh...@gmail.com writes:
On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan and...@dunslane.net 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
David Rowley dgrowle...@gmail.com 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
On Mon, Mar 17, 2014 at 1:16 PM, Haribabu Kommi
kommi.harib...@gmail.com wrote:
On Fri, Feb 21, 2014 at 12:02 PM, Haribabu Kommi
kommi.harib...@gmail.com wrote:
On Thu, Feb 20, 2014 at 10:06 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
On Thu, Feb 20, 2014 at 10:23 AM, Haribabu
On 2014-05-19 13:45:15 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
On 05/20/2014 07:09 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, May 19, 2014 at 7:58 PM, Andrew Dunstan and...@dunslane.net 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
Andrew Dunstan and...@dunslane.net 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
On Fri, May 16, 2014 at 1:22 PM, Peter Geoghegan p...@heroku.com 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
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
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??
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 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.
Well, I
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?
There are
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 inconsistent with
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
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_recvlogical,
On Mon, May 19, 2014 at 11:30:48AM -0400, David Johnston wrote:
On Mon, May 19, 2014 at 10:23 AM, Bruce Momjian br...@momjian.us 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
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
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:
On Tue, May 20, 2014 at 11:23 AM, Pavel Stehule pavel.steh...@gmail.com 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
On Tue, May 20, 2014 at 11:40 AM, Peter Geoghegan p...@heroku.com 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
2014-05-20 20:40 GMT+02:00 Peter Geoghegan p...@heroku.com:
On Tue, May 20, 2014 at 11:23 AM, Pavel Stehule pavel.steh...@gmail.com
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
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
On Tue, May 20, 2014 at 12:03 PM, Pavel Stehule pavel.steh...@gmail.com 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
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: Polygon,
coordinates: [[[-122.476849622729347,
On Tue, May 20, 2014 at 12:38 PM, Pavel Stehule pavel.steh...@gmail.com 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: b:
On 21/05/14 01:42, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
2014-05-20 21:45 GMT+02:00 Peter Geoghegan p...@heroku.com:
On Tue, May 20, 2014 at 12:38 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
NOTICE: a: {type: Feature, geometry: null, properties:
{TO_ST:
null, BLKLOT: 1245063, STREET: null, FROM_ST: null, LOT_NUM:
063, ST_TYPE: null,
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
Failure,
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 a
On 05/20/2014 03:59 PM, Gavin Flower wrote:
On 21/05/14 01:42, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
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
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:
On May 20, 2014, at 4:39 PM, Andrew Dunstan and...@dunslane.net 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
David E. Wheeler da...@justatheory.com writes:
On May 20, 2014, at 4:39 PM, Andrew Dunstan and...@dunslane.net 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?
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
On Tue, May 20, 2014 at 4:17 PM, Pavel Stehule pavel.steh...@gmail.com 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
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 help for help.
2014-05-21 3:22 GMT+02:00 Peter Geoghegan p...@heroku.com:
On Tue, May 20, 2014 at 4:17 PM, Pavel Stehule pavel.steh...@gmail.com
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
45 matches
Mail list logo
