better make sure the sort order is totally specified; else we get burnt
by platform-specific behavior of qsort() with equal keys. Per buildfarm
results.
is null-terminated. I think this is not a real bug because the parser
would always have truncated the identifier to NAMEDATALEN-1 already,
but let's be safe. Per report from Klocwork.
> throughout to the spellings suggested by your book.
Great.
A follow-up patch for current CVS HEAD is attached, and available at
http://troels.arvin.dk/db/pgsql/conformance/pgsql-sql-conformance-
followup.patch
The patch
- includes a core feature ID that had been left
out by mistake (C011)
- updates the sql_feature_packages.txt table to
reflect changes in SQL:2003 which were not
covered properly in my last patch
Troels Arvin
> > Windows service, it says you can use the -I and -R options.
> >
> > When I do that and I specify a password with '-P'
> (uppercase) then in
> > the registry it's saved as '-p' (lowercase) in the
> service-commandline
> > (ImagePath).
This was fixed in v1.21 of pg_autovacuum.c, That rev is tagged for
beta3, so you should not be seeing this issue unless you actually have
an older version for some reason.
http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_autovacuum/p
g_autovacuum.c.diff?r1=1.20;r2=1.21;f=h
> > Also it removes the quotes I added and I'm not so sure it
> would work
> > the way it's supposed to, without it.
It's not so much that it strips them (that happens automagically), more
that it doesn't re-add them when it writes the command line in the
registry. The attached patch fixes that by simply quoting all options
that may need it.
> > If you add DependOnService (a REG_MULTI_SZ an
> array-like-thingie) and
> > have the name (in this case: pgsql-8.0-beta2-dev3) of a service it
> > depends on, it will not fail to start (it will not even try, as
> > PostgreSQL is not running), when PostgreSQL already failed.
> >
> > Maybe it's an idea to specify it on the commandline (what
> service to
> > depend on).
A -E <service> option is added in the attached patch.
Dave Page
> seconds to 10 seconds. The original number was plucked from thin air
> some months ago, and I'd like to review that now based upon further
> thought, observation and experience.
>
> This change has little or no effect on performance, since the interval
> is there mainly to avoid repeated respawn attempts if archiver fails at
> startup. Archiver start-up time is very quick, so there is little danger
> of exceeding 10 seconds.
>
> On a busy system, if the archiver does die, then many files can build up
> in the 60 seconds before respawning. That xlog file backlog could take
> some time to clear. This then leaves a larger than normal window of data
> loss for a possibly long period.
>
> It's a minor change only, with no other effect on function.
Simon Riggs
the "ps" argument list on Unix - meaning that there is no way to
identify for example the stats processors or the bgwriter.
This patch adds this functionality, in a bit of a crufty way. It creates
a kernel Event object with the name of what would be in the title. This
can be viewed using for example Process Explorer.
It's been very handy for me during both debugging and using. I haven't
figured a better way, but perhaps someone has one that's less crufty? If
not, here is at least a working patch :-)
Magnus Hagander
reasons I outlined in pghackers a few days ago.
Also, undo someone's overly optimistic decision to reduce tuple state
checks from if (...) elog() to Asserts. If I trusted this code more,
I might think it was a good idea to disable these checks in production
installations. But I don't.
Peter Eisentraut
Bruce Momjian
Tom Lane
Michael Meskes
Neil Conway
PostgreSQL Daemon