Commercial PostgreSQL support

[Louie Kwan]

We are looking for some sort of commercial PostgreSQL support, but we have
limited budget.

Email based type support may be enough.

Any pointer will be appreciated.

Thanks.

Regards,
Louie Kwan

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ***@postgresql.org so that your
message can get through to the mailing list cleanly

[Devrim GUNDUZ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

Post by Louie Kwan
We are looking for some sort of commercial PostgreSQL support, but we have
limited budget.

AFAICS, you're located in Canada. Both hub.org and Lanux Limited are
located on Canada.

You can find their addresses from the following URL:

http://www.pgsql.com/partnerlinks/

Regards,
- --
Devrim GUNDUZ
***@gunduz.org ***@linux.org.tr
http://www.TDMSoft.com
http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAQ1wptl86P3SPfQ4RAjOaAKC7mwrIhgMD5dq/gy67qFIQbO1U3wCg6v2K
923N9RY6j+exI5gbH8e8Y1c=
=q3e/
-----END PGP SIGNATURE-----


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Marc Mitchell]

We are running a highly transaction-intensive application in the
following environment:

Postgres Version 7.3.5 built off the source tree, not RPMs
Operating System: Red Hat Enterprise Linux AS (v 2.1)
Kernel: 2.4.9-e.34smp
Hardware: Dell PE 2600-Dual 2.8 Ghz Xeon w/2GB RAM and Dual 36GB Mirrors
using PERC RAID

The same problem has occurred on at least three separate occasions on 3
different tables and manifests itself through the following error while
performing "COPY TABLE" commands:

ERROR: MemoryContextAlloc: invalid request size 4294967293 lost
synchronization with server, resetting connection

In each case, by examining the copy table output up to the point where
it errors out, a single row could be identified that contained corrupted
char/varchar values but could be queried using primary key or numeric
lookups. We've been able to work around the issue by deleting the row
and manually re-inserting it based on values determined from a previous
backup. Note that in each case, it has been determined that the corrupt
row existed without a problem earlier as it could be found in old
backups. Thus the rows seem to get into the table ok but got wacked at
some future point in time.

Any ideas on what's causing this?

Marc Mitchell - Senior Application Architect
Enterprise Information Solutions, Inc.
Downers Grove, IL 60515
***@eisolution.com



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ***@postgresql.org

[Tom Lane]

Post by Marc Mitchell
In each case, by examining the copy table output up to the point where
it errors out, a single row could be identified that contained corrupted
char/varchar values but could be queried using primary key or numeric
lookups. We've been able to work around the issue by deleting the row
and manually re-inserting it based on values determined from a previous
backup. Note that in each case, it has been determined that the corrupt
row existed without a problem earlier as it could be found in old
backups. Thus the rows seem to get into the table ok but got wacked at
some future point in time.
Any ideas on what's causing this?

Hardware problems possibly? You might try running memtest86 or some
such.

It would be good to take note of the exact bit pattern of the
corruption, if you can match up correct and corrupted versions of the
rows.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match