On 20-2-2007 8:07 Tom Lane wrote:
It's surely incorrect as a means of getting out of a COPY state. To
tell the truth, if their intention is to close the connection
unceremoniously, they should just do that, ie PQfinish or just quit
the application. So I'd suggest removing that loop.
I think i
On 20-2-2007 4:42 Tom Lane wrote:
"Arjen van der Meijden" <[EMAIL PROTECTED]> writes:
I'm not sure whether this is a php-issue or a postgresql-client-api one, but
when connecting gdb to that process and doing a 'bt' it displays:
#0 0xa7c36d9f in free () from /l
The following bug has been logged online:
Bug reference: 3031
Logged by: Arjen van der Meijden
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.1
Operating system: Debian Linux (etch, 2.6.17 kernel)
Description:PHP (and others?) cannot close a connection when
The following bug has been logged online:
Bug reference: 2441
Logged by: Arjen van der Meijden
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2devel, 05-16
Operating system: Solaris 10
Description:All useable indexes for an IN are used, not just one
Details
Hi Tom,
I found another example, in case you're interested:
This query:
SELECT * FROM meuktracker m
JOIN pwproduktrel p ON tabel = 'm' AND tabelid = m.id
WHERE m.id = (select min(id) from meuktracker where id > 7810);
It works ok if the subquery is replaced by the actual result, but this
on
Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
I found another example, in case you're interested:
Did you apply the patch?
No, it was just another test-case I stumbled upon. And I'd rather nog
install development versions of postgresql on the machine
Hi Tom,
The "zichtbaar" as false is indeed a very rare case and appearantly
isn't occuring right now. There are indeed 46631 rows in total, and all
46631 have the "zichtbaar" as true. Which reminds me to adjust the index
anyway ;-)
It appears to be happening if the fraction of zichtbaar's is
On 13-9-2005 16:25, Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
It's highly unlikely that that query has anything to do with it, since
it's not touching anything but system catalogs and not trying to write
them either.
Indeed, other things trigger it as w
On 13-9-2005 0:26, Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
There is still the question of how the LSN value got corrupted, but
we've probably missed any chance of finding that out now.
As a matter of fact, I just tested it again. Issuing that same query
w
Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
I'll try and see if I can dig up more from the logs and see if I can
test a few reasonable scenario's tomorrow though.
I wasn't able to find anything suspicious at all.
Is it conceivable that the i
Arjen van der Meijden wrote:
On 13-9-2005 23:01, Tom Lane wrote:
I'll try and see if I can dig up more from the logs and see if I can
test a few reasonable scenario's tomorrow though.
I wasn't able to find anything suspicious at all. A smart-shutdown
should've come fr
On 13-9-2005 23:01, Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
That's all? There's something awfully suspicious about that. You're
sure this is 8.0.3?
When I do "select version();"
PostgreSQL 8.0.3 on i686-pc-linux-gnu, compiled by
On 13-9-2005 20:53, Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
Unless reindexing is part of other commands, I didn't do that. The last
time 'grep' was able to find an reference to something being reindexed
was in June, something (maybe me, but
On 13-9-2005 20:04, Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
On 13-9-2005 16:25, Tom Lane wrote:
Well, its an index, not a table. It was the index:
"pg_class_relname_nsp_index" on pg_class(relname, relnamespace).
Ah. So you've reindexed p
c.relname ~ '^pwprijs$'
ORDER BY 2, 3;
I shut down the postgresql-server after the restart again to prevent
further changes to the data-files of it.
Best regards,
Arjen van der Meijden
---(end of broadcast)---
TIP 3: Have you c
15 matches
Mail list logo
