On 30 August 2011 16:40, Robert Haas 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:
http://www.postgresql.org/mailpref/pgsql-hack
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
On tis, 2011-08-30 at 18:07 -0400, Tom Lane wrote:
> Joe Abbate 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, we've been ar
2011/8/30 Peter Eisentraut :
> 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
> --- i/src/backend/utils/misc/postgresql.con
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
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 w
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 email_
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 pgs
On Wed, Aug 31, 2011 at 16:34, Peter Eisentraut 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 9.1rc1.
>
>
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 wrote:
> On Mon, May 9, 2011 at 1:41 PM, Bruce Momjian 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 their own spec
>>> > w
Peter Eisentraut 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 aren't cu
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* intentionally
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 T
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 a
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 crea
On Wed, Aug 31, 2011 at 11:36 AM, Heikki Linnakangas
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 '[1,10)'::int4range and
c
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 v
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, 201
On Wed, Aug 31, 2011 at 12:16 PM, 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 I
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 rec
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 ol
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
> > > >
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, 201
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,
> > >
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
> 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
On Wed, Aug 31, 2011 at 6:22 AM, Peter Eisentraut 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.
>>
>> T
Robert Haas writes:
> On Wed, Aug 31, 2011 at 6:22 AM, Peter Eisentraut 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 is worse in 8.4.8.
I am not, h
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 Mo
On Fri, Aug 12, 2011 at 10:14:58PM +0300, Marko Kreen wrote:
> On Thu, Aug 11, 2011 at 5:46 PM, Tom Lane wrote:
> > Marko Kreen writes:
> >> On Wed, Aug 10, 2011 at 9:19 PM, Tom Lane wrote:
> >>> ... which this approach would create, because digest() isn't restricted
> >>> to just those algorith
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 version
On Wed, Aug 31, 2011 at 9:00 AM, Thom Brown wrote:
> On 9 May 2011 20:52, Merlin Moncure wrote:
>> On Mon, May 9, 2011 at 1:41 PM, Bruce Momjian wrote:
>>> Josh Berkus wrote:
Peter,
> I would like to collect some specs on this feature. So does anyone have
> links to document
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 r
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 lis
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 l
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
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
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 9.1
On Fri, Apr 2, 2010 at 12:17 PM, Tom Lane 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 overlooked pgstatinde
Marti Raudsepp 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 factor.
Could we
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:
1.
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 bit
2011/8/31 Peter Eisentraut :
> 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.
sur
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
sele
Marti Raudsepp writes:
> On Wed, Aug 31, 2011 at 23:59, Tom Lane 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 test case and duplicated
you
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 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
> D
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:
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 f
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
> >
>
- Original Message -
From: "Bruce Momjian"
To: "Lou Picciano"
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 essentially uneventful* pg_upgrad
On Wed, Aug 31, 2011 at 09:54:20PM -0400, Bruce Momjian wrote:
> Working with depesz, I have found the cause. The code I added to fix
> pg_upgrade in 9.0.4 and earlier releases didn't handle old 8.3 servers
> properly. I mistakenly processed toast table with the same pg_dump
> query as used for p
59 matches
Mail list logo
