Обсуждение: missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3
Hi, I just discovered, that there is missing a const when passing a buffer to PQescapeBytea and PQunescapeBytea. I fixed it and tried to create a usable diff (I'm not so familar to diff). Tommi (resent with the right identity)
Is the missing const a major problem or can I save this patch for 7.4? --------------------------------------------------------------------------- Tommi M�kitalo wrote: > Hi, > > I just discovered, that there is missing a const when passing a buffer to > PQescapeBytea and PQunescapeBytea. I fixed it and tried to create a usable > diff (I'm not so familar to diff). > > Tommi > > > (resent with the right identity) [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Hi, not really. I can cast it away. Ugly, but it works. But I think it isn't that big, that it cant go into 7.3? It is really very local. It doesn't change anything. It should be very save. I just write another C++-interface and c++ is more strict in checking. By the way: I think there are other problems in PQescapeBytea. It do not work as expected. It seems, than nobody is using it anyway. I am checking it right now. I will tell you about my researches soon. Tommi Am Sonntag, 3. November 2002 02:29 schrieb Bruce Momjian: > Is the missing const a major problem or can I save this patch for 7.4? > > --------------------------------------------------------------------------- > > Tommi Mäkitalo wrote: > > Hi, > > > > I just discovered, that there is missing a const when passing a buffer to > > PQescapeBytea and PQunescapeBytea. I fixed it and tried to create a > > usable diff (I'm not so familar to diff). > > > > Tommi > > > > > > (resent with the right identity) > > [ Attachment, skipping... ] > > [ Attachment, skipping... ] > > > ---------------------------(end of broadcast)--------------------------- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/users-lounge/docs/faq.html
Tommi M�kitalo wrote: > Hi, > > not really. I can cast it away. Ugly, but it works. > > But I think it isn't that big, that it cant go into 7.3? It is really very > local. It doesn't change anything. It should be very save. We are sort of in a code freeze so though it is little, I will keep it for 7.4. Thanks. > > I just write another C++-interface and c++ is more strict in checking. > > By the way: I think there are other problems in PQescapeBytea. It do not work > as expected. It seems, than nobody is using it anyway. I am checking it right > now. I will tell you about my researches soon. OK, let me know. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
This has been saved for the 7.4 release: http:/momjian.postgresql.org/cgi-bin/pgpatches2 --------------------------------------------------------------------------- Tommi M�kitalo wrote: > Hi, > > I just discovered, that there is missing a const when passing a buffer to > PQescapeBytea and PQunescapeBytea. I fixed it and tried to create a usable > diff (I'm not so familar to diff). > > Tommi > > > (resent with the right identity) [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Hi, my "other problems in PQescapeBytea" disappeared. I can't find them any more. I did some testing and all is fine. Tommi Am Sonntag, 3. November 2002 15:50 schrieb Bruce Momjian: > Tommi Mäkitalo wrote: > > Hi, > > > > not really. I can cast it away. Ugly, but it works. > > > > But I think it isn't that big, that it cant go into 7.3? It is really > > very local. It doesn't change anything. It should be very save. > > We are sort of in a code freeze so though it is little, I will keep it > for 7.4. Thanks. > > > I just write another C++-interface and c++ is more strict in checking. > > > > By the way: I think there are other problems in PQescapeBytea. It do not > > work as expected. It seems, than nobody is using it anyway. I am checking > > it right now. I will tell you about my researches soon. > > OK, let me know. -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de
Patch applied, with doc updates by me. Thanks. --------------------------------------------------------------------------- Tommi M�kitalo wrote: > Hi, > > I just discovered, that there is missing a const when passing a buffer to > PQescapeBytea and PQunescapeBytea. I fixed it and tried to create a usable > diff (I'm not so familar to diff). > > Tommi > > > (resent with the right identity) [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Hello, We just crashed a live server with a load tester. PostgreSQL tells - -bash-2.05b$ psql psql: FATAL 1: The database system is in recovery mode We searched the documentation and the mailing lists, but we could not find any instructions what to do in this case. Shall we wait? Is a restart going to corrupt the data? Any specific instrictions? We have a back up done several hours ago - shall we simply use it? And - why did it happen at all? Thanks, Iavor
"Iavor Raytchev" <pobox@verysmall.org> writes:
> -bash-2.05b$ psql
> psql: FATAL 1: The database system is in recovery mode
What do you find in the postmaster's log?
regards, tom lane
Tom, Before the crash is this one - FATAL 1: Sorry, too many clients already Then there is a mixture of three messages - IpcSemaphoreLock: semop(id=-1) failed: Invalid argument DEBUG: pq_flush: send() failed: Bad file descriptor NOTICE: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. I have rolled back the current transaction and am going to terminate your database system connection and exit. Please reconnect to the database system and repeat your query. Shall we simply restart? Are there anywhere advices how to handle if too many clients try to connect? Iavor ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Iavor Raytchev" <pobox@verysmall.org> Cc: <pgsql-hackers@postgresql.org> Sent: Sunday, November 10, 2002 2:54 PM Subject: Re: [HACKERS] The database system is in recovery mode > "Iavor Raytchev" <pobox@verysmall.org> writes: > > -bash-2.05b$ psql > > psql: FATAL 1: The database system is in recovery mode > > What do you find in the postmaster's log? > > regards, tom lane
"Iavor Raytchev" <pobox@verysmall.org> writes:
> Before the crash is this one -
> FATAL 1: Sorry, too many clients already
That should be harmless --- I doubt it's relevant to the crash, unless
you have timestamps that prove it happened just before the crash.
> IpcSemaphoreLock: semop(id=-1) failed: Invalid argument
This is a new one on me. AFAICT it must mean that something clobbered
the PROC array in shared memory (the semId argument to IpcSemaphoreLock
is always taken from MyProc->sem.semId). Never heard of that happening
before.
> DEBUG: pq_flush: send() failed: Bad file descriptor
And that seems odd too; it suggests something overwrote MyProcPort->sock,
which is another un-heard-of failure mode.
> Shall we simply restart?
Yeah, I'd try that, but I'd also suggest looking for system-wide
problems. Normally the postmaster can recover by itself from any sort
of failure in child processes ... the fact that it didn't seem to do so
is another strikingly odd behavior. I'm starting to wonder about
possible hardware flakiness. Bad RAM maybe?
regards, tom lane
Tom Lane wrote: > "Iavor Raytchev" <pobox@verysmall.org> writes: > > Before the crash is this one - > > FATAL 1: Sorry, too many clients already > > That should be harmless --- I doubt it's relevant to the crash, unless > you have timestamps that prove it happened just before the crash. True, after the recovery we had this several times without a crash. > > IpcSemaphoreLock: semop(id=-1) failed: Invalid argument > > This is a new one on me. AFAICT it must mean that something clobbered > the PROC array in shared memory (the semId argument to IpcSemaphoreLock > is always taken from MyProc->sem.semId). Never heard of that happening > before. > > > DEBUG: pq_flush: send() failed: Bad file descriptor > > And that seems odd too; it suggests something overwrote MyProcPort->sock, > which is another un-heard-of failure mode. > > > Shall we simply restart? > > Yeah, I'd try that, but I'd also suggest looking for system-wide > problems. Normally the postmaster can recover by itself from any sort > of failure in child processes ... the fact that it didn't seem to do so > is another strikingly odd behavior. I'm starting to wonder about > possible hardware flakiness. Bad RAM maybe? There was something strange - one (old?) db connection that refused to be killed. After we managed to shut down the postmaster (not sure anymore, but I think we had to kill it) - this db connection could be killed as well. After new start of the postmaster all was OK. Seems there has been something stuck that has been old and now it was just triggered... We still investigate the surrounding sofware and hardware. Thanks for the help. Iavor