At one point, the question of casting between range types came up. At
first, this seemed like a fairly reasonable suggestion, but now I don't
think I like the semantics.
A normal cast changes between essentially equivalent values in different
domains. For instance 3 as an int4 is equivalent to
On 31.08.2011 09:14, Jeff Davis wrote:
At one point, the question of casting between range types came up. At
first, this seemed like a fairly reasonable suggestion, but now I don't
think I like the semantics.
A normal cast changes between essentially equivalent values in different
domains. For
On 30 August 2011 16:40, Robert Haas robertmh...@gmail.com wrote:
OK, committed.
Thanks.
I'm fine with not back-patching it, on the grounds given.
Cheers,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On tis, 2011-08-30 at 19:11 -0400, Stephen Frost wrote:
* Joe Abbate (j...@freedomcircle.com) wrote:
In order to compare the schema of two presumably identical
databases, I've been diffing the output of pg_dump -Osx.
I'm not sure exactly how it does it, but check_postgres.pl offers this.
On tis, 2011-08-30 at 18:07 -0400, Tom Lane wrote:
Joe Abbate j...@freedomcircle.com writes:
In order to compare the schema of two presumably identical databases,
I've been diffing the output of pg_dump -Osx. However, I've found that
the order of the output is not very reliable.
Yeah,
2011/8/30 Peter Eisentraut pete...@gmx.net:
I think it would be useful to add the following explanation and sample
to the postgresql.conf sample file:
diff --git i/src/backend/utils/misc/postgresql.conf.sample
w/src/backend/utils/misc/postgresql.conf.sample
---
Wilfried Weiss wrote:
I am just trying to compile postgresql-9.0.4 on AIX 6100-06-03-1048
using gcc 4.4.6.
There was also:
[Bug target/46072] AIX linker chokes on debug info for uninitialized
static variables
Does any one know whether there is an alternate way to compile
postgresql on AIX
On lör, 2011-08-27 at 13:32 -0400, Tom Lane wrote:
EXPLAIN SELECT * FROM test1 WHERE sha1 in (SELECT sha1 FROM test2
LIMIT 200);
Here, however, it has apparently not passed this knowledge through
the
LIMIT.
The LIMIT prevents the subquery from being flattened entirely, ie we
don't
Out of curiosity,
is anybody working on $subject? I'm currently planning to work on such a driver,
but given the current stream of new drivers i want to make sure to not
duplicate any efforts...
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
While looking through old emails, I bumped into this:
http://archives.postgresql.org/message-id/25219.1303306...@sss.pgh.pa.us
To recap, setlocale() on Windows is broken for locale names that contain
dots or apostrophes in the country name. That includes Hong Kong
S.A.R., Macau S.A.R., and
Hi list!
I'm getting really surprising planner estimates for a query that's
joining another table via a varchar field. All of this was tested on
PostgreSQL 8.4.8, 9.0.4 and 9.1rc1.
The original query is pretty huge, but I managed to shrink it down to this:
SELECT * FROM email_message where
On 11-08-30 07:58 AM, Weiss, Wilfried wrote:
Hello,
I am just trying to compile postgresql-9.0.4 on AIX 6100-06-03-1048
using gcc 4.4.6.
Unfortunately that was not all.
There was also:
[Bug target/46072] AIX linker chokes on debug info for uninitialized
static variables
This is an IBM
On ons, 2011-08-31 at 15:38 +0300, Marti Raudsepp wrote:
I'm getting really surprising planner estimates for a query that's
joining another table via a varchar field. All of this was tested on
PostgreSQL 8.4.8, 9.0.4 and 9.1rc1.
By any chance, did it work better in 8.4.7?
--
Sent via
On Wed, Aug 31, 2011 at 16:34, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2011-08-31 at 15:38 +0300, Marti Raudsepp wrote:
I'm getting really surprising planner estimates for a query that's
joining another table via a varchar field. All of this was tested on
PostgreSQL 8.4.8, 9.0.4 and
Having trouble installing dblink under PostgreSQL 8.4.4 on MAC OS X 10.4.11
Running make gives the following error:
sed 's,MODULE_PATHNAME,$libdir/dblink,g' dblink.sql.in dblink.sql
gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
On 9 May 2011 20:52, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, May 9, 2011 at 1:41 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
Peter,
I would like to collect some specs on this feature. So does anyone have
links to documentation of existing implementations, or
Peter Eisentraut pete...@gmx.net writes:
On tis, 2011-08-30 at 18:07 -0400, Tom Lane wrote:
Yeah, we've been around on that before. pg_dump does actually sort the
output items (modulo dependency requirements), but it sorts by the same
tag values that are printed by pg_restore -l, and those
On 08/31/2011 10:17 AM, Tom Lane wrote:
Short of that sort of anal-retentiveness, there are going to be cases
where the dump order is a bit unpredictable. IMO what we need is a
reasonable compromise between verbosity and uniqueness, such that in
normal cases (ie, where you *didn't*
On Wed, 2011-08-31 at 09:20 +0300, Heikki Linnakangas wrote:
On 31.08.2011 09:14, Jeff Davis wrote:
First, a range is really a set. So if we take '[1,10)'::int4range and
cast that to numrange, we end up moving from a set of exactly 9 elements
to a set of an infinite number of elements.
I've just stumbled across this, which appears to be a regression from
8.4 that is present in 9.0 and master:
andrew=# create table foo (x int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
foo_pkey for table foo
CREATE TABLE
andrew=# alter table
On 31.08.2011 18:20, Andrew Dunstan wrote:
I've just stumbled across this, which appears to be a regression from
8.4 that is present in 9.0 and master:
andrew=# create table foo (x int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
foo_pkey for table foo
CREATE
On 31.08.2011 18:09, Jeff Davis wrote:
On Wed, 2011-08-31 at 09:20 +0300, Heikki Linnakangas wrote:
On 31.08.2011 09:14, Jeff Davis wrote:
First, a range is really a set. So if we take '[1,10)'::int4range and
cast that to numrange, we end up moving from a set of exactly 9 elements
to a set of
On 08/31/2011 11:24 AM, Heikki Linnakangas wrote:
On 31.08.2011 18:20, Andrew Dunstan wrote:
I've just stumbled across this, which appears to be a regression from
8.4 that is present in 9.0 and master:
andrew=# create table foo (x int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will
On Wed, Aug 31, 2011 at 11:36 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 31.08.2011 18:09, Jeff Davis wrote:
On Wed, 2011-08-31 at 09:20 +0300, Heikki Linnakangas wrote:
On 31.08.2011 09:14, Jeff Davis wrote:
First, a range is really a set. So if we take
hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
OK, this was very helpful. I found out that there is a bug in current
9.0.X, 9.1.X, and HEAD that I introduced recently when I excluded temp
tables. (The bug is not in any released version
Alvaro Herrera wrote:
Excerpts from hubert depesz lubaczewski's message of lun ago 29 14:49:24
-0300 2011:
On Mon, Aug 29, 2011 at 06:54:41PM +0200, hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at 05:28:35PM +0200, hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at
On Wed, Aug 31, 2011 at 12:16 PM, Bruce Momjian br...@momjian.us wrote:
hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
OK, this was very helpful. I found out that there is a bug in current
9.0.X, 9.1.X, and HEAD that I introduced recently
On Wed, Aug 31, 2011 at 12:16:03PM -0400, Bruce Momjian wrote:
hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
OK, this was very helpful. I found out that there is a bug in current
9.0.X, 9.1.X, and HEAD that I introduced recently when
hubert depesz lubaczewski wrote:
INFO: vacuuming pg_toast.pg_toast_106668498
vacuumdb: vacuuming of database etsy_v2 failed: ERROR: could not access
status of transaction 3429738606
DETAIL: Could not open file pg_clog/0CC6: No such file or directory.
Interestingly.
In old dir there
hubert depesz lubaczewski wrote:
On Wed, Aug 31, 2011 at 12:16:03PM -0400, Bruce Momjian wrote:
hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
OK, this was very helpful. I found out that there is a bug in current
9.0.X, 9.1.X,
Excerpts from Bruce Momjian's message of mié ago 31 13:23:07 -0300 2011:
Alvaro Herrera wrote:
Excerpts from hubert depesz lubaczewski's message of lun ago 29 14:49:24
-0300 2011:
On Mon, Aug 29, 2011 at 06:54:41PM +0200, hubert depesz lubaczewski wrote:
On Fri, Aug 26, 2011 at
Alvaro Herrera wrote:
I don't understand the pg_upgrade code here. It is setting the
datfrozenxid and relfrozenxid values to the latest checkpoint's NextXID,
/* set pg_class.relfrozenxid */
PQclear(executeQueryOrDie(conn,
UPDATE
On Wed, Aug 31, 2011 at 01:23:05PM -0400, Bruce Momjian wrote:
Can you get me the 9.0.X pg_class.relfrozenxid for the toast and heap
tables involved?
Sure:
=# select oid::regclass, relfrozenxid from pg_class where relname in
('transactions', 'pg_toast_106668498');
oid
On Sun, Aug 28, 2011 at 8:28 PM, YAMAMOTO Takashi
y...@mwd.biglobe.ne.jp wrote:
On men, 2011-08-22 at 04:09 +, YAMAMOTO Takashi wrote:
i know that postgresql uses ts=4 for C source code.
but how about documatation?
I'd say ideally don't use any tabs at all.
i agree.
It appears to be
On Wed, Aug 31, 2011 at 6:22 AM, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2011-08-27 at 13:32 -0400, Tom Lane wrote:
EXPLAIN SELECT * FROM test1 WHERE sha1 in (SELECT sha1 FROM test2
LIMIT 200);
Here, however, it has apparently not passed this knowledge through
the
LIMIT.
The
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 31, 2011 at 6:22 AM, Peter Eisentraut pete...@gmx.net wrote:
I liked the old one better. ;-)
AFAICS, those plans are identical, except for a minor difference in
the cost of scanning test2.
The point is that the estimate of the result size
FYI, I am working with depesz on IM right now and will report back when
we have a cause of the bug. FYI, I was without electric power for 53
hours, which is why I am late in replying to this report.
---
daveg wrote:
On
On Fri, Aug 12, 2011 at 10:14:58PM +0300, Marko Kreen wrote:
On Thu, Aug 11, 2011 at 5:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
On Wed, Aug 10, 2011 at 9:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... which this approach would create, because digest()
Hi there,
attached is our WIP-patch for 9.2 development source tree, which provides
implementation of SP-GiST (prototype was presented at PGCon-2011, see
http://www.pgcon.org/2011/schedule/events/309.en.html and presentation
for details) as a core feature. Main differences from prototype
On Wed, Aug 31, 2011 at 9:00 AM, Thom Brown t...@linux.com wrote:
On 9 May 2011 20:52, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, May 9, 2011 at 1:41 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
Peter,
I would like to collect some specs on this feature. So does anyone
On tis, 2011-08-30 at 16:25 -0400, Tom Lane wrote:
So I think that as given, this script is only useful for testing
pg_upgrade of $currentversion to $currentversion. Which is surely
better than no test at all, but it would not for example have caught
the 8.3 incompatibility that was just
On ons, 2011-08-31 at 11:18 +0200, Cédric Villemain wrote:
Just a question: can we build a different postgresql.conf for windows
or do we add a windows command example here as well ?
Well, we could make initdb patch it up, but that might seem excessive.
--
Sent via pgsql-hackers mailing list
Back in January/February, a patch was committed to avoid using libintl's
version of setlocale:
http://archives.postgresql.org/pgsql-hackers/2011-01/msg02628.php
The comment says it was about a problem with printf() and friends, so I
wonder, why was that #undef setlocale line put inside the
On Aug 26, 2011, at 5:23 PM, Andrew Dunstan wrote:
On 08/26/2011 04:46 PM, Jim Nasby wrote:
On Aug 26, 2011, at 12:15 PM, Andrew Dunstan wrote:
I knew there would be some bike-shedding about how we specify these things,
which is why I haven't written docs yet.
While we're debating what shade
Excerpts from Jim Nasby's message of mié ago 31 16:45:59 -0300 2011:
On Aug 26, 2011, at 5:23 PM, Andrew Dunstan wrote:
On 08/26/2011 04:46 PM, Jim Nasby wrote:
On Aug 26, 2011, at 12:15 PM, Andrew Dunstan wrote:
I knew there would be some bike-shedding about how we specify these
things,
After running an essentially uneventful* pg_upgrade from 9.0.4 - 9.1rc1, we
are seeing some toast errors logged on the new cluster:
All are of this pattern: ERROR: missing chunk number 0 for toast value 130087
in pg_toast_34735
Have seen the same pattern for a few of the databases in the
On Fri, Apr 2, 2010 at 12:17 PM, Tom Lane t...@postgresql.org wrote:
Log Message:
---
Ensure that contrib/pgstattuple functions respond to cancel interrupts
reasonably promptly, by adding CHECK_FOR_INTERRUPTS in the per-page loops.
Tatsuhito Kasahara
This patch seems to have
Marti Raudsepp ma...@juffo.org writes:
After a bit of digging, I figured out that it uses the same estimate
as a semi-join WITHOUT the client_id restriction.
...
For whatever reason, the 1st query completely ignores the fact that
the client_id clause reduces the result count by a large
Hi there,
attached is WIP-patch for 9.2 development source tree, which provides
implementation of SP-GiST (prototype
was presented at PGCon-2011, see
http://www.pgcon.org/2011/schedule/events/309.en.html and presentation
for details) as a core feature. Main differences from prototype version:
On 08/31/2011 04:03 PM, Alvaro Herrera wrote:
Well, the Unix approach is to use tools that do one thing well to build up more
complex tools. Making pg_dump run some external command to inject things into
the stream seems like the wrong thing given this philosophy. Use pg_dump to get
the
2011/8/31 Peter Eisentraut pete...@gmx.net:
On ons, 2011-08-31 at 11:18 +0200, Cédric Villemain wrote:
Just a question: can we build a different postgresql.conf for windows
or do we add a windows command example here as well ?
Well, we could make initdb patch it up, but that might seem
Hi list,
In current PostgreSQL versions, subquery expressions in the SELECT list
always generate columns with name ?column?
postgres=# select (select 1 as foo);
?column?
1
This patch improves on that:
select (SELECT 1 AS foo) = foo
select exists(SELECT 1) = exists
select
Marti Raudsepp ma...@juffo.org writes:
On Wed, Aug 31, 2011 at 23:59, Tom Lane t...@sss.pgh.pa.us wrote:
Could we see the pg_stats rows for the two join columns?
Sure, but I don't want to send this out to the public list since
[ it's private data ]
Thanks for the data. I set up a comparable
HI all,
(2011/09/01 4:30), Heikki Linnakangas wrote:
Back in January/February, a patch was committed to avoid using libintl's
version of setlocale:
http://archives.postgresql.org/pgsql-hackers/2011-01/msg02628.php
The comment says it was about a problem with printf() and friends, so I
wonder,
Marti Raudsepp ma...@juffo.org writes:
In current PostgreSQL versions, subquery expressions in the SELECT list
always generate columns with name ?column?
...
This patch improves on that:
select (SELECT 1 AS foo) = foo
select exists(SELECT 1) = exists
select array(SELECT 1) = array
hubert depesz lubaczewski wrote:
On Wed, Aug 31, 2011 at 01:23:05PM -0400, Bruce Momjian wrote:
Can you get me the 9.0.X pg_class.relfrozenxid for the toast and heap
tables involved?
Sure:
=# select oid::regclass, relfrozenxid from pg_class where relname in
('transactions',
daveg wrote:
On Mon, Aug 29, 2011 at 07:49:24PM +0200, hubert depesz lubaczewski wrote:
On Mon, Aug 29, 2011 at 06:54:41PM +0200, hubert depesz lubaczewski wrote:
vacuumdb: vacuuming of database etsy_v2 failed: ERROR: could not access
status of transaction 3429738606
DETAIL: Could not
Lou Picciano wrote:
After running an essentially uneventful* pg_upgrade from 9.0.4 -
9.1rc1, we are seeing some toast errors logged on the new cluster:
All are of this pattern: ERROR: missing chunk number 0 for toast value
130087 in pg_toast_34735
Have seen the same pattern for a few of
Bruce Momjian wrote:
Lou Picciano wrote:
After running an essentially uneventful* pg_upgrade from 9.0.4 -
9.1rc1, we are seeing some toast errors logged on the new cluster:
All are of this pattern: ERROR: missing chunk number 0 for toast value
130087 in pg_toast_34735
Have seen
- Original Message -
From: Bruce Momjian br...@momjian.us
To: Lou Picciano loupicci...@comcast.net
Cc: pgsql-hackers@postgresql.org
Sent: Wednesday, August 31, 2011 10:38:01 PM
Subject: Re: [HACKERS] toast error after pg_upgrade 9.0.4 - 9.1rc1
Lou Picciano wrote:
After running an
60 matches
Mail list logo
