[BUGS] BUG #5211: invalid password
The following bug has been logged online: Bug reference: 5211 Logged by: lee brown Email address: lee_bro...@msn.com PostgreSQL version: 8.3 Operating system: vista Description:invalid password Details: i accidentally let computer generate password at"initialize database cluster"stage of installation.is there any way of undoing this error? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5212: incorrect resource manager data checksum in record at ...
The following bug has been logged online: Bug reference: 5212 Logged by: Amaya Gamarra Email address: amaya.gama...@gtd.es PostgreSQL version: 8.1.11 Operating system: RHEL %.2 Description:incorrect resource manager data checksum in record at ... Details: Hi, We've got a Slony-I cluster over 2 postgres 8.1.11 servers. Every 4 or 5 days the DB access gets locked and an the next error appears on the log: "redo starts at 2/XX" "incorrect resource manager data checksum in record at 2/" "redo done at 2/" Sometimes we can also find a recommandation for increasing our check_points. I suspect that the problem comes from our postgres configuration but I would like to confirm it. I join the pgsql.conf file. Could you please tell me what are the parameters to change/survey? Thanks for your help, Amaya # - # PostgreSQL configuration file # - # # This file consists of lines of the form: # # name = value # # (The "=" is optional.) Whitespace may be used. Comments are introduced with # "#" anywhere on a line. The complete list of parameter names and allowed # values can be found in the PostgreSQL documentation. # # The commented-out settings shown in this file represent the default values. # Re-commenting a setting is NOT sufficient to revert it to the default value; # you need to reload the server. # # This file is read on server startup and when the server receives a SIGHUP # signal. If you edit the file on a running system, you have to SIGHUP the # server for the changes to take effect, or use "pg_ctl reload". Some # parameters, which are marked below, require a server shutdown and restart to # take effect. # # Any parameter can also be given as a command-line option to the server, e.g., # "postgres -c log_connections=on". Some paramters can be changed at run time # with the "SET" SQL command. # # Memory units: kB = kilobytes MB = megabytes GB = gigabytes # Time units:ms = milliseconds s = seconds min = minutes h = hours d = days #--- --- # FILE LOCATIONS #--- --- # The default values of these variables are driven from the -D command-line # option or PGDATA environment variable, represented here as ConfigDir. #data_directory = 'ConfigDir' # use data in another directory # (change requires restart) #hba_file = 'ConfigDir/pg_hba.conf' # host-based authentication file # (change requires restart) #ident_file = 'ConfigDir/pg_ident.conf' # ident configuration file # (change requires restart) # If external_pid_file is not explicitly set, no extra PID file is written. #external_pid_file = '(none)' # write an extra PID file # (change requires restart) #--- --- # CONNECTIONS AND AUTHENTICATION #--- --- # - Connection Settings - listen_addresses = '*' # what IP address(es) to listen on; # comma-separated list of addresses; # defaults to 'localhost', '*' = all # (change requires restart) #port = 5432# (change requires restart) max_connections = 100 # (change requires restart) # Note: Increasing max_connections costs ~400 bytes of shared memory per # connection slot, plus lock space (see max_locks_per_transaction). You might # also need to raise shared_buffers to support more connections. #superuser_reserved_connections = 3 # (change requires restart) #unix_socket_directory = '' # (change requires restart) #unix_socket_group = '' # (change requires restart) #unix_socket_permissions = 0777 # begin with 0 to use octal notation # (change requires restart) #bonjour_name = '' # defaults to the computer name # (change requires restart) # - Security and Authentication - #authentication_timeout = 1min # 1s-600s #ssl = off # (change requires restart) #ssl_ciphers = 'ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH' # allowed SSL ciphers # (change requires restart) #password_encryption = on #db_user_namespace = off # Kerberos and GSSAPI #krb_server_keyfile = ''# (change requires restart) #krb_srvname = 'postgres' # (change requires restart, Kerberos only) #krb_server_hostname = '' # empty string matches any keytab
Re: [BUGS] BUG #5212: incorrect resource manager data checksum in record at ...
"Amaya Gamarra" wrote: > PostgreSQL version: 8.1.11 > We've got a Slony-I cluster over 2 postgres 8.1.11 servers. > I join the pgsql.conf file. > logging_collector = on That option (and others) are not present in 8.1. Either that's not your version or it's not your postgresql.conf file. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5212: incorrect resource manager data checksum in record at ...
"Amaya Gamarra" writes: > We've got a Slony-I cluster over 2 postgres 8.1.11 servers. Every 4 or 5 > days the DB access gets locked and an the next error appears on the log: > "redo starts at 2/XX" > "incorrect resource manager data checksum in record at 2/" > "redo done at 2/" The "incorrect data checksum" message does not necessarily show that anything is wrong --- it's entirely possible to get that message during normal reading of the WAL after a crash. What seems more useful to investigate is why you're crashing in the first place. But you did not provide any information that could reveal that. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] How duplicate data produce when a UNIQUE index exite ?
2009/11/24 RD黄永卫 : > Dear all, > > > > When "reindex" operation do,this error occurred: > Nov 22 10:22:27 SUC11 postgres[14145]: [2-1] ERROR: could not create unique > index > Nov 22 10:22:27 SUC11 postgres[14145]: [2-2] DETAIL: Table contains > duplicated values. > Nov 22 10:22:27 SUC11 postgres[14145]: [2-3] STATEMENT: REINDEX TABLE > "t_sfh_history" > > My question is: > > How the Duplicate datas produce when a UNIQUE index exite ? > Is this a bug of PostgreSQL ? Either bad hardware, or a pgsql bug can do this. > My postgreSQL version is : > PostgreSQL 8.1.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 > 20030502 (Red Hat Linux 3.2.3-56) You are aware that 8.1.x is up to 8.1.18, right, that's 14 or so updates you're missing. Could one of them have fixed a bug that causes this? Sure. Look through the changelogs to be sure, but why not just keep your pgsql version up to date? It's easier. Or are you running some redhat version that stays the same number while getting bugs back ported to it or something? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: 答复: [GENERAL] How duplicate data produce whe n a UNIQUE index exite ?
2009/11/24 RD黄永卫 : > > 发件人: Scott Marlowe [mailto:scott.marl...@gmail.com] > 发送时间: 2009年11月25日 14:44 > 收件人: RD黄永卫 > 抄送: pgsql-bugs@postgresql.org; pgsql-gene...@postgresql.org > 主题: Re: [GENERAL] How duplicate data produce when a UNIQUE index exite ? > > 2009/11/24 RD黄永卫 : >> Dear all, >> >> >> >> When "reindex" operation do,this error occurred: >> Nov 22 10:22:27 SUC11 postgres[14145]: [2-1] ERROR: could not create unique >> index >> Nov 22 10:22:27 SUC11 postgres[14145]: [2-2] DETAIL: Table contains >> duplicated values. >> Nov 22 10:22:27 SUC11 postgres[14145]: [2-3] STATEMENT: REINDEX TABLE >> "t_sfh_history" >> >> My question is: >> >> How the Duplicate datas produce when a UNIQUE index exite ? >> Is this a bug of PostgreSQL ? > > > >>> My postgreSQL version is : >>> PostgreSQL 8.1.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 >>> 20030502 (Red Hat Linux 3.2.3-56) > >> You are aware that 8.1.x is up to 8.1.18, right, that's 14 or so >> updates you're missing. Could one of them have fixed a bug that >> causes this? Sure. Look through the changelogs to be sure, but why >> not just keep your pgsql version up to date? It's easier. >> >> Or are you running some redhat version that stays the same number >> while getting bugs back ported to it or something? > > Either , or a pgsql bug can do this. > > What kind of " bad hardware " cause that ? May I reproduce that ? Any kind of bad hardware. Bad memory, cpu, motherboard, RAID controller, possibly the OS and on and on. memtest86+ is a good starting place to see if your hardware has cpu / ram /mobo issues. But first, update pgsql. Then hunt down your duplicates and fix the data in the database. I'm pretty sure there were a few problems like this in the early 8.1 series releases. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: [GENERAL] How duplicate data produce when a UNIQUE index exite ?
Scott Marlowe wrote: >> My postgreSQL version is : >> PostgreSQL 8.1.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 >> 20030502 (Red Hat Linux 3.2.3-56) >> > > You are aware that 8.1.x is up to 8.1.18, right, that's 14 or so > updates you're missing. Could one of them have fixed a bug that > causes this? Sure. Look through the changelogs to be sure, but why > not just keep your pgsql version up to date? It's easier. > > Or are you running some redhat version that stays the same number > while getting bugs back ported to it or something? > That GCC string suggests this is a RHEL3 system, which would have shipped with PostgreSQL 7.3. Not sure how they got 8.1 onto there, but a later 8.1 is certainly a useful first step to take here, before they get any more corruption from that ancient version when trying to fix things. Compiling PostgreSQL on RHEL3 from source has some fun challenges; http://markmail.org/message/2bclakrjfxtgwcge#query:+page:1+mid:jhj3yf7zxfmsi22i+state:results covers the main one I'm aware of. And unfortunately http://yum.pgsqlrpms.org/8.1/redhat/rhel3.0/ seems to be empty, so a source build may be the only good route to get a newer version onto there. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com
