Rural Hunter escribió:
2. Since db1 is a very large database(it is the main db the user is
using) I can not afford to take long time to vacuum full on that. So
I thought about to try on other small dbs first.
3. I stop the instance.
4. I use echo 'vacuum full;' | postgres --single -D
Wells Oliver escribió:
I have this error in a pg_upgrade:
psql:pg_upgrade_dump_db.sql:88725: ERROR: UNION could not convert type
text[] to integer[]
Have a look at the file and see what's in the mentioned line. My guess
is that this is a view definition, or similar, that no longer works.
Struckhoff, Kevin wrote:
I've installed postgres 9.2 on a server, call it db01. I now want to access
postgres from my app server, call it app01.
What do I install on the app01 server? I've installed postgres 9.2 on it and
set the postgresesql.conf file's listen_address to a value of '*' on
Struckhoff, Kevin wrote:
Sorry, rhel 5.8. so there is a separate client install package?
Yes; on RHEL the library package is called postgresql-libs or something
similar, while the client package containing the psql utility is just
postgresql. (The server lives in a package called
Struckhoff, Kevin wrote:
I'm trying to use the psql tool:
/home/postgres-psql test
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket /tmp/.s.PGSQL.5432?
the answer of course is No..
Wojciechowski, Robert (GE Transportation) wrote:
I’ve noticed a weird situation on one of our development servers running
PostgreSQL 9.1.3 where roles have been dropped even though objects depend on
that user. I didn’t think that was possible due to the dependency checks on
DROP USER/ROLE.
David Johnston wrote:
Wojciechowski, Robert (GE Transportation) wrote
[...] there is a database that shows this connect grant to a user that was
known as foo1_userA (oid 3562339547): 3562339547=c/postgres
The main user dependent situation is having said user OWNER on a database
object.
k...@rice.edu wrote:
Each SELECT opens your FOREIGN TABLE so you are opening it 10 times. This is
hardcoded by a #define in ./src/backend/storage/file/fd.c during the build so
you would need to recompile the software yourself to change it. Can you re-
write your query using a single SELECT or
Virupaksha Kanjilal escribió:
Does anyone know what the fields in the output of pg_controldata mean?
A lot of people. What do you want to know, precisely?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via
Craig James wrote:
Contributors in these newsgroups seem to think it's OK to quote five pages
of someone else's response, then add one or two sentences at the bottom ...
it's just laziness that forces readers to wade through the same stuff over
and over in each thread.
How did the Postgres
Kamil Jońca wrote:
PS. does news.postgresql.org work? I got 'unknown host'
Not anymore.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to
Armin Resch escribió:
Thx, Albe. I tested both proposals, and I gravitate now more towards the
E'' nomenclature since it avoids something like this:
$pg_bs_char = ( $dbh-{pg_server_version} = 90100 ) ? \\ : ;
Hoping for a long half life of the E'' nomenclature ...
E'' is very unlikely
Gabriel E. Sánchez Martínez escribió:
I will try to make these tables logged and see if they withstand the
test of time. Are crashes and unclean shutdowns logged anywhere? I
would like to see why I might be getting them. I have not had to
manually restart the database, if that were an
Excerpts from daveg's message of mié mar 02 18:30:34 -0300 2011:
After a restart and vacuum of all dbs with no other activity things were
quiet for a couple hours and then we started seeing these PD_ALL_VISIBLE
messages again.
Going back through the logs we have been getting these since at
Excerpts from Pablo Delgado Díaz-Pache's message of lun nov 15 04:52:53 -0300
2010:
But it strikes me that the code comment is wrong in one significant way:
if the postmaster were failing to heed SIGUSR1 at all, you could reach
the timeout here, because the fork-failed signal wouldn't get
Excerpts from Pablo Delgado Díaz-Pache's message of jue nov 18 08:57:16 -0300
2010:
Well, we had the problem again. This is what we did
1) A ps to check what processes were running. Many postmaster processes
in defunct state. A few postgres connections still working. A few psql (by
shell
Excerpts from Pablo Delgado Díaz-Pache's message of jue nov 18 08:57:16 -0300
2010:
2) We did a strace to the postmaster pid. However we had 2 postmasters not
dead
# ps -fea |grep -i postmaster
postgres 3889 1 0 Nov16 ?00:01:24 /usr/bin/postmaster -p 5432
-D
Excerpts from Pablo Delgado Díaz-Pache's message of mar nov 16 12:18:09 -0300
2010:
Not sure what you mean.
Once we start getting that error in the postgres log, there is no autovacuum
entry. Only that error message once every minute (and as i wrote in my last
email, the same message all
Excerpts from Tom Lane's message of lun oct 25 16:57:10 -0300 2010:
It looks to me like the problem is that get_database_list()
intentionally pushes its result into a long-lived context, and then the
result is never cleaned up. It doesn't help any that it does a lot of
leaky things like
Excerpts from Little, Douglas's message of jue oct 28 09:39:19 -0300 2010:
Hi,
We're having to vacuum full the system tables everyday due to the number of
temp table drop/creates.
Seems to me that you're solving the wrong problem. I think you should
be doing very frequent lazy vacuum (not
Excerpts from Tom Lane's message of lun nov 08 12:15:02 -0300 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
Patch for this is attached (applies cleanly to 9.0 and HEAD; 8.4 doesn't
need to be patched, but I'll run the test case now just to be sure.)
Possibly s/cxt/resultcxt
Excerpts from Greg Spiegelberg's message of mar ago 31 09:04:18 -0400 2010:
Probably questions best asked on hackers but I figure many are represented
here.
Will there ever be a release where a dump-restore is not necessary?
Perhaps, at least, minor releases (e.g. 9.0 to 9.1) will not require
Excerpts from Tom Lane's message of jue ago 26 14:59:43 -0400 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
Code is here:
else if (deptype == SHARED_DEPENDENCY_ACL)
appendStringInfo(descs, _(access to %s), objdesc);
in StoreObjectDescription
Excerpts from Tom Lane's message of mar ago 24 09:36:05 -0400 2010:
McGehee, Robert robert.mcge...@geodecapital.com writes:
Thanks Tom and Alvaro for clearing up my confusion.
\l showed that a485099 had both (C)reate and (T)emporary access.
Revoking those allowed me to drop the role. Thanks
Excerpts from Keith Pinnix's message of lun ago 23 19:47:53 -0400 2010:
All:
I have a postgresql instance and I have noticed that it is logging the user
passwords in clear text in the postgresql.log. Is this configurable so that
it
retains the user info and commands but does not log
Excerpts from McGehee, Robert's message of lun ago 23 13:29:47 -0400 2010:
PostgreSQL developers,
I am unable to drop a role with presumably no object dependencies or
connection access on my PostgreSQL 8.4.2 installation (64-bit OSX). Any
help would be greatly appreciated as I've spent way too
Excerpts from Gnanakumar's message of jue ago 12 00:56:34 -0400 2010:
in 8.2 naptime means time to sleep after we finish a job. So even
if the previous task takes an hour, it will still sleep a minute before
doing another round. (Note that this setting has a different meaning in
later
Excerpts from Gnanakumar's message of mié ago 11 01:07:08 -0400 2010:
Hi,
1. Does autovacuum daemon works with one table at a time or does it work
with multiple tables at the same time?
Only one.
Reason to ask this question is, let's say I've autovacuum_naptime set to 1
minute, and there
Excerpts from Kasia Tuszynska's message of mar ago 10 15:08:20 -0400 2010:
Hello Postgres Gurus,
Is it expected behavior for the has_table_privilege postgres function to not
handle the user PUBLIC? Or should I submit a bug?
The has_table_privilege function does not handle PUBLIC - the
Excerpts from Silvio Brandani's message of vie ago 06 07:56:53 -0400 2010:
it seems the execution plan is different for this query when run from
the application versus the psql . How can I check the execution plan of
a query run by a user??
I can set explain analyze for the query via psql
Excerpts from Lou Picciano's message of mar jul 27 11:23:50 -0400 2010:
Has anyone had any luck building pl/PHP on PostgreSQL v9 betas? Any
tips/gotchas?
It works for me -- just compiled with with 9.0 beta3 and regression
tests pass fine.
Is this language extension immensely
Excerpts from Benjamin Krajmalnik's message of lun jul 26 17:03:54 -0400 2010:
I just used the upper(text) function on a database which is utf8 encoded
and which has spanish text.
All of the regular characters were properly converted, except for
characters which had accents.
FWIW it works
Excerpts from Scott Marlowe's message of lun jul 26 23:12:08 -0400 2010:
On Mon, Jul 26, 2010 at 8:09 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I suspect that the problem is an incorrect client_encoding setting.
Yeah, OP had set lc_collate to C under the mistaken impression
Excerpts from Fábio Gibon - Comex System's message of mar jul 20 12:20:36 -0400
2010:
Hi everybody,
are there how define autovacuum to ON and define the period time (for
example, 00h - 06h) that it's can run?
You could have a script that toggles the value in postgresql.conf and do
a
Excerpts from Fábio Gibon - Comex System's message of mar jul 20 16:13:39 -0400
2010:
Perfect!!!
I'm starting with PostgreSQL (my knowledge is Oracle). Can you explain more
about autovacuum? for example...
1 - on windows SO, autovacuum start works (postgres.exe as
autovacuum_max_workers)
Excerpts from Uwe Bartels's message of jue jul 01 04:42:42 -0400 2010:
Hi Tom,
till now i found more blocking vacuum processes in other databases as well.
we migrated postgres from 8.3 to 8.4 in april.
Please examine pg_locks to see what's blocking autovacuum. The key is
WHERE granted=f.
Excerpts from Senthil Kumar G's message of mié jun 23 07:59:26 -0400 2010:
Hi
I executed follows. I am able to ping.
ping 127.0.0.1
So can you ping localhost?
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication,
Excerpts from Mike Broers's message of lun jun 21 14:18:01 -0400 2010:
I need to change service_name column to varchar(55), my plan was to backup
the table with pg_dump, then run the below alter statement:
alter table dim_product alter column service_name type varchar(55);
But i am
Excerpts from Matthew Excell's message of lun jun 07 15:33:27 -0400 2010:
I'm on PostgreSQL 8.3.11 on Debian.
I have a small piece of DDL (alter table title drop column is_target) that
hangs waiting forever. (I've waited hours - it still shows as waiting in
pg_top.) I have restarted the
Excerpts from Tena Sakai's message of lun may 31 21:36:41 -0400 2010:
But when I do this:
$ echo select marker, p, afreq from gallo.fbat_sdsdecode limit 10 | \
psql -P 'format=unaligned' -P 'fieldsep=\t' -t -f - musket
(here the only change from the previous is the specification of
Excerpts from Mitch Collinsworth's message of mar may 25 14:40:04 -0400 2010:
I'm wondering about the same question. I did the above and restarted,
and now my pg_stat_user_tables looks like this:
postgres=# \d pg_stat_user_tables
View pg_catalog.pg_stat_user_tables
Column | Type
Excerpts from Mitch Collinsworth's message of mar may 25 15:38:38 -0400 2010:
On Tue, 25 May 2010, Alvaro Herrera wrote:
I'd say you're running 8.1, not 8.2 as initially stated.
Well... yes. Sorry.I take it the answer is different then...
So... How can I tell if I'm autovacuuming
Excerpts from Mikko Partio's message of jue may 20 00:39:00 -0400 2010:
On Wed, May 19, 2010 at 3:21 PM, Ray Stell ste...@cns.vt.edu wrote:
http://archives.postgresql.org/pgsql-general/2007-06/msg01050.php
Browsing through that thread I can see that I have similar symptoms:
$
Excerpts from Narasimha Murthy-VRFX87's message of jue may 20 02:47:21 -0400
2010:
Hi Alvaro Herrera,
Since, my original plan was to run the auto-vacuum daily EXACTLY at 5 am, I
wanted to know which seconds of a minute. My query in other word was, if I
set autovacuum_naptime to 1 hr
Excerpts from Narasimha Murthy-VRFX87's message of mar may 18 07:04:34 -0400
2010:
I need some more clarification. autovacuum_naptime takes one minute by
default. In this case, which second of each minute the autovacuum
daemon runs (provided it is enabled)?
Why does it matter which second it
Excerpts from Narasimha Murthy-VRFX87's message of mar may 18 05:56:26 -0400
2010:
Hello,
Postgresql-8.2 manual has mentioned following points.
* The autovacuum daemon, when enabled, runs every autovacuum_naptime
seconds.
* autovacuum_naptime (integer): Specifies the delay between
and isn't ever able to get to the next ones.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http
Benjamin Krajmalnik wrote:
I did not find any errors pertaining to the autovacuum task.
Hmm. I think it would be good to find out what is the launcher doing,
if anything. If you strace it, do you see it sending signals to
postmaster?
--
Alvaro Herrerahttp
:56:45
and 13:57:38.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Julius Tuskenis wrote:
Hello, Alvaro Herrera
2010.04.26 18:38, Alvaro Herrera rašė:
Hmm, isn't the file read every time a backend starts on Windows?
This would explain the problem if the file was edited between 13:56:45
and 13:57:38.
Do you want to say that on windows postgresql acts
to a supported version as soon as
possible.
Yeah, at least update to 7.3.21 which is not supported but has quite a
few bugs fixed -- and I think this misleading error message was fixed in
one of them.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
size. The 32 bytes (previously 256)
are compared against a single column value.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org
/static/runtime-config-autovacuum.html
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
counters for live and dead tuples, IIRC (though
they may not be exposed in the pg_stat views)
3. Is there a way to see autovacuum daemon log entries?
Not in 8.2.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom
Though, is there value in silencing these warnings?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http
.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Alvaro Herrera escribió:
Also, keep in mind that max_workers is a new setting in 8.3. Since the
OP is running 8.2, he can only get one worker. Presumable he needs to
disable autovac for those two very active tables and setup a cron job to
process them in their own schedule.
Err, sorry, she
is only cleared by database-wide vacuums, which IIRC
autovac doesn't do unless it does a for-Xid-wraparound run, which is not
often. Probably a weekly database-wide vacuum (not full, i.e. vacuumdb
without -f) is enough.
--
Alvaro Herrerahttp://www.CommandPrompt.com
, start archiving to a different directory /WAL2, and when the
second base backup is done you can delete /WAL
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin
with pg_restore
--disable-triggers? Or can we convert plain text dump to be processed
by pg_restore? Perhaps a table by table trigger disabling script?
Have you tried using 8.2's pg_dump instead of the old one?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
do something funny to the system role
(typically called postgres)?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes
be
causing autovacuum to get killed and thus never completing, leading to
catastrophic bloat.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes
automatically on the replica (but you can
do it with some manual labour). If you want to replicate a new set of
tables, you can do that easily.
I imagine you've already been flamed to death about the one-schema-per-user
bit so I won't say anything about that.
--
Alvaro Herrera
can now test the program.
FWIW you should always prefer pg_config to help you get the right
compile flags; something like
gcc -I`pg_config --includedir` -L`pg_config --libdir` -lpq ...
That gets you the right include and lib dirs.
--
Alvaro Herrerahttp
the files
across? Maybe that process is getting stuck.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your
Anj Adu escribió:
If I were to use autovacuum on 8.1 , and If I specify the ignore'
tables in pg_autovacuum,
1. will the XID wraparound counter be reset after autovacuum finishes
No.
I think you really need to get off 8.1.
--
Alvaro Herrerahttp
Anj Adu escribió:
Does vacuumdb have knowledge of a VACUUM that was done on a table in
the prior run and skip it the next time (assuming the table does not
change) ?
No.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt
Tomeh, Husam escribió:
How about if using autovacuum daemon instead?
Autovacuum only processes tables that need vacuuming, per the configured
parameters, so yes, it skips tables that were recently processed
(where recently is defined by said parameters and operations).
--
Alvaro Herrera
Anj Adu escribió:
And autovacuum will reset the XID counter even if it skips tables
right? Just wanted to confirm before enabling autovacuum.
On 8.2 and up, yes.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom
to vacuum a list of tables that
you keep on a separate file or such. Something trivial like
while read table; do
vacuumdb -t $table
done /path/to/tablelist
with proper error handling and reporting etc.
--
Alvaro Herrerahttp://www.CommandPrompt.com
can get away with doing it one table at a time.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http
INTO pg_autovacuum VALUES ('whatever'::regclass, false, -1, -1, ...);
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription
.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
.
(When playing with this, however, note that the modified table may need
a toast table that may not be there).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin
last. It's an index scan and will definitely depend on
the index ordering.
Er, uh, of course. I wonder what I was thinking.
Your patched version of course.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent
Simon Riggs escribió:
On Wed, 2009-10-14 at 13:57 -0300, Alvaro Herrera wrote:
Anj Adu escribió:
I have several daily tables that get dropped every day..Is there a
wildcard that I can use to tell vacuumdb NOT to vacuum those
tables...
No. You need to do INSERT
Anj Adu escribió:
I have several daily tables that get dropped every day..Is there a
wildcard that I can use to tell vacuumdb NOT to vacuum those
tables...
No. You need to do INSERT INTO pg_autovacuum (or ALTER TABLE/SET in 8.4)
just after you've created the table.
--
Alvaro Herrera
vacuum is going to be affected too.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Jakub Gołębiewski escribió:
when i try to connetc from remote host I get information: psql: FATAL: PAM
authentication failed for user golebiej
Please try psql -W
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
to implement some pthreads stuff. Anyone know more?
Maybe a backtrace from GDB would tell us more.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-admin mailing list (pgsql-admin
\password in psql.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
8563 15633 0 Sep05 ?00:05:01 postgres: tracker
trackerData [local] VACUUM
Maybe your vacuum_cost_delay settings are too high? What do you have
them set to?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development
Lee, Mija escribió:
Hi -
Thanks for the response.
I'm on solaris so the ps ax doesn't work for me. I think the equivalent
is ps -ef which shows:
hmm, did you try /usr/ucb/ps?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command
.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
'DROP FUNCTION ' ||
textin(regprocedureout(p.oid::regprocedure)) || ' CASCADE;' FROM
pg_catalog.pg_proc p LEFT JOIN pg_catalog.pg_namespace n ON n.oid =
p.pronamespace WHERE n.nspname = current_schema();
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
BTW I notice that this does not work unless the client supplies the
password the first time around; psql does not retry. It only works if I
do psql -W.
Huh, that sounds like a bug someplace. Care to trace through
. This is an unfixable bug (short of rewriting
vacuum full from scratch) and has been reported in the wild several
times.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org
LATIN1.
What's your operating system?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Rob Newton escribió:
Alvaro Herrera wrote:
Devrim GÜNDÜZ escribió:
FWIW, PostgreSQL 8.3+ will start autovacuum (even if it is turned off)
if a database is approaching XID wraparound, and get rid of the
problem-- so you don't actually need to check it.
8.1 does it too. The main
Anj Adu escribió:
We currently use postgres 8.1.x and run the following query
periodically to check for XID wraparound proximity.
select datname, age(datfrozenxid) from pg_database
What is the equivalent check in 8.4
Same.
--
Alvaro Herrerahttp
, whereas in 8.2 and up it only vacuum tables that
have not been vacuumed recently.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your
Anj Adu escribió:
So..we dont have to check the last XID value per table ?
we have a very high volume data warehouse for which autovacuum is not
suitable due to performance reasons. Can we track the last XID on a
per-table basis ?
Sure, see pg_class.relfrozenxid
--
Alvaro Herrera
. However...the XID issue will force the need for an
autovacuum at some point..hence we do it as a one-off occasionally.
Hmm, in 8.2 you won't need to vacuum any tables that you drop or
truncate. Only permanent tables will need to be vacuumed once in a
while.
--
Alvaro Herrera
, which amounts more or less to the
same thing.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
You can authenticate users with PAM, which amounts more or less to the
same thing.
I believe though that using PAM against /etc/shadow would require the
postmaster to run as root. You need some external authentication
could use the pgsql-es-ayuda list, in any case. (Your
english does not seem all that bad anyway).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-admin mailing list (pgsql-admin
. Just in case.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
= ''::varchar (
1 ), alertoccurrence = 0::integer where ksalertssysid = 1737078
Please note the lasteventsource is null instead of lasteventsource =
null which is being generated when the value of x_eventsource is null.
Do you have transform_null_equals set?
--
Alvaro Herrera
Benjamin Krajmalnik wrote:
I tried it with both on and off, and it did not make a difference.
Please show a complete example.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql
I know in
version 8.1 what table is being vacuumed? I thought that even in 8.1 the
current_query column in pg_stat_activity would list the full sql being run as
opposed to 'VACUUM'.
It might need to run database wide vacuum in case of transaction
wraparound.
--
Alvaro Herrera
1 - 100 of 458 matches
Mail list logo