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
- 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
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
> >
>
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
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:
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',
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
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:
> 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 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
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
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
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.
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
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
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
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
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
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 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
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 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
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 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
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
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
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
> 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 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
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,
> > >
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
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
> > > >
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
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
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
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
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
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
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 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 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
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 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
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
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 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
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 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.
>
>
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 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
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_
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
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
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
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
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
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
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 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
59 matches
Mail list logo
