Re: [BUGS] WAL Log numbering
Hi Bruce, Bruce Momjian wrote: > > Attached is a patch that changes "sequential" to "ever-increasing". That's a good idea. :) I was trying to think of the right wording, but I could only think of sentences that were too complex. That one's nice and simple. Regards and best wishes, Justin Clift > > > Justin Clift <[EMAIL PROTECTED]> writes: > > > I would have though that after 00FE would be > > > 0100, not 0001. > > > > This is the intended behavior, I believe. The low-order half is a > > 32-bit byte offset DIV XLogSegSize --- we could compress out the zero > > bits, but only at the cost of wiring an assumption about XLogSegSize > > into the filename format. The reason that 0/FF is missing from the > > sequence is stated in xlog.h: > > > > /* > > * We break each logical log file (xlogid value) into 16Mb segments. > > * One possible segment at the end of each log file is wasted, to ensure > > * that we don't have problems representing last-byte-position-plus-1. > > */ > > #define XLogSegSize ((uint32) (16*1024*1024)) > > #define XLogSegsPerFile (((uint32) 0x) / XLogSegSize) > > #define XLogFileSize (XLogSegsPerFile * XLogSegSize) > > > > > Just checked through the Interactive docs (not sure which version of 7.1 > > > they are) and says the numbers should be sequential. > > > > This would seem to be an oversimplification in the docs. > > > > regards, tom lane > > > > ---(end of broadcast)--- > > TIP 4: Don't 'kill -9' the postmaster > > > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > > Index: doc/src/sgml/wal.sgml > === > RCS file: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v > retrieving revision 1.9 > diff -c -r1.9 wal.sgml > *** doc/src/sgml/wal.sgml 2001/09/09 23:52:12 1.9 > --- doc/src/sgml/wal.sgml 2001/09/22 03:58:39 > *** > *** 137,143 > divided into 8 kB pages. The log record headers are described in > access/xlog.h; record content is dependent on > the type of event that is being logged. Segment files are given > !sequential numbers as names, starting at > . The numbers do not wrap, at > present, but it should take a very long time to exhaust the > available stock of numbers. > --- 137,143 > divided into 8 kB pages. The log record headers are described in > access/xlog.h; record content is dependent on > the type of event that is being logged. Segment files are given > !ever-increasing numbers as names, starting at > . The numbers do not wrap, at > present, but it should take a very long time to exhaust the > available stock of numbers. -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug #466: Unable to remove /root/tmp/initdb:xxxx.xxx
Hi Vladimir, [EMAIL PROTECTED] wrote: > > Vladimir Georgiev ([EMAIL PROTECTED]) reports a bug with a severity of 3 > The lower the number the more severe it is. > > Short Description > Unable to remove /root/tmp/initdb:.xxx This definitely sounds like a permissions problem. > Long Description > I've tried to follow the detailed description in INSTALL as for fresh install as >long as it was possible. > > 0)My Linux box: Mandrake 8.0 for i586. Any RPMS concerning any RDBMSs were >intentionally NOT installed during the Mandrake installation. PostgreSQL 7.1.3 source >unpacked into /usr/src/postgresql-7.1.3. The root user enters this directory. Then: It sounds like you're trying to say you are certain you don't have PostgreSQL installed for the rest of this procedure. One thing I'll point out is that in point 4) below, you show it won't add the user "postgres" because that user exists already. In my experience with Mandrake, if you have PostgreSQL (can't remember which RPM) already installed then the "postgres" user is automatically added (by whichever RPM it is), and also removed when the RPM version of PostgreSQL is removed. > 1) > root# ./configure --with-perl --enable-odbc --enable-syslog > Result: Worked fine > > 2) > root# gmake > Result: Worked fine > > 3) > root# gmake install > Result: Worked fine > > 4) > root# adduser -r -d /dyn/pgsql/home postgres > Result: Failed. User postgres already exists. If you haven't ever manually created the "postgres" user, then I strongly feel you have some kind of PostgreSQL RPM already present on the system. > 5) > root# chown -R postgres.postgres * > Result: Worked fine > > 6) > user root edits /etc/ld.so.conf adding the line: > /usr/local/pgsql > Save the file and close it. > > 7) > root# ldconfig > Result: Worked fine > > 8) > user root edits /etc/profile adding > PATH=$PATH:/usr/local/pgsql/bin > export $PATH > MANPATH=$MANPATH:/usr/local/pgsql/man > export $MANPATH > > 9) > logout/login > Result: System variables set fine > > 10) > root# mkdir /dyn/pgsql > root# mkdir /dyn/pgsql/data > root# mkdir /dyn/pgsql/home > root# chown -R postgres.postgres /dyn/pgsql > Result: Worked fine > > 11) > root# usermod -d /dyn/pgsql/home > Result: Worked fine > > 12) > root# su postgres > Result: Worked fine > > 13) > postgres$ /usr/local/pgsql/bin/initdb -D /dyn/pgsql/data > Result: most of the script runs ok. At some point it said: > ... unable to remove /root/tmp/initdb:xxx.xxx > where "xxx.xxx" are some numbers > Result:Failed > Observation: There are files created in /dyn/pgsql/data > > 14) > postgres$ /usr/local/pgsql/bin/pg_ctl -D /dyn/pgsql/data -l >/dyn/pgsql/home/server.log start > Result: Failed. It said: Unable to remove /root/tmp/. > The server did not started. > > == > How did I workarounded the problem > == > > 1) I've opened /dyn/pgsql/data/postgresql.conf > 2) I've Uncommented the line > #unix_socket_directory='' > so it became this: > unix_socket_directory='/tmp' > 3) I've saved the so edited postgresql.conf. > 4) > postgres$ /usr/local/pgsql/bin/pg_ctl -D /dyn/pgsql/data -l >/dyn/pgsql/home/server.log start > > RESULT: NOW IT WORKS FINE :-) >From reading this, it looks like something is causing PostgreSQL to run as the "postgres" user, but trying to install it's Unix Socket file in the /root/tmp directory (where it doesn't have permission to put it). That's why the error occurs. > = > WHY do I think it's a bug > = > Because I've followed the commands order recommended by the INSTALL file as long as >it was possible. > I've installed already about 4 prior versions of PostgreSQL, every time working this >same way and never had this problem, every time working on some Mandrake distribution. I strongly feel you already had/have some kind of PostgreSQL installation on your system, and I would point the finger at that as having caused or contributed to your problem. Can you run : rpm -q -a | grep post and look for occurances of postgresql-x (or any other indications of PostgreSQL), just to make sure? :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Clustering error with present CVS
Hi all, Just testing a few things out with present pre-7.2 CVS (as of a few hours ago). Came across the following error when clustering an index : ERROR: IndexBuildHeapScan: concurrent insert in progress The table in question (with about 10MB of data in it) is defined as : Table "uniques" Column| Type | Modifiers -+---+--- col_key | integer | not null col_int | integer | not null col_signed | integer | not null col_float | double precision | not null col_double | double precision | not null col_decim | numeric(18,2) | not null col_date| character(20) | not null col_code| character(10) | not null col_name| character(20) | not null col_address | character varying(80) | not null Then an index was created (no problems) : osdb=# create unique index uniques_key_bt on uniques using btree (col_key); CREATE osdb=# Then the cluster command was run (the problem here) : osdb=# cluster uniques_key_bt on uniques; ERROR: IndexBuildHeapScan: concurrent insert in progress osdb=# This is on Mandrake Linux 8.0, CVS of PostgreSQL as of a few hours ago, totally default postgresql.conf and pg_hba.conf. The database and tables have just been created and loaded, and there is no difference in behaviour whether vacuum or vacuum analyse have/haven't been run. Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
