You can use the psql command line to run:
"select pg_start_backup();"
...then when you're done,
"select pg_stop_backup();"
if you want an example from the unix command line:
psql -c "select pg_start_backup();" database_name
then
psql -c "select pg_stop_backup();" database_name
/kurt
On J
st likely going to
promote one of my subscribers to be master, then nuke this database,
but I have no problems keeping it
around if you think I may have found some obscure bug that could help
someone debug. Again, this
DB gets vacuumed every day, and in the beginning, I think I remember
Drat! I'm wrong again. I thought for sure there wouldn't be a
wraparound problem.
So does this affect the entire database server, or just this table?
Is best way to
proceed to immediately ditch this db and promote one of my slaves to
a master? I'm just
concerned about the data integrity.
looking for, Tom? The only thing that
stands out to me is
the XMAX_INVALID mask. Thoughts?
Thanks,
/kurt
On Jun 20, 2007, at 11:22 AM, Tom Lane wrote:
Kurt Overberg <[EMAIL PROTECTED]> writes:
Okay, so the sl_log_1 TABLE looks okay. Its the indexes that seem to
be messed up, sp
for your thoughts on
this matter so far. It helps to not feel "so alone" when dealing
with difficult issues (for me anyway) on a system I don't know so
much about.
Thanks guys,
/kurt
On Jun 19, 2007, at 10:51 PM, Tom Lane wrote:
Kurt Overberg <[EMAIL PROTECTED]> writes:
O
On Jun 19, 2007, at 7:26 PM, Tom Lane wrote:
Kurt Overberg <[EMAIL PROTECTED]> writes:
That's the thing thats kinda blowing my mind here, when I look at
that table:
db1=# select count(*) from _my_cluster.sl_log_1 ;
count
---
6788
(1 row)
Well, that's real inte
ess it up further. Maybe when I take my production
systems down for
maintenance, can I wait until sl_log_1 clears out, so then I can just
drop that
table altogether (and re-create it of course)?
Thanks!
/kurt
On Jun 19, 2007, at 5:33 PM, Tom Lane wrote:
Kurt Overberg <[EMAIL
Chris,
I took your advice, and I had found that sl_log_1 seems to be causing
some of the problem. Here's the result of a VACUUM VERBOSE
mydb # vacuum verbose _my_cluster.sl_log_1 ;
INFO: vacuuming "_my_cluster.sl_log_1"
INFO: index "sl_log_1_idx1" now contains 309404 row versions in
1421
too? I figured something would else
would jump out bigger than this. FWIW, the same table on db2 and db3
is very small, like zero. I guess this is looking like it is
overhead from slony? Should I take this problem over to the slony
group?
Thanks again, gang-
/kurt
On Jun 19, 2007,
A useful utility that I've found is PgFouine. It has an option to
analyze VACUUM VERBOSE logs. It has been instrumental in helping me
figure out whats been going on with my VACUUM that is taking 4+
hours, specifically tracking the tables that are taking the longest.
I highly recommend ch
Gang,
Hoping you all can help me with a rather bizarre issue that I've run
across. I don't really need a solution, I think I have one, but I'd
really like to run it by everyone in case I'm headed in the wrong
direction.
I'm running a small Slony (v1.1.5)/postgresql 8.0.4 cluster (on
Re
Thank you everyone for the replies. I'll try to answer everyone's
questions in one post.
* Regarding production/mac memory and cache usage. This query HAS
been running on 8.0 on my Mac, I just got that particular query
explain from our production system because I had to nuke my local 8.0
Gang,
I'm running a mid-size production 8.0 environment. I'd really like
to upgrade to 8.2, so I've been doing some testing to make sure my
app works well with 8.2, and I ran across this weirdness. I set up
and configured 8.2 in the standard way, MacOSX Tiger, current
patches, download
13 matches
Mail list logo
