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
"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 ha
"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 exclu
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 SS
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 n
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 a
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 ).
You shouldn't do that. You should issue a cancel query to the b
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
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
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 k
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 woul
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:
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
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). Second,
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 f
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"
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
> mat
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 ). But these hanging
> connections (which blocks other statements infinitly) cant be killed.
W
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 drop
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 broa
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 oltp.requ
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 ). But these hanging
connections (which blocks other statements infinitly) cant be killed.
the only way is a pg_ctl -m imme
22 matches
Mail list logo
