Hi,
we recently discovered on our production database an a little bit bizarre
problem (after two years stable operations). Some tables are simply missing, or
sometimes the affected table(s) is/are there but not listed in pg_tables.
An example (I am looking for the table kog_blasthit_tables):
dev
The following bug has been logged online:
Bug reference: 1658
Logged by: Marcio Roberto Chiaveli
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.2
Operating system: windows
Description:Error download of odbc
Details:
When doing download of the driver ODBC, wh
The following bug has been logged online:
Bug reference: 1657
Logged by: Miguel Higuera
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows XP
Description:Database don't start
Details:
Hi
I have Install Postgresql 8 on Windows Xp Prof
The following bug has been logged online:
Bug reference: 1659
Logged by: İbrahim
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.2
Operating system: Windows XP sp1
Description:primary key accepts null value
Details:
i m using pg 8.0.2 in a project with Visu
The AIX 5.3 provide the structure sockaddr_storage :
struct sockaddr_storage {
ushort_t__ss_family;/* address family */
char__ss_pad1[_SS_PAD1SIZE]; /* pad up to alignment
field */
#if defined(__64BIT__) || (defined(_ALL_SOURCE) && defined(_LONG_LONG))
"Michael Beckstette" <[EMAIL PROTECTED]> writes:
> we recently discovered on our production database an a little bit bizarre
> problem (after two years stable operations). Some tables are simply missing,
> or
> sometimes the affected table(s) is/are there but not listed in pg_tables.
This sounds
Vincent Vanwynsberghe <[EMAIL PROTECTED]> writes:
> The AIX 5.3 provide the structure sockaddr_storage :
> ...
> In Postgress this structure sockaddr_storage is filled with the structure
> sockaddr_un but the size of sockaddr_storage
> is less then the size of sockaddr_un and cause a memory overfl
Hi Tom,
this is the output from 'SELECT datname, age(datfrozenxid) FROM pg_database;'
datname | age
-+-
xgc | -1950241750
dev_db | -1886587214
template1 | -1884294460
template0 | -1884294460
promo_db| -1884294460
snap_db_new | -188429446
Hi,
after reading the docs (I know it was a little bit late), I am now relatively
sure that I trapped into a transaction ID wraparound problem. For me its now a
little bit unclear, how to proceed in order to minimize the caused damage.
I checked all tables in the affected DB. Till now, the result
The following bug has been logged online:
Bug reference: 1660
Logged by: Bogdan Matei
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3.2
Operating system: Red Hat 9.0 (everything standard distribution)
Description:Growing used memory and critical performance l
"Michael Beckstette" <[EMAIL PROTECTED]> writes:
> The 6 completely lost tables are not so dramatical, because they contain only
> static data, that I can restore from the development system. But what happens
> with the 8 tables that are still accessable, but not listed in pg_tables,
> after
> a V
On 2005-05-11, Vincent Vanwynsberghe <[EMAIL PROTECTED]> wrote:
> The AIX 5.3 provide the structure sockaddr_storage :
>
> struct sockaddr_storage {
> ushort_t__ss_family;/* address family */
> char__ss_pad1[_SS_PAD1SIZE]; /* pad up to alignment
> field */
>
On Wed, May 11, 2005 at 04:56:28PM +0100, Bogdan Matei wrote:
> These are the efects. First of all we thought that is our application that
> consumes all the performance of Postgresql, with a predilection in the peak
> time of traffic, we improved it very well but even so there is no change.
> Wh
Hi,
On May 11, 2:39pm, Tom Lane wrote:
> What I would recommend as a first step is to stop the postmaster and
> then take a tarball backup of the entire $PGDATA tree. This will at
> least provide a chance to go back if subsequent tries mess things up
> completely.
Done. This was probably the
P.S.:A TODO for me: CRON Script for weekly VACUUM ;)
on heavy use databases, mine generally does a light vacuum every 4 hours, and a
once a day full on everything. also, a weekly full reindex on a really really
heavy use systems like this one message board server I ad-mangle
something like...
"Michael Beckstette" <[EMAIL PROTECTED]> writes:
> On May 11, 2:39pm, Tom Lane wrote:
>> If it does, go ahead and do a database-wide plain VACUUM, and you
>> should be OK.
> Done. As far as I can tell, everything is OK again.
Sweet ;-) In the words of my former business partner, a private pilot
Hi,
I'm using the pg_dump and pg_restore client applications to implement
our database backup-restore strategies. Wrt this, inorder to be able to
autoamate the backup process (run it as a cron job), I'm using the
.pgpass file for automating the password input. This is working for
pg_dump.
My res
17 matches
Mail list logo
