I am currently running Windows XP Pro and need to re-compile PostgreSQL as
we need to increase the length of the NAMEDATALENGTH parameter to 128.
Before attempting to change this value I thought I would see if I could
successfully compile PostgreSQl under Windows.
I downloaded and installed
I'm running 8.2.3 on ubuntu 6.06 (2.6.15-26-server SMP i686)
sometimes i have SELECTs that never ends. Normally I drop connections by
killing the connection process (kill PID). But these hanging
connections (which blocks other statements infinitly) cant be killed.
the only way is a pg_ctl -m
Hi guys,
I am having problems with freeing disk space after a massive delete
operation on a table that had approximately 80 million record. I ran the
following command, by setting the vacuum memory to approximately a GigaByte:
SET vacuum_mem TO 1024000
VACUUM FULL ANALYSE VERBOSE
Hi All,
Can any one tell me what I need to do to get this back on if I do a select
on pg_user for a particular user and then do a select on users for the same
user the expiry and valuntil columns are different? How do I get these to
match?
Cheers,
Sandy
---(end of
Hi Tom
I installed CentOS 4.4 final late last year. The kernel version was the latest
about a year back. I have been running yum updates and applying patches
regularly. Can you give me any ideas on how to troubleshoot (and establish that
this issue is due to a kernel bug) the kernel packet
Thomas Markus wrote:
I'm running 8.2.3 on ubuntu 6.06 (2.6.15-26-server SMP i686)
sometimes i have SELECTs that never ends. Normally I drop connections by
killing the connection process (kill PID). But these hanging
connections (which blocks other statements infinitly) cant be killed.
On Wed, May 02, 2007 at 11:55:51AM +0100, Sandy Spence wrote:
Can any one tell me what I need to do to get this back on if I do a select
on pg_user for a particular user and then do a select on users for the same
user the expiry and valuntil columns are different? How do I get these to
match?
Hi,
What would cause or what should I do with a table that hangs during its
reindexing? I can see in the messages the last table to reindex, so
sequentially the next table must be the problem.
I have statement_timeout set for 6 hours, then I get canceling statement
due to statement timeout
I have looked in the archives for an answer to this and have not found
one as of yet, so I guess I'll pose the question here.
I'm working to set up a high-availability PostgreSQL server using WAL
shipping. Everything works very well with the set of scripts I have
developed and I'm down to my
I've noticed in my own experiments and experiences with VACUUM FULL that
it tries to reindex all the indexes to compress them. While a good idea,
this unfortunately takes a *long* time.
You should check two things. First, the server CPU usage should be high
(~100% if on a single core).
On Wed, 2007-05-02 at 09:50, dx k9 wrote:
Hi,
What would cause or what should I do with a table that hangs during its
reindexing? I can see in the messages the last table to reindex, so
sequentially the next table must be the problem.
I have statement_timeout set for 6 hours, then I get
On Wed, 2007-05-02 at 05:05, Gabriele Bartolini wrote:
Hi guys,
I am having problems with freeing disk space after a massive delete
operation on a table that had approximately 80 million record. I
ran the following command, by setting the vacuum memory to
approximately a GigaByte:
Thanks for the response Scott.
It turns out it was a temporary database and temporary table, that just
wasn't there maybe it thought it was there from some type of snapshot then
the next minute it was gone.
Too bad we can't come up with a -e parameter for exclude say,
Something like this
Peter Koczan escribió:
I've noticed in my own experiments and experiences with VACUUM FULL that
it tries to reindex all the indexes to compress them. While a good idea,
this unfortunately takes a *long* time.
Huh, this is not an accurate description of what happens. VACUUM FULL
tries to
On Wed, 2007-05-02 at 10:49, dx k9 wrote:
Thanks for the response Scott.
It turns out it was a temporary database and temporary table, that just
wasn't there maybe it thought it was there from some type of snapshot then
the next minute it was gone.
Too bad we can't come up with a -e
Kevin Kempter sayeth...
Hi List;
Anyone have any thoughts per which logging method (SYSLOG vs
STDERR) is the
better approach ?
From looking at 8.2.1 source the internal postgres stderr redirect
method only does line buffering which explains why we see a performance
gain when we turn
On Wed, 2007-05-02 at 03:33, Thomas Markus wrote:
I'm running 8.2.3 on ubuntu 6.06 (2.6.15-26-server SMP i686)
sometimes i have SELECTs that never ends. Normally I drop connections by
killing the connection process (kill PID).
You shouldn't do that. You should issue a cancel query to the
Hi,
I am operating in an environment where we have regular users who will
authenticate via PAM and software users for automated processes that
would be more appropriate to authenticate via a password (encrypted or
not - irrelevant to this question). I have taken a look through the
documentation
Rob Cherry [EMAIL PROTECTED] writes:
Does anyone know if it is possible to overload auth types like this such
that if pam fails password would be tried?
No, it's not, as per the Fine Manual:
: The first record with a matching connection type, client address,
: requested database, and user name
Tom Lane wrote:
Rob Cherry [EMAIL PROTECTED] writes:
Does anyone know if it is possible to overload auth types like this such
that if pam fails password would be tried?
No, it's not, as per the Fine Manual:
Provided that you don't care about the security and performance
implications of SSL
dx k9 [EMAIL PROTECTED] writes:
[ stuck reindex ]
It turns out it was a temporary database and temporary table, that just
wasn't there maybe it thought it was there from some type of snapshot then
the next minute it was gone.
Hmm, there is not any filter in ReindexDatabase() to exclude temp
Sandy Spence [EMAIL PROTECTED] writes:
Can any one tell me what I need to do to get this back on if I do a select
on pg_user for a particular user and then do a select on users for the same
user the expiry and valuntil columns are different? How do I get these to
match?
It's pretty hard to
thanks for your awnsers
i cant repeat the problem after increasing autovacuum_naptime to 5min. a
vacuumdb -f -a runs over night (and finished :) ) and now that blocking
statement finished after some seconds. it seems autovacuum = on is not
enough.
Thomas Markus schrieb:
I'm running 8.2.3
23 matches
Mail list logo
