Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Böjthe Zoltán wrote:
> Bruce Momjian ?rta
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This message seems to be breaking the message guidelines.
Wups, that seems to have slipped by me. (There were a *lot* of
elogs :-() Fixed, thanks for the pointer.
regards, tom lane
---(end of broadcast
download from the link below:
http://www.pgsqldb.org/pgsql-po-zh_CN.tar.gz
sorry for the inconvenience, for I'm afraid of filled
out by anti-spam system.
Thanks
Laser
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send
seemed like a typo in one of the appendix tables
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: datetime.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/datetime.sgml,v
retrieving
This message seems to be breaking the message guidelines.
--
Alvaro Herrera ()
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?" (Mafalda)
Index: opclasscmds.c
==
Hello.
When I sent in the sslmode patch I forgot to update the comments/examples
in pg_hba.conf. This patch remedies that, adds a brief explanation of the
connection types, and adds a missing period in the docs.
JonIndex: doc/src/sgml/client-auth.sgml
=
Patch applied. Thanks.
---
Robert Treat wrote:
> seemed like a typo in one of the appendix tables
>
> Robert Treat
> --
> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
[ Attachment, skipping... ]
>
> -
I had to modify your patch sligthly to fit more recent code
changes --- updated version attached and applied.
---
Böjthe Zoltán wrote:
> Bruce Momjian ?rta:
>
> >Patch applied. Thanks.
> >
> >--
Patch applied. Thanks.
---
Christopher Kings-Lynne wrote:
> Mention that pg_type_is_visible is used for domains as well.
>
> Chris
>
Content-Description:
[ Attachment, skipping... ]
>
> ---(
Patch applied. I will now go through and lowercase all the GUC
variable names, as agreed upon.
---
Neil Conway wrote:
> This patch makes a few minor improvements to the docs: make the
> conventions more consistent, and imp
Weiping He writes:
> download from the link below:
>
> http://www.pgsqldb.org/pgsql-po-zh_CN.tar.gz
Please fix the following errors:
backend-zh_CN.po:2490: format specifications for argument 1 are not the same
pg_dump-zh_CN.po:645: number of format specifications in `msgid' and `msgstr' does not
Christoph Dalitz writes:
> a) Write documentation how the win32 console needs to be set up so that
> psql can handle 8-bit characters.
> Where should it be added? The Section "Installation on Windows" in the
> Administrator's Guide seems natural to me.
Sure.
> b) Add code to psql t
Christoph Dalitz wrote:
On Thu, 11 Sep 2003 20:51:24 +0200
Manfred Spraul <[EMAIL PROTECTED]> wrote:
- OemToChar() and CharToOem() convert all console input/output. In the
long run this might be the better solution, if it works entirely without
user intervention. I'm not sure if it's possible
Patch applied. Thanks. Your documentation changes can be viewed in
5 minutes using links at the bottom of the developer's page.
---
Neil Conway wrote:
> This patch fixes a few missed GUC variables that were still upper ca
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Found some bugs with this patch - that makes it about 1 per line
> patched... :-(
> i) onerel->rd_nblocks should be elog'ed as an unsigned int.
> ii) acquire_sample_rows has 2 return points - I had ignored the case
> where the
> onerel has < sampl
Patch applied. Thanks.
---
Joe Conway wrote:
> Joe Conway wrote:
> > Tom Lane wrote:
> >> Did we discuss this already? I'd forgotten.
> >>
> > I can't find it in the archives for some reason, but here was the exchange:
>
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, turns out the '\h alter' code does a simple printf(), not a
> > PageOutput() and fprintf() to that pipe. Various \h outputs are long,
> > including CREATE TABLE, GRANT, and ALTER TABLE. ALTER itself is really
> > larger because it prints
Patch applied. Thanks.
---
Neil Conway wrote:
> This patch makes a number of improvements to the runtime config
> documentation.
>
> -Neil
>
[ Attachment, skipping... ]
>
> ---(end of broadcast
On Thu, 2003-09-11 at 17:41, Bruce Momjian wrote:
> Patch applied. Thanks. Your documentation changes can be viewed in
> 5 minutes using links at the bottom of the developer's page.
Right (... although I always build a copy of the docs locally while I'm
making changes, to double-check that they
Prompted by confusion over Itanium/Opterion, I have written a patch to
improve the way we define spinlocks for platforms and cpu's. It
basically decouples the OS from the CPU spinlock code. In almost all
cases, the spinlock code cares only about the compiler and CPU, not the
OS.
The patch:
Bruce Momjian writes:
> OK, turns out the '\h alter' code does a simple printf(), not a
> PageOutput() and fprintf() to that pipe. Various \h outputs are long,
> including CREATE TABLE, GRANT, and ALTER TABLE. ALTER itself is really
> larger because it prints all the ALTER commands help.
They a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Prompted by confusion over Itanium/Opterion, I have written a patch to
> improve the way we define spinlocks for platforms and cpu's.
The main.c part of the patch strikes me as irrelevant to the claimed
purpose and unlikely to accomplish anything except
On Thu, 2003-09-11 at 11:58, Bruce Momjian wrote:
> Uh, how do you force the stats collector to 'on' before the test is
> run?
The stats collector is on by default (of course, that doesn't apply to
"make installcheck"...)
But this reminds me: I think it would be cool to extend the language we
us
Christoph Dalitz wrote:
> > Please send in a patch. Else, someone else is going to try to fix it with
> > less guarantees that it will work afterwards.
> >
> Ok. I can do the following:
>
> a) Write documentation how the win32 console needs to be set up so that
> psql can handle 8-bit chara
Uh, how do you force the stats collector to 'on' before the test is
run?
---
Manfred Koizar wrote:
> With pg_autovacuum becoming increasingly popular it's important to
> have a working stats collector. This test is able to
New patch attached.
---
Bruce Momjian wrote:
> Prompted by confusion over Itanium/Opterion, I have written a patch to
> improve the way we define spinlocks for platforms and cpu's. It
> basically decouples the OS from the C
Peter Eisentraut wrote:
If you can detect that they are different, why can't you adjust the code
page in that case only?
What should we do if we detect that they differ:
- set the console code page to the ansi code page. This has two
drawbacks: It doesn't work with Indic, because Indic doesn't
Neil Conway wrote:
> On Thu, 2003-09-11 at 17:41, Bruce Momjian wrote:
> > Patch applied. Thanks. Your documentation changes can be viewed in
> > 5 minutes using links at the bottom of the developer's page.
>
> Right (... although I always build a copy of the docs locally while I'm
> making chan
On Thu, 11 Sep 2003 23:17:13 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>> The stats collector is on by default (of course, that doesn't apply to
>> "make installcheck"...)
By doing "appropriate" changes to your installation I guess you can
break almost every test ;-)
>Oh I see now, ni
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Prompted by confusion over Itanium/Opterion, I have written a patch to
> > improve the way we define spinlocks for platforms and cpu's.
>
> The main.c part of the patch strikes me as irrelevant to the claimed
> purpose and unlikely to
On Thu, 11 Sep 2003, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The problem with waiting for 7.5 is that we will have no error reporting
> > when our non-spinlock code is being executed, and with Opteron/Itanium,
> > it seems like a good time to get it working.
>
> Well, as
Marc G. Fournier wrote:
> > But it seems to me that this is mostly a cosmetic cleanup and therefore
> > not the kind of thing to be doing late in beta. Couldn't we do
> > something that affects only Opteron/Itanium and doesn't take a chance
> > on breaking everything else?
>
> I just went through
On Thu, 11 Sep 2003, Bruce Momjian wrote:
> Yes, but to throw an error if spinlocks aren't found, we need this
> patch. We would have to test for Opteron in all the platforms that test
> for specific CPU's but don't test for opteron, and might support
> opterion/itanium, but even then, we don't
--On Thursday, September 11, 2003 23:46:56 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Thu, 11 Sep 2003, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The problem with waiting for 7.5 is that we will have no error
> reporting when our non-spinlock code is being execu
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Thu, 11 Sep 2003, Tom Lane wrote:
>> Well, as long as you're prepared to reduce the list of known supported
>> platforms to zero as of 7.4beta3, and issue a fresh call for port reports.
> I didn't think we had done that yet ... had we? called fo
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all=
> =20
> care).
Unfixably? Or just a small oversight?
I'm actually not worried about platforms that are actively being tested.
It's the stuff that hasn't been confirmed recent
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I guess we could splatter a test for Itanium and Opterion in every port
> > that could possibly use it, but then again, if we fall back to not
> > finding it for some reason, we don't get a report because we silently
> > fall back to s
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, we could do just the configure warning, then plaster tests into the
> port files to try to hit all the opteron/itanium cases. I am a little
> concerned that this might throw up a bunch of problem cases that we will
> patching for a while.
Probably
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, we could do just the configure warning, then plaster tests into the
> > port files to try to hit all the opteron/itanium cases. I am a little
> > concerned that this might throw up a bunch of problem cases that we will
> > patchi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Looking at the code, I wonder if we already have folks not using
> spinlocks, and not even knowing it. I don't think problem reports will
> be limited to new platforms.
Very likely --- I heard from someone recently who was trying to run
HPUX/Itanium. A
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Looking at the code, I wonder if we already have folks not using
> > spinlocks, and not even knowing it. I don't think problem reports will
> > be limited to new platforms.
>
> Very likely --- I heard from someone recently who was tr
--On Thursday, September 11, 2003 23:42:53 -0400 Tom Lane
<[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Looking at the code, I wonder if we already have folks not using
spinlocks, and not even knowing it. I don't think problem reports will
be limited to new platforms.
Ve
Larry Rosenman <[EMAIL PROTECTED]> writes:
>> Please, only the first two. Make the Unixware template add __i386__.
>> Don't add assumptions about valid user-namespace symbols.
> that's reasonable. At least until 64-bit UnixWare. :-)
Even then, I'd prefer to put the necessary kluge into template
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I've already sent a whine-a-gram to the compiler guys at SCO.
Prolly you thought of this already, but: getting them to *add*
an implicit #define of __i386__ should be plenty easy compared
to getting them to *remove* the one for i386. And while I think
On Thu, 11 Sep 2003, Bruce Momjian wrote:
> Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
> I guess we could splatter a test for Itanium and Opterion in every port
> that could possibly use it, but then again, if we fall back to not
> finding it for some reason, we don
Marc G. Fournier wrote:
>
>
> On Thu, 11 Sep 2003, Bruce Momjian wrote:
>
> > Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
> > I guess we could splatter a test for Itanium and Opterion in every port
> > that could possibly use it, but then again, if we fall back to no
46 matches
Mail list logo
