"Alan Choi" writes:
> psql stopped and quit if it encountered an invalid surrogate pair.
Fixed, thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
The following bug has been logged online:
Bug reference: 5729
Logged by: Alan Choi
Email address: alan.c...@emc.com
PostgreSQL version: Version 9.0.1-1
Operating system: Mac OS X 10.6.4
Description:psql stopped after invalid surrogate pair
Details:
psql stopped and
"Dobes Vandermeer" writes:
> Seeing some surprising behavior with the use of age() and comparing the
> result to an interval:
> select current_date,
>age(current_date - interval '123 days') <= interval '120 days',
>age(current_date - interval '122 days') <= interval '120 days',
The following bug has been logged online:
Bug reference: 5728
Logged by: Dobes Vandermeer
Email address: dobes.vanderm...@kashoo.com
PostgreSQL version: 8.4
Operating system: Windows
Description:Unexpected behavior comparing result of age() to an
interval
Details:
S
On Tue, 2010-10-26 at 14:08 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> >> * Operations on hash indexes are not presently WAL-logged, so replay will
> >> not update these indexes. Hash indexes will not be used for query plans
> >> during recovery.
>
> > The initial patch indeed had a
On 26.10.2010 10:48, Heikki Linnakangas wrote:
On 25.10.2010 19:04, Jeff Davis wrote:
On Mon, 2010-10-25 at 14:44 +0300, Heikki Linnakangas wrote:
It seems we should use ReadRecord instead of the lower-level
XLogPageRead function. One difference is that ReadRecord performs a
bunch of sanity che
Heikki Linnakangas writes:
>> * Operations on hash indexes are not presently WAL-logged, so replay will
>> not update these indexes. Hash indexes will not be used for query plans
>> during recovery.
> The initial patch indeed had a special-case in the planner to ignore
> hash indexes during ho
On 26.10.2010 20:47, Tom Lane wrote:
Heikki Linnakangas writes:
There's a note in the docs about this:
Note: Hash index operations are not presently WAL-logged, so hash indexes
might need to be rebuilt with REINDEX after a database crash. For this reason,
hash index use is presently disco
Heikki Linnakangas writes:
> There's a note in the docs about this:
>> Note: Hash index operations are not presently WAL-logged, so hash indexes
>> might need to be rebuilt with REINDEX after a database crash. For this
>> reason, hash index use is presently discouraged.
> though it doesn't ex
On 26.10.2010 20:04, Jan Kantert wrote:
we have set up streaming replication. It works fine in normal cases. We
found out that one query did not work anymore on our slaves. We have
verified that the slaves were up to date and contained all data.
...
master=# CREATE INDEX index_user_lower_login ON
"Jan Kantert" writes:
> After we created the index again, we saw strange problems on the slave:
> master=# CREATE INDEX index_user_lower_login ON users USING hash
> (lower(login::text));
Hash indexes are not replicated. There's seldom any very good reason to
use them in practice, because they a
The following bug has been logged online:
Bug reference: 5727
Logged by: Jan Kantert
Email address: jan-postg...@kantert.net
PostgreSQL version: 9.0.1
Operating system: Ubuntu 10.04 x86_64 2.6.32-22-server #33-Ubuntu SMP
x86_64 GNU/Linux
Description:Indexes broken in
Excerpts from Vincent Maury's message of mar oct 26 10:17:36 -0300 2010:
> Hello
>
> Thank you very much.
> However, postgresql 8.4 can be installed on ubuntu 9.10 live cd. Why wouldn't
> it work with 10.10 live cd?
> I'm aware of RAM considerations, but my database is very light (a few hundred
On Mon, Oct 25, 2010 at 11:03:07AM -0400, Tom Lane wrote:
> Perhaps. The new implementation of VACUUM FULL is really more like a
> CLUSTER, or one of the rewriting variants of ALTER TABLE. Should all
> of those operations result in an update of last_vacuum? From an
> implementation standpoint it
Vincent Maury writes:
> However, postgresql 8.4 can be installed on ubuntu 9.10 live cd. Why wouldn't
> it work with 10.10 live cd?
Either they changed the live CD to use a different filesystem that
doesn't support O_DIRECT, or this is a kernel bug introduced since 9.10.
Hello
Thank you very much.
However, postgresql 8.4 can be installed on ubuntu 9.10 live cd. Why wouldn't
it work with 10.10 live cd?
I'm aware of RAM considerations, but my database is very light (a few hundred
records), so there is no problem running it on a liveUSB.
Thank you very much in adva
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of lun oct 25 23:37:31 -0300 2010:
>> If this really is caused by a WAL setting that's incompatible with the
>> filesystem, maybe we should add a HINT. This makes two reports today,
>> plus apparently at least one more on the Ubuntu sig
Excerpts from Robert Haas's message of lun oct 25 23:37:31 -0300 2010:
> On Mon, Oct 25, 2010 at 5:43 PM, Alvaro Herrera
> wrote:
> > Hmm, my manpage says that open() could fail with EINVAL if O_DIRECT is
> > used and not supported by the filesystem. We use O_DIRECT in some
> > wal_sync_method c
On 25.10.2010 19:04, Jeff Davis wrote:
On Mon, 2010-10-25 at 14:44 +0300, Heikki Linnakangas wrote:
It seems we should use ReadRecord instead of the lower-level
XLogPageRead function. One difference is that ReadRecord performs a
bunch of sanity checks on the record, while XLogPageRead just reads
19 matches
Mail list logo
