On Jun 18, 10:44 pm, [EMAIL PROTECTED] (Alvaro Herrera)
wrote:
Please check MultiXact id consumption. Do you mean that your server
has crashed?
How do I check MilitXact id consumption ? Is it Latest checkpoint's
NextXID: in the output of pg_controldata ?
transaction id consumption is ~
[EMAIL PROTECTED] wrote:
On Jun 18, 10:44 pm, [EMAIL PROTECTED] (Alvaro Herrera)
wrote:
Please check MultiXact id consumption. Do you mean that your server
has crashed?
How do I check MilitXact id consumption ? Is it Latest checkpoint's
NextXID: in the output of pg_controldata ?
And when was the message logged?
after the server was running with version 8.1.8 for about 2 month
(actually it was Jun 13 on one server and Apr 5 on the other) and no
similar log entries since then.
Gerhard
---(end of broadcast)---
TIP 2:
On Jun 13, 2:35 pm, [EMAIL PROTECTED] wrote:
On Jun 8, 3:23 pm, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
Gunther Mayer wrote:
Hi there,
I just found the following message in my logs:
Jun 8 10:38:38 caligula postgres[56868]: [1-1] : LOG: could not
truncate directory
[EMAIL PROTECTED] wrote:
On Jun 18, 11:08 am, [EMAIL PROTECTED] wrote:
On Jun 13, 2:35 pm, [EMAIL PROTECTED] wrote:
Can someone tell me if I should be concerned about this log entry ? My
database is quite large (~ 2G in PGDATA)
BTW, I do not use autovacuum, and run vacuumdb on a weekly
Aha, google thinks it's wise to make the last postings (probably if
more than n ?) show only the poster name and make the name clickable.
Not very userfriendly :-( but now i know it ;-)
Sorry if that wasn't clear. I'm getting the same log entry as the
original
poster, i.e.: LOG: could not
[EMAIL PROTECTED] wrote:
Aha, google thinks it's wise to make the last postings (probably if
more than n ?) show only the poster name and make the name clickable.
Not very userfriendly :-( but now i know it ;-)
I don't very much understand what you mean. I do see that you said I
noticed the
On Jun 8, 3:23 pm, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
Gunther Mayer wrote:
Hi there,
I just found the following message in my logs:
Jun 8 10:38:38 caligula postgres[56868]: [1-1] : LOG: could not
truncate directory pg_subtrans: apparent wraparound
Should I be worried or can
Hi there,
I just found the following message in my logs:
Jun 8 10:38:38 caligula postgres[56868]: [1-1] : LOG: could not
truncate directory pg_subtrans: apparent wraparound
Should I be worried or can I just ignore this one? My database is still
small (a pg_dumpall bzippe'd is still around
Gunther Mayer wrote:
Hi there,
I just found the following message in my logs:
Jun 8 10:38:38 caligula postgres[56868]: [1-1] : LOG: could not
truncate directory pg_subtrans: apparent wraparound
Should I be worried or can I just ignore this one? My database is still
small (a
I see other posts on this log message before, but not clear to me how/if
they apply to me. Opinions appreciated. I am on 8.1.3 on Linux. I have a
log entry like this:
2006-11-08 12:38:34 PST [3739]: [3-1] LOG: could not truncate directory
pg_multixact/members: apparent wraparound
Nothing
George Pavlov [EMAIL PROTECTED] writes:
I am on 8.1.3 on Linux. I have a
log entry like this:
2006-11-08 12:38:34 PST [3739]: [3-1] LOG: could not truncate directory
pg_multixact/members: apparent wraparound
During crash recovery? If so, probably nothing to worry about, per this
8.1.5 bug
During crash recovery?
no crashes, just normal DB operation...
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Fri, 2006-11-10 at 15:21 -0800, George Pavlov wrote:
I see other posts on this log message before, but not clear to me how/if
they apply to me. Opinions appreciated. I am on 8.1.3 on Linux. I have a
log entry like this:
2006-11-08 12:38:34 PST [3739]: [3-1] LOG: could not truncate
George Pavlov [EMAIL PROTECTED] writes:
During crash recovery?
no crashes, just normal DB operation...
Hmm ... what is in pg_multixact/members/ again?
Now there is only a file named 0010 the date on which changes about
every 4-5 minutes or so. I only noticed the log even with a day+
George Pavlov [EMAIL PROTECTED] writes:
George Pavlov [EMAIL PROTECTED] writes:
2006-11-08 12:38:34 PST [3739]: [3-1] LOG: could not truncate directory
pg_multixact/members: apparent wraparound
During crash recovery?
no crashes, just normal DB operation...
Hmm ... what is in
I wrote:
Reece Hart [EMAIL PROTECTED] writes:
After a system crash, postgresql 8.1.4 restarted but reported that I
have an apparent wraparound:
2006-07-13 14:03:40 PDT [10092] LOG: could not truncate directory
pg_multixact/offsets: apparent wraparound
2006-07-13 14:03:40 PDT [10092] LOG:
Greg, Florian, Joshua, Tom-
On Fri, 2006-07-14 at 17:02 -0700, Gregory S. Williamson wrote:
You need to edit the postgresql.conf file and increase the
max_fsm_pages and max_fsm_relations parameters and then restart
postgres
I did this and vacuumed. I didn't need to up shmmax. The problem's
Gregory S. Williamson wrote:
You need to edit the postgresql.conf file and increase the max_fsm_pages and
max_fsm_relations parameters and then restart postgres (I think you
have to actually stop and restart, as opposed to a reload, but I could be
wrong). You may end up needing to adjust the
Florian G. Pflug wrote:
Gregory S. Williamson wrote:
You need to edit the postgresql.conf file and increase the
max_fsm_pages and
max_fsm_relations parameters and then restart postgres (I think you
have to actually stop and restart, as opposed to a reload, but I
could be
wrong). You
After a system crash, postgresql 8.1.4 restarted but reported that I
have an apparent wraparound:
2006-07-13 14:03:40 PDT [10092] LOG: database system was interrupted at
2006-07-13 13:22:19 PDT
2006-07-13 14:03:40 PDT [10092] LOG: checkpoint record is at 1DD/26283E18
2006-07-13 14:03:40 PDT
Reece Hart [EMAIL PROTECTED] writes:
After a system crash, postgresql 8.1.4 restarted but reported that I
have an apparent wraparound:
...
2006-07-13 14:03:40 PDT [10092] LOG: next MultiXactId: 5475264; next
MultiXactOffset: 13765525
...
2006-07-13 14:03:40 PDT [10092] LOG: could not
Tom Lane wrote:
I'd ask you the same question I asked Thomas: do you continue to get those
log messages
during subsequent checkpoints?
No, I don't. The error did not reappear during ~2h of continuous
inserts since my report, didn't reappear after a forced checkpoint
(i.e., via psql), and did
-general
Cc:
Subject:Re: [GENERAL] apparent wraparound
Tom Lane wrote:
I'd ask you the same question I asked Thomas: do you continue to get those
log messages
during subsequent checkpoints?
No, I don't. The error did not reappear during ~2h of continuous
inserts since my report, didn't
24 matches
Mail list logo
