The following bug has been logged online:
Bug reference: 3291
Logged by: Todd Frankson
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Windows 2003 Server
Description:Query tool not returning all results
Details:
When selecting From a Text
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The problem I was actually investigating was that pgstats does not seem
> > to count certain scans of the index on the b table. I haven't been able
> > to reproduce the bug.
>
> Strange. It could easily be version-specific though
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, we've always done so. I'm a bit surprised though that it's
>> letting you drop the index --- isn't that index required for the FK
>> constraint? Exactly what is the constraint anyway?
> create table a (a int primary key);
> cr
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > (This is on 8.2) What is happening here -- are we caching the plan for
> > the FK check query?
>
> Yeah, we've always done so. I'm a bit surprised though that it's
> letting you drop the index --- isn't that index required for the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> (This is on 8.2) What is happening here -- are we caching the plan for
> the FK check query?
Yeah, we've always done so. I'm a bit surprised though that it's
letting you drop the index --- isn't that index required for the FK
constraint? Exactly what
I know that in 8.3 we have the new plan caching mechanism which fixes
this, but I am wondering if this particular problem was known:
alvherre=# delete from a where a = 2;
ERROR: update o delete en «a» viola la llave foránea «b_a_fkey» en «b»
DETAIL: La llave (a)=(2) todavía es referida desde la
Yes, #2829 seems quite similar to my plight. I did take a look through
the code tree and there appear to be checks for an EINTR status within
loops in src/backend/libpq/pqcomm.c (line 725 in function pq_recvbuf and
line 1057 in function internal_flush), that could point to the problem.
I don't
The following bug has been logged online:
Bug reference: 3290
Logged by: Indrek
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.9-1
Operating system: Windows XP
Description:can't install
Details:
I have downloaded this file: postgresql-8.1.9-1.zip
But I can
nilay çeter wrote:
Yes,it is the same query, and had worked on PostgreSQL8.0 ,but although I
had already added "onay_durum" to from clause and it did not work on 8.2,I
have changed the 'add_missing_from = off ' and made it on in conf. file but
it didn't work too.
I have no idea about what to do:
Hi!
Stephan Szabo wrote:
>>> "delete from foo" fails:
>>> ERROR: update or delete on table "bar" violates foreign key constraint
>>> "foobar_fk0" on table "foobar"
>>> SQL state: 23503
>>> Detail: Key (bar_id)=(1) is still referenced from table "foobar".
>>> Context: SQL statement "DELETE FROM ON
One more quick addendum...I tried this with non-SSL connections, and
this problem did *not* arise when using non-SSL connections.
Peter Koczan wrote:
Yes, #2829 seems quite similar to my plight. I did take a look through
the code tree and there appear to be checks for an EINTR status within
lo
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
12 matches
Mail list logo
