Hi to all,
We have a pretty big database that is going for an upgrade (PG7 -> PG8)
in the next few days, we have tested all the features of our application
but we cannot be sure that everything will work out perfectly (db is
managing several blob's only tables that have proven to be pretty har
> We have a pretty big database that is going for an upgrade (PG7 -> PG8)
> in the next few days, we have tested all the features of our application
> but we cannot be sure that everything will work out perfectly (db is
> managing several blob's only tables that have proven to be pretty hard
>
Hi,
I've already made almost same upgrade (7.4->8.1) under Debian linux.
On Debian the 8.1 database structure will be installed into
/var/lib/postgresql/ by default and on 7.4 it's /var/lib/postgres/. So
if you remove the packages and you (or your package manager) do not
remove the databases phys
I wrote to Peter Wilson some day ago:
I had problems, like that. I've omitted them using "plain" format (SQL
script file) of dump file. I restore data from "plain" format with psql
- using command "\i FILE". It work always. If You gzip this "plain" file
- You become simillar volume of file usi
Thank you for this infos, I wasn't sure about this, now, at least, I know
that this is not possible.
On the other hand, even the most experienced database programmer /
administrator when upgrading a production environment can't be 100% sure
about whether the application,will fail or not.
Of cours
I created a table in 8.1.5 on Linux with three columns;
date, bigint and integer.
Then I populated the table with more than 2 million rows.
I looked at the size of the file that contained the table and divided this
by the number of rows which gave an average of just over 60 bytes per row.
This
On Wed, 2006-11-29 at 13:57, Joe Bloggs wrote:
> I created a table in 8.1.5 on Linux with three columns;
>
> date, bigint and integer.
>
> Then I populated the table with more than 2 million rows.
>
> I looked at the size of the file that contained the table and divided
> this by the number of
Hello All
We are having an issue and it appears to be with file descriptors.
We are running PostgreSQL 7.4.13 on RHEL 3.0 box. This system is running
Redhat Cluster Suite with each system running multiple postmasters. The
error has occurred on both boxes and we can't find any consistencies on
w
Hello All
We are having an issue and it appears to be with file descriptors.
We are running PostgreSQL 7.4.13 on RHEL 3.0 box. This system is running
Redhat Cluster Suite with each system running multiple postmasters. The
error has occurred on both boxes and we can't find any consistencies
Scott Marlowe <[EMAIL PROTECTED]> writes:
> On Wed, 2006-11-29 at 13:57, Joe Bloggs wrote:
>> I created a table in 8.1.5 on Linux with three columns;
>> date, bigint and integer.
>>
>> I looked at the size of the file that contained the table and divided
>> this by the number of rows which gave
John Allgood <[EMAIL PROTECTED]> writes:
> 2006-11-29 14:57:51 [3823] LOG: out of file descriptors: Too many open
> files; release and retry
Consider reducing PG's max_files_per_process setting. Postgres itself
will usually not have a serious problem when you've run the kernel out
of file descr
Hey Tom
I assume that if it is the kernel running out of descriptors that I
would get the messages in dmesg. This message only appears in the log
file for that database.
Thanks
Tom Lane wrote:
> John Allgood <[EMAIL PROTECTED]> writes:
>
>> 2006-11-29 14:57:51 [3823] LOG: out of file des
John Allgood wrote:
> Hey Tom
>
> I assume that if it is the kernel running out of descriptors that I
> would get the messages in dmesg. This message only appears in the log
> file for that database.
Yeah, the point is that you have the max_files_per_process setting
higher than what the kerne
13 matches
Mail list logo
