Bruce Momjian wrote:
Patch applied. Thanks.
thanks - that's wonderful news :-)
However the patch as it went in has a minor cosmetic issues with the
display of the --help output.
Maybe something like the attached patch should be applied to restore
the alphabetical option ordering and make the out
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> ... And then we'd need to change the regression makefile to use
>> the option, based on an environment variable a bit like MAX_CONNEXCTIONS
>> maybe.
>
> Why wouldn't we just use it always? If a regression test dumps core,
> that's
on an Intel based Solaris 10U2 box using Sun Studio 11 with
-xarch=generic64 we get a compile time failure in contrib/pgcrypto
because BYTE_ORDER is not defined.
in src/include/port/solaris.h we define it to little endian only for
__i386 - however in 64bit mode the compiler only defines __amd64 ca
Stefan Kaltenbrunner wrote:
on an Intel based Solaris 10U2 box using Sun Studio 11 with
-xarch=generic64 we get a compile time failure in contrib/pgcrypto
because BYTE_ORDER is not defined.
in src/include/port/solaris.h we define it to little endian only for
__i386 - however in 64bit mode the
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> on an Intel based Solaris 10U2 box using Sun Studio 11 with
>> -xarch=generic64 we get a compile time failure in contrib/pgcrypto
>> because BYTE_ORDER is not defined.
>
> After further though
Alvaro Herrera wrote:
> Magnus Hagander wrote:
>> Gevik Babakhani wrote:
I'd be willing to accept a core uuid type sans generator function,
but is that really all that useful?
>>> This is also a point I remember from the last discussions. To not to
>>> include the generator in the c
Neil Conway wrote:
On Sun, 2007-01-21 at 00:17 +0100, Gevik Babakhani wrote:
So.. do we agree for uuid to be included in the core?
I'd be curious to know the degree to which the proposed patch is
consistent with RFC 4122, which AFAIK is the most recent relevant
standard.
With regard to functi
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> ... In regards to your idea of a filter, there is no reason why
>> we couldn't install a filter that checks for signatures with specific
>> legal words and strips said signature automatically, responding to the
>> sender that we did
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Peter Eisentraut wrote:
>>> But the policy is that the presence of features in the final build
>>> should not depend on the incidental presence of features in the build
>>> environment. Either you select a feature, then it's built,
Neil Conway wrote:
> On Mon, 2007-02-07 at 23:13 -0400, Tom Lane wrote:
>> Er, was this on the agenda for 8.3?
>
> Well, it seemed fairly harmless to me (no behavioral changes and very
> little new code, just syntax), so I didn't see a compelling reason to
> delay applying it for a few months. But
Tom Lane wrote:
> "Jacob Rief" <[EMAIL PROTECTED]> writes:
>> Just for curiosity, I would like to ask something.
>> libpqxx is based on libpq, and thus includes headers-files from libpq.
>> These header-files are C++-safe, otherwise libpqxx would'nt compile.
>
> Well, if they are, it's only by cha
The just commited GSSAPI patch is unable to find the required libraries
and includes on OpenBSD (which are in /usr/include/kerberosV/) - the
attached patch allows building with gssapi support on OpenBSD 4.0/amd64
(and still seems to build fine on Debian Etch/x86_64).
Note that the patch does not in
the attached patch adds -lgss to the autoconf tests and enables
--with-gssapi builds on solaris 10 (and probably others).
Stefan
Index: configure
===
RCS file: /projects/cvsroot/pgsql/configure,v
retrieving revision 1.553
diff -c -r1
Pavan Deolasee wrote:
>
> Please see updated version of the patch. This includes further code
> refactoring and bug fixes.
>
> heapam code is now refactored and I have also added several comments
> in that code as well as vacuum and create index related code.
>
> In the previous version, we were
Heikki Linnakangas wrote:
> Stefan Kaltenbrunner wrote:
>> tried to test a bit on my Solaris 10 install(sun studio , 64bit build)
>> but I'm hitting the following while trying to initdb a new cluster:
>
> I can't reproduce this error, but I found a bug that's
I'm slowly working on submitting patches to reduce the amount of (bogus)
compiler warnings generated by various buildfarm members.
Warthog(the unixware box) generates some 1140 lines of:
UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled
UX:cc: WARNING: debugging and opt
the attached patch makes teh following changes to the psql tab-complete
support
* adds a few missing words to some commands (like adding GIN as a valid
index type or OWNED BY for ALTER SEQUENCE,...)
* support for ALTER TABLE foo ENABLE/DISABLE REPLICA TRIGGER/RULE
* autocomplete CREATE DATABASE
ially about the \du change)?
regards
Stefan Kaltenbrunner
Changes in Detail:
*) SET SCHEMA for ALTER AGGREGATE,FUNCTION.DOMAIN,SEQUENCE,TABLE,TYPE
*) add CONNECTION LIMIT to ALTER DATABASE
*) add support for ALTER ROLE
*) make ALTER USER aware about ROLES
*) COMMENT ON LARGE OBJECT
*) add suppor
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>attached is a patch against psql that makes psql's tabcomplete code
>>ROLES aware, adds SET SCHEMA and basic CREATE DATABASE/TRIGGER support
>>as well as some other minor things.
>
>
Chris Browne wrote:
> We haven't seen any agreement emerge as to what is causing AIX 5.3 ML3
> to fail to successfully build the release candidates.
>
> However, a patch has emerged (thanks, Seneca!) that does allow it to
> work, and which I'd expect to be portable (better still!).
>
> We are sti
Hi!
looks like somebody forgot to test some changes to the pg_dumpall code
in Revision 1.70 against <8.1 installations - resulting in the
following syntax error:
--
-- PostgreSQL database cluster dump
--
\connect postgres
pg_dumpall: query failed: ERROR: syntax error at or near "null"
LIN
Peter Eisentraut wrote:
> Stefan Kaltenbrunner wrote:
>
>>looks like somebody forgot to test some changes to the pg_dumpall
>>code in Revision 1.70 against <8.1 installations - resulting in the
>>following syntax error:
>
>
> Dump output is never expected to
Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> OK, based on this feedback, I am adding COPY VIEW to the patches queue.
>> I think we have other things that demand our attention more than a
>> half-baked feature.
>
> Well, the patch was submitted in time, an
[sorry if you get this mail twice, i think my first post didn't made it
passt the moderator queue]
Hi!
While playing around with 8.0devel I found it somewhat irritating that
psql had no tab-complete support for all tablespace related commands.
Attached is my own poor attempt that adds at least ba
Hi!
While playing around with 8.0devel I found it somewhat irritating that
psql had no tab-complete support for all tablespace related commands.
Attached is my own poor attempt that adds at least basic support for
CREATE/ALTER/DROP and \db.
When looking through the code I found that there seem t
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
When looking through the code I found that there seem to be much more
places where the tabcomplete-code is not 100% in sync with what the
doc's show as possible syntax.
Is there interest in fixing those up (ie qualifing as BUGS that can get
Gavin Sherry wrote:
Index: src/bin/psql/tab-complete.c
===
RCS file: /usr/local/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.109
diff -2 -c -r1.109 tab-complete.c
*** src/bin/psql/tab-complete.c 28 Jul 2004
Hi all!
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code.
This diff includes the still missing tab-complete support for TABLESPACE
I already sent earlier.
New in this version of the patch is a small adaption of the tab-complete
code to supp
Bruce Momjian wrote:
Great, patch applied. I merged it into Gavin's recent ALTER INDEX
addition.
Many thanks for applying my first patch, but looking at result I noticed
that you have removed INDEX from the list_ALTER which looks like a
possible merge-error to me(Garry added that one in his orig
Tom Lane wrote:
> I've attached the 2PC patch as applied in case you want to have a look.
> I did some fairly significant hacking on it, and I thought it'd be a
> good idea to enumerate some of the changes:
FYI: this commit seems to cause problems/crashes during make check on my
OpenBSD/Sparc64 b
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>FYI: this commit seems to cause problems/crashes during make check on my
>>OpenBSD/Sparc64 buildfarmclient:
>
>
>>http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2005
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>>Can you get a stack trace from the core dump?
>
>
>>(gdb) bt
>>#0 0x50377ba4 in memcpy () from /usr/lib/libc.so.34.2
>>#1 0x00326efc in hash_search ()
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>the machine had some issues a week ago or so - but it looks like the
>>problem occured first here:
>
>
> Hmm, what kind of issues, and are you sure they are fixed?
admin error :-).
I had a s
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
There is a problem in PL/TCL that can cause the postgres backend to
become multithreaded. Postgres is not designed to be multithreaded, so
this causes downstream errors in s
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> hmm i wonder if that could be related to:
>> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00377.php
>
> I had forgotten that thread, but it sure does look related doesn't it?
>
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> yeah testing that patch now (seems to apply just fine on -HEAD) but it
>> seems that there is something strange going on because I just got:
>
> ! ERROR: could not read block 2 of relation 1663
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> yeah testing that patch now (seems to apply just fine on -HEAD) but it
>> seems that there is something strange going on because I just got:
>
> ! ERROR: could not read block 2 of relation 1663
Marshall, Steve wrote:
> I'm glad to see the patch making its way through the process. I'm also
> glad you guys do comprehensive testing before accepting it, since we are
> only able to test in a more limited range of environments.
>
> We have applied the patch to our 8.2.4 installations and are
Joshua D. Drake wrote:
> On Sun, 04 Nov 2007 13:24:54 -0500
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> Shouldn't --with-libxml be noted as deprecated?
>> Huh?
>
> Because in 8.3 it is in core or am I misunderstanding the difference?
you missunder
Gregory Stark wrote:
"Kris Jurka" <[EMAIL PROTECTED]> writes:
On Mon, 28 Jan 2008, Jeff Davis wrote:
I think that pg_dump is a reasonable use case for synchoronized scans
when the table has not been clustered. It could potentially make pg_dump
have much less of a performance impact when run a
40 matches
Mail list logo
