Ashish Karalkar wrote:
Hi Shoaib
Following is the output for ps auxwww | grep ^postgres
IP address of my server is 172.18.5.155
postgres 12846 0.0 0.8 45328 4164 ?Ss
Jan12 0:00 postgres: qsweb qsweb06jan07
172.18.4.61(4272) idle
postgres 23335 0.0 0.9 45336 4800 ?Ss
Hi all
I have a PL/PGSQL conversion procedure that reads a "source table" and then
inserts tuples into several related tables. Recently I upgraded from 8.1 to
8.2.0, then to 8.2.1.
With 8.1 everything worked fine.
Now since I upgraded to 8.2 I have problems inserting data into tables that
hav
Thanks Shane for your replay,
It was by mistake , I have multiple clients,my server
IP is 155, having a web server, what we are doing is
using a java pool. and yes we are following the method
to close the connection immediatly after its work and
for next work pick up the new connection from pool, w
Hi,
I'm about to buy a few new servers, and I'm trying to determine if I
should buy XEON family 5000, 5100 or 5300 processors.
For about the same price, I can have:
2 Dual-Core Intel Xeon 5060, 3.2 GHz, 4MB
2 Dual-Core Intel Xeon 5130, 2.0 GHz, 4MB
2 Quad-Core Intel Xeon 5310, 1.6 GHz, 4MB
I ha
Ashish Karalkar wrote:
Thanks Shane for your replay,
It was by mistake , I have multiple clients,my server
IP is 155, having a web server, what we are doing is
using a java pool. and yes we are following the method
to close the connection immediatly after its work and
for next work pick up the ne
Hi all
I am coverting a database with several stored procedures from MS SQL Server
to PostgreSQL 8.2 and I have the following doubt:
With MS Sql a stored procedure containing the statement "SELECT * FROM
TABLE_A INNER JOIN TABLE_B" automatically creates and return a recordset
with all the fields o
Philippe Lang wrote:
If I'm not wrong, a single postgresql sql query cannot be spread over
two processors, but can it be spread over multiple cores? If that's
No - a *core* is another cpu, basically you will have 2 or 4 cpu's in
the one physical package.
HT creates 2 virtual cpu's sharing t
Stéphane Schildknecht wrote:
My goal is to migrate to 8.2.1. definitely. But as you said it, I do not
want to recreate unwanted index when migrating. I want to drop them BEFORE.
But, I can't just do a "drop index" command. It fails.
That's why I asked for an advice to drop them or not recreate
Stéphane Schildknecht wrote:
> Joshua D. Drake a écrit :
> > On Fri, 2007-01-12 at 17:50 +0100, Stéphane Schildknecht wrote:
> >
> >> Dear community members,
> >>
> >> I'm having a quite strange behaviour while trying to drop some index.
> >>
> >> We have some tables with two indexes on a primar
(I'm reposting this because the original message didn't make it through in the
last ~20 hours)
Hi,
I'm looking for a solution for indexing long TEXT columns. We're currently using a HASH index, which can handle most
situations, but every now and then we need support for even longer texts.
On
Tom Lane <[EMAIL PROTECTED]> wrote:
BTW, please don't do anything to try to correct the problem until we're
pretty sure we understand how this happened --- we might ask you for
more info. AFAICS this isn't having any bad effects except for bleats
in your log file, so you can wait.
Happened agai
=?UTF-8?B?U3TDqXBoYW5lIFNjaGlsZGtuZWNodA==?= <[EMAIL PROTECTED]> writes:
> My goal is to migrate to 8.2.1. definitely. But as you said it, I do not
> want to recreate unwanted index when migrating. I want to drop them BEFORE.
> But, I can't just do a "drop index" command. It fails.
Right, because
"Marcel Gsteiger" <[EMAIL PROTECTED]> writes:
> Now since I upgraded to 8.2 I have problems inserting data into tables that
> have unique indexes. Ugly enough, I get the message 'duplicate key violates
> unique constraint' when inserting the very first record into a table. This
> happens everyti
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The problem is that the constraint was defined with a dependence on the
> second index. I guess what you could do is drop the constraint, drop
> the second index, and then recreate the constraint. Try it within a
> transaction block, just in case it do
Aleksander Kmetec <[EMAIL PROTECTED]> writes:
> I'm looking for a solution for indexing long TEXT columns. We're currently
> using a HASH index, which can handle most
> situations, but every now and then we need support for even longer texts.
> One solution would be to create a functional index
> Aleksander Kmetec <[EMAIL PROTECTED]> writes:
> > I'm looking for a solution for indexing long TEXT columns. We're currently
> > using a HASH index, which can handle most
> > situations, but every now and then we need support for even longer texts.
>
> > One solution would be to create a funct
Jeff Amiel <[EMAIL PROTECTED]> writes:
> Jan 13 08:27:26 prod-app-1 postgres[92257]: [30259-1] jboss 92257 ERROR:
> could not access status of transaction 2107200825
> Jan 13 08:27:26 prod-app-1 postgres[92257]: [30259-2] jboss 92257 DETAIL:
> could not open file "pg_clog/07D9": No such file or
Tom Lane <[EMAIL PROTECTED]> wrote:
Really? Wow, *that's* an interesting thought. Is it likely that that
temp table could contain many-hour-old data?
Certainly...our connection pool used by jboss can have connections to postgres
persisting for multiple days. (We're still looking for a way to
On Thu, Jan 11, 2007 at 06:04:56PM -0500, Andrew Dunstan wrote:
> Please don't. At least not on the PostgreSQL web site nor in the docs.
> And no, I don't run my production servers on Windows either.
>
> For good or ill, we made a decision years ago to do a proper Windows
> port. I think that it
Hi,
On Fri, 2007-01-12 at 21:21 -0800, Joshua D. Drake wrote:
> > Is there a prebuilt package available for solaris 10 somewhere or
> > should I just follow the instructions here:
> >
> http://www.postgresql.org/docs/8.2/interactive/install-procedure.html
> > ?
>
> I have only seen up to 8.1.4. I
On Fri, Jan 12, 2007 at 07:33:05PM -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > Some feedback from initial testing is that 2 queues probably isn't
> > enough. If you have tables with 100s of blocks and tables with millions
> > of blocks, the tables in the mid-range still lose out. So I'
I wrote:
> ... but I suddenly fear that we've missed a fundamental point about
> pg_clog truncation. And WAL wraparound for that matter. To wit, a
> sufficiently long-lived temp table could contain old XIDs, and there's
> no way for anyone except the owning backend to clean them out, or even
> gu
22 matches
Mail list logo
