Thread: missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3

missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3

From
Tommi Mäkitalo
Date:
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)

Re: missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3

From
Bruce Momjian
Date:
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
 


Re: missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3

From
Tommi Mäkitalo
Date:
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



Re: missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3

From
Bruce Momjian
Date:
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
 


Re: missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3

From
Bruce Momjian
Date:
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
 


Re: missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3

From
Tommi Maekitalo
Date:
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


Re: missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3

From
Bruce Momjian
Date:
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
 


The database system is in recovery mode

From
"Iavor Raytchev"
Date:
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




Re: The database system is in recovery mode

From
Tom Lane
Date:
"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


Re: The database system is in recovery mode

From
"Iavor Raytchev"
Date:
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




Re: The database system is in recovery mode

From
Tom Lane
Date:
"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


Re: The database system is in recovery mode

From
"Iavor Raytchev"
Date:
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