harmless on signed-char machines but would lead to core dump in the
deadlock detection code if char is unsigned. Amazingly, this bug has
been here since 7.1 and yet wasn't reported till now. Thanks to Robert
Bruccoleri for providing the opportunity to track it down.
known problem with failure to respond to 'pg_ctl stop -m fast', and
probable problems if SIGINT or SIGTERM arrives while processing a
SIGUSR2 interrupt that arrived while waiting for a new client query.
in ruleutils output. The previous partial parenthesization was a hack
to get around grammar restrictions that have since been fixed; and as
Sam O'Connor pointed out, there were cases where it didn't work.
Fixed bug with '=' operator for gist__int_ops and
define '=' operator for gist__intbig_ops opclass.
Now '=' operator is consistent with standard 'array' type.
Thanks Achilleus Mantzios for bug report and suggestion.
Oleg Bartunov
is actively dangerous, per bug report from Ewald Geschwinde 14-May-02,
and several of the rest look suspicious to me. Since there is no longer
any significant value in retail pfree's in these functions, just get
rid of all of them for safety's sake.
--nonexistingoption).
per report from sugita@sra.co.jp on Thu, 09 May 2002 11:57:51 +0900
(JST) at pgsql-patches list.
Illegal long options to pg_dump makes core on some systems, since it
lacks the last null sentinel of struct option array.
Attached is a patch made by Mr. Ishida Akio <iakio@pjam.jpweb.net>.
Fix PQescapeBytea/PQunescapeBytea so that they handle bytes > 0x7f.
This is necessary for mulibyte character sequences.
See "[HACKERS] PQescapeBytea is not multibyte aware" thread posted around
2002/04/05 for more details.
wrapped-around databases. The unvacuumed databases might be fine, or
they might not, but things will definitely not be fine if we remove the
wrong CLOG segments. Per trouble report from Gary Wolfe, 1-Apr-2002.
> > to perform sql command:
> > update pg_amop set amopreqcheck = true where amopclaid =
> > (select oid from pg_opclass where opcname = 'gist_txtidx_ops');
>
> Oleg, sorry, I don't understand where this should appear. In the README
> file, and if so, where? Is this something only for people upgrading
> from 7.2?
Sorry Bruce, I was unclear. I have attached patch to Readme.tsearch
Also, It'd be worth to mention in Changes to point users of tsearch
about importang upgrade notices.
Oleg Bartunov
