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)
Attachments:
fe-exec.c.difftext/x-diff; charset=us-ascii; name=fe-exec.c.diffDownload
*** postgresql-7.3b3/src/interfaces/libpq/fe-exec.c 2002-09-04 22:31:47.000000000 +0200
--- postgresql-7.3b3tm1/src/interfaces/libpq/fe-exec.c 2002-11-02 22:28:34.000000000 +0100
***************
*** 118,126 ****
* anything >= 0x80 ---> \\ooo (where ooo is an octal expression)
*/
unsigned char *
! PQescapeBytea(unsigned char *bintext, size_t binlen, size_t *bytealen)
{
! unsigned char *vp;
unsigned char *rp;
unsigned char *result;
size_t i;
--- 118,126 ----
* anything >= 0x80 ---> \\ooo (where ooo is an octal expression)
*/
unsigned char *
! PQescapeBytea(const unsigned char *bintext, size_t binlen, size_t *bytealen)
{
! const unsigned char *vp;
unsigned char *rp;
unsigned char *result;
size_t i;
***************
*** 202,213 ****
* 6 \\
*/
unsigned char *
! PQunescapeBytea(unsigned char *strtext, size_t *retbuflen)
{
size_t buflen;
unsigned char *buffer,
- *sp,
*bp;
unsigned int state = 0;
if (strtext == NULL)
--- 202,213 ----
* 6 \\
*/
unsigned char *
! PQunescapeBytea(const unsigned char *strtext, size_t *retbuflen)
{
size_t buflen;
unsigned char *buffer,
*bp;
+ const unsigned char *sp;
unsigned int state = 0;
if (strtext == NULL)
libpq-fe.h.difftext/x-diff; charset=us-ascii; name=libpq-fe.h.diffDownload
*** postgresql-7.3b3/src/interfaces/libpq/libpq-fe.h 2002-09-04 22:31:47.000000000 +0200
--- postgresql-7.3b3tm1/src/interfaces/libpq/libpq-fe.h 2002-11-02 22:27:24.000000000 +0100
***************
*** 249,257 ****
/* Quoting strings before inclusion in queries. */
extern size_t PQescapeString(char *to, const char *from, size_t length);
! extern unsigned char *PQescapeBytea(unsigned char *bintext, size_t binlen,
size_t *bytealen);
! extern unsigned char *PQunescapeBytea(unsigned char *strtext,
size_t *retbuflen);
--- 249,257 ----
/* Quoting strings before inclusion in queries. */
extern size_t PQescapeString(char *to, const char *from, size_t length);
! extern unsigned char *PQescapeBytea(const unsigned char *bintext, size_t binlen,
size_t *bytealen);
! extern unsigned char *PQunescapeBytea(const unsigned char *strtext,
size_t *retbuflen);
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?
--
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, Pennsylvania 19073Hi,
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:
Show quoted text
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?
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, Pennsylvania 19073This 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?
--
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, Pennsylvania 19073Hi,
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?
--
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, Pennsylvania 19073
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
Forgot to mention -
Free BSD 4.6.2
PostgreSQL 7.2.2
----- Original Message -----
From: "Iavor Raytchev" <pobox@verysmall.org>
To: <pgsql-hackers@postgresql.org>
Sent: Sunday, November 10, 2002 1:52 PM
Subject: The database system is in recovery mode
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 modeWe 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
Show quoted text
it?
And - why did it happen at all?
Thanks,
Iavor
Import Notes
Resolved by subject fallback
"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
Show quoted text
"Iavor Raytchev" <pobox@verysmall.org> writes:
-bash-2.05b$ psql
psql: FATAL 1: The database system is in recovery modeWhat 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 alreadyThat 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