Heikki Linnakangas writes:
> Tom Lane wrote:
>> 2. By chance, a shared-cache-inval flush comes through while it's doing
>> that, causing all non-open, non-nailed relcache entries to be discarded.
>> Including, in particular, the one that is "next" according to the
>> hash_seq_search's status.
> I
You are right.
This is solved in 8.4 and is in the release notes. Even thought the 8.4 has a
bug in displaying the SSL mode and that’s why I didn’t installed at the first
place, then I realized is only a display problem and if you write in the
registry directly everything is ok.
I have posted a
Hi,
One of the tables in a client production system has several timestamp
with time zone fields, in one of those fields they store '1900-01-01
00:00:00'::timestamp with time zone where there is no valid value (a
legacy from another dbms)...
pg = 8.4.1
timezone 'America/Guayaquil'
yesterday we fo
Jaime Casanova writes:
> One of the tables in a client production system has several timestamp
> with time zone fields, in one of those fields they store '1900-01-01
> 00:00:00'::timestamp with time zone where there is no valid value (a
> legacy from another dbms)...
This will be interpreted as 1
The following bug has been logged online:
Bug reference: 5081
Logged by: Stefan
Email address: s...@drbott.de
PostgreSQL version: 8.3.7
Operating system: FreeBSD 7.2
Description:ON INSERT rule does not work correctly
Details:
I'm trying to implement an "insert_or_up
The following bug has been logged online:
Bug reference: 5082
Logged by: smuffy
Email address: vday1...@gmail.com
PostgreSQL version: 8.4.0
Operating system: opensuse 10.2
Description:I can't get logfile( achive )
Details:
hello.
My DB can't make a logfile( archive
I wrote:
> I'll get you a real fix as soon as I can, but might not be till
> tomorrow.
The attached patch (against 8.4.x) fixes the problem as far as I can
tell. Please test.
regards, tom lane
Index: src/backend/utils/cache/relcache.c
I wrote:
> Interestingly, the bug can no longer be reproduced in CVS HEAD, because
> pg_database no longer has a trigger. We had better fix it anyway of
> course, since future hash collisions are unpredictable. I'm wondering
> though whether to bother back-patching further than 8.4. Thoughts?
I
