On Mon, 27 Nov 2006, Shawn Tayler wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2788
> Logged by: Shawn Tayler
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1.5
> Operating system: Linux 2.6.17
> Description:Create Function operat
"Thomas H." <[EMAIL PROTECTED]> writes:
> regarding pg_dump: where there some changes from b3 to rc1 that would
> explain the resulting rc1 pg_dump output (-c) being half as big as with b3?
No...
regards, tom lane
---(end of broadcast)---
This really should have been asked on pgsql-performance and would probably
get a better response there..
On Sun, Nov 26, 2006 at 16:35:52 +,
Michael Simms <[EMAIL PROTECTED]> wrote:
> PostgreSQL version: 8.1.4
> Operating system: Linux kernel 2.6.12
> Description:Performance seriou
We have never promised backward compatibility of pg_dump output to older
server versions.
regarding pg_dump: where there some changes from b3 to rc1 that would
explain the resulting rc1 pg_dump output (-c) being half as big as with b3?
i've rerun pg_dump several times with the same result, and
"Patrick Hayes" <[EMAIL PROTECTED]> writes:
> I get the following error.
> postgres-# language plpgsql;
> ERROR: unrecognized exception condition "no_data"
> CONTEXT: compile of PL/pgSQL function "chip_pps_data_check" near line 101
Indeed, because no_data is not an error condition, so EXCEPTION
"Alaa El Gohary" <[EMAIL PROTECTED]> writes:
> this message appears when trying to open an application
> Fatal:could not open file"/usr/local/pgsql/data/global/1262":too many open
> files in system
Try reducing max_files_per_process. Your kernel is evidently promising
more than it can deliver abo
"Michael Simms" <[EMAIL PROTECTED]> writes:
> OK, we have a database that runs perfectly well after a dump and restore,
> but over a period of a month or two, it just degrades to the point of
> uselessness.
> vacuumdb -a is run every 24 hours. We have also run for months at a time
> using -a -z but
"Greg Peters" <[EMAIL PROTECTED]> writes:
> As you can see, the primary key is exported as a bigint, with a separate
> section for the sequence. This differs to the way 8.1 dumps the same table
> below:
This is an intentional change that fixes a lot of corner cases such as
renamed sequences. The
The following bug has been logged online:
Bug reference: 2789
Logged by: Lucian Capdefier
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Windows XP
Description:problem with delete statement
Details:
I have noticed a problem with the DEL
Tom Lane wrote:
> "Chris Jones" <[EMAIL PROTECTED]> writes:
>> I used to be decent with gdb, so let me know if there's anything I can do as
>> far as backtraces, etc.
>
> Try setting a breakpoint at errfinish() and backtracing from there.
Breakpoint 1, 0x081cd8ba in errfinish ()
(gdb) bt
#0 0x08
The following bug has been logged online:
Bug reference: 2788
Logged by: Shawn Tayler
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Linux 2.6.17
Description:Create Function operator Broken?
Details:
I have been through the online DOC's
The following bug has been logged online:
Bug reference: 2786
Logged by: Gilberto Xavier
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Linux and Windows
Description:PGADMIN 1.6
Details:
Where was set the backup and restore capability int
The following bug has been logged online:
Bug reference: 2787
Logged by: Pete Deffendol
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Red Hat Enterprise 4
Description:postgresql-jdbc-8.1.407 won't install on RHEL4
Details:
When attempt
The following bug has been logged online:
Bug reference: 2785
Logged by: Patrick Hayes
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Windows Professional
Description:Exception Issue
Details:
I am defining Exception blocks. When I put so
The following bug has been logged online:
Bug reference: 2781
Logged by: Greg Peters
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1/8.2beta3
Operating system: WInXP
Description:database dump/restore problems
Details:
Hello,
I recently performed a database
The following bug has been logged online:
Bug reference: 2782
Logged by: Alaa El Gohary
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.12
Operating system: FreeBSD 6.0
Description:Too Many open files in system
Details:
this message appears when trying to o
The following bug has been logged online:
Bug reference: 2783
Logged by: mike
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: windows 2000
Description:insufficient base table information for updating or
refreshing
Details:
if using 8.01.
The following bug has been logged online:
Bug reference: 2784
Logged by: Michael Simms
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Linux kernel 2.6.12
Description:Performance serious degrades over a period of a month
Details:
OK, we
Jeff Davis wrote:
> On Mon, 2006-11-27 at 12:44 -0800, Ron Mayer wrote:
>> Shouldn't the results of this query shown here been sorted by "b" rather
>> than by "a"?
>>
>> I would have thought since "order by b" is in the outer sql statement it
>> would have
>> been the one the final result gets or
Kris Jurka <[EMAIL PROTECTED]> writes:
> I'm getting some odd results when running two generate_series calls in a
> SELECT ...
> When the row counts differ you get the least common multiple number of
> rows.
Yup, this is the expected or at least historical behavior. It's not
entirely clear what
well yes, as the system is "live", users are browsing the website. but
all queries that try to access the table in question are stalled at the
moment. when querying server status i'm seeing lots of queries that are
waiting for access to the table.
would vacuum freeze be faster?
Vacuum freeze
Thomas H. wrote:
this somehow sounds buggy:
vacuum full absolutely *will* bloat your index, if run on a
heavily-modified table. I do not think it will bloat pg_xlog by itself
however; are you sure you don't have some other open transactions?
well yes, as the system is "live", users are brows
Thanks for the feedback. If you don't mind, what version of PostgreSQL
are you running?
I'm trying to bring PostgreSQL into this company - they are primarily a
Windows/SQL Server shop (although Java software development) I've
already gotten comments similar to "Why don't you just switch to SQL
S
Jeremy Haile wrote:
I've gotten pushback from my organization on removing antivirus from the
servers completely. Are there any antiviruses that are known to be
compatible with PostgreSQL/win32?
All my boxes (2 build farm members, 1 production server, and the laptop
on which the official rel
I've gotten pushback from my organization on removing antivirus from the
servers completely. Are there any antiviruses that are known to be
compatible with PostgreSQL/win32?
On Mon, 27 Nov 2006 10:28:23 -0500, "Jeremy Haile" <[EMAIL PROTECTED]>
said:
> Thanks Magnus.
>
> I will uninstall the
Thanks Magnus.
I will uninstall the AntiVirus and see if my problems persist. I have
disabled all other non-essential services, indexing, etc. so I don't
know of anything else that could be causing the problems. However, in
some of the posts I referred to, the poster indicated that they were n
Per the FAQ, we suggest that you *uninstall* your antivirus. Especially
if it has firewall-like functionality (like I beleive McAfee does). Just
disabling the scan does *not* remove the filter drivers and does not
make the antivirus not affect the database processes. So try this. If
the problem doe
I've been attempting to run PostgreSQL 8.1.5/win32 on a production
deployment, but have started having many problems. McAfee Antivirus is
installed and running, although I've excluded the entire drive where
PostgreSQL is installed and where the data is installed.
I've received several errors in t
I'm getting some odd results when running two generate_series calls in a
SELECT. When the two calls return the same number of rows you get that
many rows out:
# SELECT generate_series(1,3), generate_series(1,3);
generate_series | generate_series
-+-
29 matches
Mail list logo