I have the following table
Table "public.authorsort"
Column | Type | Modifiers
--+---+---
ordernum | integer |
handle | character varying(30) |
Indexes: author_handle_idx btree (handle)
As you can tell I have a
"Blanco, Jose" <[EMAIL PROTECTED]> writes:
> Well, this was running very slowly, so I droped the index and recreated
> it, and then it ran quickly.
Sounds like you had a bloated index.
> I'm running versin 7.3
Consider switching to something more modern --- 7.3 is vastly slower
than current rele
Hi,
On Thu, 17 May 2007, Tom Lane wrote:
Christian Kratzer <[EMAIL PROTECTED]> writes:
It's not that simple though. The ipv6 stack will propably not allow
users to build sockets from addresses in link local scope from a
specific interface to a server bound to a global address, ::1, or
scoped
Tom Lane wrote:
> Well, let's be clear: this is entirely the fault of the inet type not
> accepting what we now know to be RFC-compliant address specifications.
> So we ought to put fixing that on the TODO list. It's not happening
> for 8.3 though, let alone in existing release branches, so we'd b
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Thu, May 17, 2007 at 02:39:55PM -0400, Tom Lane wrote:
>> It seems the correct solution here is to extend the inet type to support
>> RFC4007 "zone_id" strings. Yech. Not going to happen as a bug fix,
>> but we should probably put it on the TODO li
Christian Kratzer <[EMAIL PROTECTED]> writes:
> It's not that simple though. The ipv6 stack will propably not allow
> users to build sockets from addresses in link local scope from a
> specific interface to a server bound to a global address, ::1, or
> scoped to any other interface. After all li
Christian Kratzer <[EMAIL PROTECTED]> writes:
> On Thu, 17 May 2007, Tom Lane wrote:
>> As a temporary workaround, should we hack the server to suppress any
>> %-foo found in the result of getnameinfo()?
> Not sure what that would buy us.
Mostly, it would buy us not having pg_stat_activity fail c
Hi,
On Thu, 17 May 2007, Tom Lane wrote:
It seems the correct solution here is to extend the inet type to support
RFC4007 "zone_id" strings. Yech. Not going to happen as a bug fix,
but we should probably put it on the TODO list.
propably yes. But we should bear in mind that addresses of dif
On Thu, May 17, 2007 at 02:39:55PM -0400, Tom Lane wrote:
> It seems the correct solution here is to extend the inet type to support
> RFC4007 "zone_id" strings. Yech. Not going to happen as a bug fix,
> but we should probably put it on the TODO list.
>
> As a temporary workaround, should we hac
Hi,
On Thu, 17 May 2007, Andrew Sullivan wrote:
On Thu, May 17, 2007 at 07:29:47PM +0200, Christian Kratzer wrote:
supporting scoped addresses could have their uses but then again
theres nothing stopping you to bind multiple global ipv6 addresses
to your loopback interface which would work fin
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Thu, May 17, 2007 at 06:42:39PM +0200, Christian Kratzer wrote:
>> of a specific interface. This is why bsd based oprating systems append
>> %ifname to the address so that they know which Interface this address
> Oh, I forgot about that wart in RF
On Thu, May 17, 2007 at 07:29:47PM +0200, Christian Kratzer wrote:
> supporting scoped addresses could have their uses but then again
> theres nothing stopping you to bind multiple global ipv6 addresses
> to your loopback interface which would work fine for disconnected
> setups and it might be a b
Hi,
On Thu, 17 May 2007, Andrew Sullivan wrote:
On Thu, May 17, 2007 at 06:42:39PM +0200, Christian Kratzer wrote:
of a specific interface. This is why bsd based oprating systems append
%ifname to the address so that they know which Interface this address
Oh, I forgot about that wart in RFC4
Hi,
On Thu, 17 May 2007, Tom Lane wrote:
Andrew Sullivan <[EMAIL PROTECTED]> writes:
On Mon, May 14, 2007 at 08:32:21PM -0600, Brian Hirt wrote:
I have postgresql installed on a mac, and I'm connecting from another
mac on the network using ip6. When I try to select out of
pg_stat_activity
On Thu, May 17, 2007 at 06:42:39PM +0200, Christian Kratzer wrote:
> of a specific interface. This is why bsd based oprating systems append
> %ifname to the address so that they know which Interface this address
Oh, I forgot about that wart in RFC4007. Thanks for the cluestick.
> There is prop
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Mon, May 14, 2007 at 08:32:21PM -0600, Brian Hirt wrote:
>> I have postgresql installed on a mac, and I'm connecting from another
>> mac on the network using ip6. When I try to select out of
>> pg_stat_activity i get this error. I suspect the
On Mon, May 14, 2007 at 08:32:21PM -0600, Brian Hirt wrote:
> I have postgresql installed on a mac, and I'm connecting from another
> mac on the network using ip6. When I try to select out of
> pg_stat_activity i get this error. I suspect the %en0 has something
> to do with the problem, b
I have postgresql installed on a mac, and I'm connecting from another
mac on the network using ip6. When I try to select out of
pg_stat_activity i get this error. I suspect the %en0 has something
to do with the problem, but I'm no IP6 expert.
load=# select * from pg_stat_activity ;
ERRO
=?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?=
<[EMAIL PROTECTED]> writes:
> I installed an newer rpm of the glibc (2.2.2-8.1 / 2.2.2-4 before) und
> reinitialized the database with locale=3DC.
> Just after installing the rpm, the problem was still there (reindex I =
> did),
> but after
Title: AW: AW: [BUGS] strange problem
Hi,
I installed an newer rpm of the glibc (2.2.2-8.1 / 2.2.2-4 before) und reinitialized the database with locale=C.
Just after installing the rpm, the problem was still there (reindex I did), but after dump/initdb --locale=C/import the problem was
=?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?=
<[EMAIL PROTECTED]> writes:
> This happend to 0.3% of all rows in this table, after dump/import exactly
> the same rows were affected.
So you can reproduce the problem after dumping/reloading? If you could
send me the dump file (off-list!)
Title: AW: [BUGS] strange problem
Hi,
I did reindex, vacuum , dump/import, ...
I also tried 7.3.1
-->> It happens only with btree index on that column, without index it works, with hash index also no problem.
This happend to 0.3% of all rows in this table, after dump/import e
=?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?=
<[EMAIL PROTECTED]> writes:
> ici=3D# select id,pseudonym from user_all where pseudonym =3D
> 'autologin_funkey';
> id | pseudonym
> +---
> (0 rows)
> ici=3D# select id,pseudonym from user_all where pseudonym ~
> '^autologin_fun
Title: strange problem
Hi,
I don't know what is going on here. Maybe somebody can help.
Iam using postgresql 7.3.
ici=# select id,pseudonym from user_all where pseudonym = 'autologin_funkey';
id | pseudonym
+---
(0 rows)
ici=# select id,pseudonym from user_all where pseud
24 matches
Mail list logo
