OK: Linux 2.4.2 i686 / gcc 2.95.2 / Debian testing/unstable
no problems.
OK?: NetBSD 1.5 i586 / egcs 2.91.66 / (netbsd-1-5 from Jan)
netbsd FAILED the geometry test, diff attached, dunno if its
critical or not.
--
marko
*** ./expected/geometry-positive-zeros.out Wed Mar 21 15:07:12
On Tue, Apr 10, 2001 at 02:24:33PM -0300, The Hermit Hacker wrote:
Theoretically, should one be able to do:
pg_dumpall db.out
remove 7.0.3 bin, lib, data, etc
install 7.1 bin, lib, etc
initdb 7.1
psql template1 db.out
Basically, has anyone actually tried *that* yet and can report
On Thu, Apr 26, 2001 at 05:20:53PM +0200, Peter Eisentraut wrote:
will trillich writes:
i know password can be used in creating/altering user
information (as used via GRANT and REVOKE) but is there any
facility within postgres to CRYPT() a value?
See contrib/pgcrypto for hashing
On Sat, May 05, 2001 at 01:09:38PM -0400, mlw wrote:
A small debate started with bad performance on ReiserFS. I pondered the likely
advantages to raw device access. It also occured to me that the FAT file system
is about as close to a managed raw device as one could get. So I did some
tests:
On Sat, May 05, 2001 at 04:54:07PM +0300, Vladimir V. Zolotych wrote:
I see the following
proba= select * from pg_language;
lisp|f |f |0|/usr/ucb/liszt
Would you mind to tell me is it possible to use Lisp
as procedural language ? Which Lisp (e.g
On Sun, Sep 30, 2001 at 12:54:25AM +0200, Peter Eisentraut wrote:
Tom Lane writes:
While that's not a fatal problem, I could imagine *much* more serious
misbehavior from inconsistent settings of some GUC parameters. Since
backends believe that these parameters have PGC_POSTMASTER
On Sun, Sep 30, 2001 at 02:13:34PM -0400, Bruce Momjian wrote:
Marko Kreen [EMAIL PROTECTED] writes:
I wonder whether we should retire -o.
How about putting -o stuff after -p? That way only postmaster
code can set PGC_POSTMASTER options for a backend, no way for
user to mess up
On Sun, Oct 28, 2001 at 02:34:49PM +0100, Jean-Michel POURE wrote:
psql uses your input literally - so is your console/xterm in
UNICODE/UTF8?
Client: \encoding returns 'UNICODE'.
Server: \list show databases. All databases are UNICODE (except TEMPLATE0
and TEMPLATE1 which are ASCII of
On Sun, Oct 28, 2001 at 04:37:48PM +0100, Jean-Michel POURE wrote:
At 17:09 28/10/01 +0200, you wrote:
$ echo accepté | od -c
It is:
000 a c c e p t é \n
010
Huh. Then try 'od -t x1'. Also what the commend 'locale'
prints.
Hmm. It may be
On Sun, Oct 28, 2001 at 09:22:24AM +0100, Jean-Michel POURE wrote:
Dear all,
I am running PostgreSQL 7.1.2 with UNICODE support in production.
Maybe I miss something about UNICODE:
SELECT * FROM test WHERE source_content ILIKE '%accepté%' --- returns
nothing
SELECT * FROM test WHERE
On Sun, Oct 28, 2001 at 09:22:24AM +0100, Jean-Michel POURE wrote:
I am running PostgreSQL 7.1.2 with UNICODE support in production.
Maybe I miss something about UNICODE:
CREATE TABLE test (
source_oid serial,
source_timestamp timestamp,
source_creation date DEFAULT 'now',
On Sun, Oct 28, 2001 at 12:44:26PM +0100, Jean-Michel POURE wrote:
I only want this query to work under Unicode:
SELECT * FROM test WHERE source_content ILIKE '%accepté%'.
As I showed it works, if data in db is in UTF-8 and the query
string 'accepté' is in UTF8
* If client_encoding ==
On Wed, Oct 10, 2001 at 11:33:04AM +1000, Chris Bitmead wrote:
So my question is, I assume TEXT is the best data type to store
large things in, what precisely is the range of characters that
I can store in TEXT? Is it only characters ascii = 127, or is
it only printable characters, or
On Tue, Oct 02, 2001 at 09:49:03AM +0200, Hannu Krosing wrote:
HI,
I've seen lots of talk about anoncvs not working, but I
can't even find out where it is ;(
:pserver:[EMAIL PROTECTED]/projects/cvsroot
--
marko
---(end of broadcast)---
Finally, here is pgp_encrypt()/pgp_decrypt() - implementation
of password-based encryption from RFC2440 (OpenPGP).
The goal of this code is to be more featureful encryption solution
than current encrypt(), which only functionality is running cipher
over data.
Compared to encrypt(), pgp_encrypt()
On Sun, Jul 03, 2005 at 12:43:32AM -0600, Michael Fuhr wrote:
On Sun, Jul 03, 2005 at 04:24:31PM +1000, Russell Smith wrote:
On Sun, 3 Jul 2005 03:32 pm, Michael Fuhr wrote:
I've noticed that contrib/pgcrypto/pgcrypto.sql.in doesn't include
a volatility category in its CREATE FUNCTION
On Sun, Jul 03, 2005 at 07:54:47AM -0600, Michael Fuhr wrote:
I'll submit a patch. Does the following look right?
digest IMMUTABLE STRICT
digest_exists IMMUTABLE STRICT
hmac IMMUTABLE STRICT
hmac_existsIMMUTABLE STRICT
crypt IMMUTABLE STRICT
gen_salt
On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
And if you decide to do it, please make them all STRICT too,
_except_ encrypt/decrypt functions. Thats an additional change
I have in the air for pgcrypto.sql.in.
As for the encrypt/decrypt
On Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
That doesn't seem like a good idea at all. Why shouldn't an encryptable
value be NULL? I think you should just make 'em strict.
Well, I
On Tue, Jul 05, 2005 at 10:20:17AM +1000, Neil Conway wrote:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
That is not the latest version of Marko's patch.
Bruce got v3, thats indeed the latest.
Also, http://momjian.postgresql.org/cgi-bin/pgpatches
On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
regression tests fail the 3des test. I haven't checked against
older versions of OpenSSL; I'll do so when I get a chance.
I haven't dug into the pgcrypto code yet
On Tue, Jul 05, 2005 at 02:18:00PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
regression tests fail the 3des test. I haven't checked against
older
On Tue, Jul 05, 2005 at 02:55:07PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
I see 2 variants:
1) put @with_openssl@ and @with_zlib@ variables into
contrib/pgcrypto/Makefile.in and let configure process it.
2) put them in some other makefile fragment under src
On Tue, Jul 05, 2005 at 03:36:06PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 05, 2005 at 02:55:07PM -0400, Tom Lane wrote:
Hm ... libpq manages to build code that requires openssl without
needing a generated Makefile, so why do we need it here?
Now, looking
On Tue, Jul 05, 2005 at 03:58:43PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
Oh, ofcourse I would not need to break it, if the interesting
settings can be put into eg. src/Makefile.config (.in), and
I include that one.
You mean Makefile.global.in, no? That seems fine to me
On Tue, Jul 05, 2005 at 04:16:04PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 05, 2005 at 03:58:43PM -0400, Tom Lane wrote:
You mean Makefile.global.in, no? That seems fine to me.
No, thats the point - the PGXS include also includes
Makefile.global
On Tue, Jul 05, 2005 at 07:20:48PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
Ok Tom, you win. It is indeed possible to make it work, and the
resulting makefile is even cleaner than before.
Following patch thus autoconfigures pgcrypto. It drops the
possibility to use libc's
On Sun, Jul 10, 2005 at 10:59:35AM +0200, Stefan Kaltenbrunner wrote:
looks like the latest pgcrypto-patches that just got applied cause
widespread failures on the buildfarm machines:
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Seems like Bruce forgot to 'cvs add' new files...
--
On Sun, Jul 10, 2005 at 10:00:04AM -0400, Bruce Momjian wrote:
All new files added, and I think all the pgcrypto patches are now
applied to CVS. I just added the openssl version patch, I see the
IMMUTABLE patch is already in, and I see the autoconfiguration stuff is
already in.
Is there
On Sun, Jul 10, 2005 at 10:00:04AM -0400, Bruce Momjian wrote:
Marko Kreen wrote:
On Sun, Jul 10, 2005 at 10:59:35AM +0200, Stefan Kaltenbrunner wrote:
looks like the latest pgcrypto-patches that just got applied cause
widespread failures on the buildfarm machines:
http
On Sun, Jul 10, 2005 at 11:37:22AM -0400, Bruce Momjian wrote:
Marko Kreen wrote:
I see from buildfarm, that pgcrypto fails to build on a
non-OpenSSL machine. The reason for it is a stale openssl/bn.h
include in pgp-pubdec.c. I did not spot it, as even for
--without-openssl build I
On Sun, Jul 10, 2005 at 09:10:29PM +0300, Marko Kreen wrote:
On Sun, Jul 10, 2005 at 11:37:22AM -0400, Bruce Momjian wrote:
Marko Kreen wrote:
I see from buildfarm, that pgcrypto fails to build on a
non-OpenSSL machine. The reason for it is a stale openssl/bn.h
include in pgp-pubdec.c
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=potorooodt=2005-07-10%2022:30:03
New sha2 code on Solaris 2.8 / SPARC. Seems like it has
problems memcpy'ing to a non-8-byte-aligned uint64 *.
Attached patch fixes it by simplifying the _Final code and
getting rid of the pointer.
(I redefined
On Mon, Jul 11, 2005 at 05:50:32AM -0500, Andrew Dunstan wrote:
Marko Kreen said:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=2005-07-11%2002:30:00
NetBSD 1.6 with older OpenSSL. OpenSSL 0.9.7 does not have
AES, but most of PGP tests use it as it is the preferred cipher
On Mon, Jul 11, 2005 at 02:59:54PM +0300, Marko Kreen wrote:
On Mon, Jul 11, 2005 at 05:50:32AM -0500, Andrew Dunstan wrote:
Marko Kreen said:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=2005-07-11%2002:30:00
NetBSD 1.6 with older OpenSSL. OpenSSL 0.9.7 does not have
On Mon, Jul 11, 2005 at 10:10:12AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
Result is - it's not so bad. As I used rijndael.c to provide
OpenSSL's own interface, I even got rid of all the ifdefs inside
the code.
Looks good, but I'm still getting these compile warnings
On Mon, Jul 11, 2005 at 10:13:22AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
(I redefined bzero and bcopy but now I think they should be
replaced directly - patch later.)
Please. We do not use those old functions in the Postgres code;
memcpy, memmove, memset, etc
On Mon, Jul 11, 2005 at 11:09:06AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
New sha2 code on Solaris 2.8 / SPARC. Seems like it has
problems memcpy'ing to a non-8-byte-aligned uint64 *.
...
Attached patch includes sys/param.h, where I found them on
MINGW, and puts
On Mon, Jul 11, 2005 at 09:19:37AM -0600, Michael Fuhr wrote:
On Mon, Jul 11, 2005 at 10:39:26AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
They won't matter on older OpenSSL, as the macros will recast
again. But on 0.9.7e the signature is:
void DES_ecb3_encrypt(const
On Mon, Jul 11, 2005 at 11:46:29AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
Here is the bcopy, bzero removal patch.
Applied.
I'm seeing the following build failure on HPUX:
/usr/ccs/bin/ld +h libpgcrypto.sl.0 -b +b /home/postgres/testversion/lib
pgcrypto.o px.o px
Another build failure from buildfarm. Seems like
I forgot to update win32 code when doing a renaming
in random.c
--
marko
Index: contrib/pgcrypto/random.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/random.c,v
retrieving
On Mon, Jul 11, 2005 at 04:47:18PM -0700, Kris Jurka wrote:
Marko Kreen wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2005-07-11%2003:30:04
Linking problem with zlib on Solaris 9/x86. I am clueless about
this. I can anyone look into it?
It appears
Seems like down mail server ate first mail.
Here it is again.
On Tue, Jul 12, 2005 at 12:51:44PM +0300, Marko Kreen wrote:
Hopefully the last regression failure.
- openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH
constants for buffers, which are small in case of
OpenSSL 0.9.6x
Hopefully the last regression failure.
- openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH
constants for buffers, which are small in case of
OpenSSL 0.9.6x and internal AES. (I tested it with
0.9.7 only, so I didn't notice...)
- Also I noticed that the wrapper macros for CBC mode
do
[buildfarm machine dragonfly]
On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
Well the buildfarm machine kudu is actually the same machine just building
with the Sun compiler and it works fine. It links all of libz.a into
libpgcrypto.so while gcc refuses to.
I googled a bit and
On Fri, Jul 15, 2005 at 08:06:15PM -0500, Kris Jurka wrote:
On Fri, 15 Jul 2005, Marko Kreen wrote:
[buildfarm machine dragonfly]
On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
Well the buildfarm machine kudu is actually the same machine just
building
with the Sun
On Mon, Aug 01, 2005 at 11:58:34AM -0700, Joshua D. Drake wrote:
What might this be?
Whether to warn on '\' in non-E'' strings.
AFAIK Bruce wants to turn this to 'on' in 8.2.
--
marko
---(end of broadcast)---
TIP 9: In versions below 8.0, the
On Thu, Aug 04, 2005 at 08:14:51PM +0200, Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
The alternative is to say that plpython isn't supported on BSDen unless
you choose to build an unthreaded libpython.
I'm OK with that, but if that's
On Sun, Aug 07, 2005 at 12:08:28PM -0400, Tom Lane wrote:
Couple thoughts here --- one, someone upthread suggested
cyg$(NAME)$(DLSUFFIX as the proper value for shlib. I didn't
see why at first, but now it occurs to me that it might avoid name
collisions with Windows-native builds, which use
On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
Currently, here are the options available for wal_sync_method:
#wal_sync_method = fsync# the default varies across platforms:
# fsync, fdatasync, fsync_writethrough,
On Mon, Aug 08, 2005 at 05:38:59PM -0400, Bruce Momjian wrote:
Marko Kreen wrote:
On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
Currently, here are the options available for wal_sync_method:
#wal_sync_method = fsync# the default varies across platforms
On Mon, Aug 08, 2005 at 06:02:37PM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
I think we should offer the reliable option by default, and mention the
fast option for those who have battery-backed cache in the manual.
But only on Win32?
We should do what's possible with what's given
On Mon, Aug 08, 2005 at 03:10:54PM -0700, Josh Berkus wrote:
Marko,
Also, why can't win32 be safe without battery-backed cache?
I can't see such requirement on other platforms.
Read the referenced message again. It's only an issue if you want to use
open_datasync. fsync_writethrough
On Mon, Aug 08, 2005 at 08:04:44PM -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Marko Kreen wrote:
On same topic:
http://archives.postgresql.org/pgsql-general/2005-07/msg00811.php
Why does win32 PostgreSQL allow data corruption by default?
It behaves the same
On Tue, Aug 09, 2005 at 10:02:44AM +0200, Magnus Hagander wrote:
It behaves the same on Unix as Win32, and if you have
battery-backed
cache, you don't need writethrough, so we don't have it as
default. I
Correction, if you have bbwc, you *should not* have writethrough. Not
only
On Tue, Aug 09, 2005 at 10:08:25AM +0200, Magnus Hagander wrote:
That can definitly be debated. Properly maintaned on proper hardware,
it's quite reliable these days.
Most filesystem corruptions that happen on windows are because people
enable write caching on drives without battery backup.
On Tue, Aug 09, 2005 at 12:14:09PM +0200, Magnus Hagander wrote:
That can definitly be debated. Properly maintaned on proper
hardware,
it's quite reliable these days.
Most filesystem corruptions that happen on windows are
because people
enable write caching on drives without
On Fri, Aug 12, 2005 at 10:27:16PM -0400, Bruce Momjian wrote:
Where are we going with this patch? It doesn't test specific OS's known
to fail.
I hoped people more familiar with the problem would tune it...
Here is updated patch where I test specifically
'openbsd*|freebsd*' instead of
On Tue, Aug 16, 2005 at 10:38:37AM -0700, David Fetter wrote:
If somebody has figured out a way to make a PL/Python (without the U),
that's great, but nothing has happened on this front in a couple of
years, and Guido said that it was a problem with the language that he
wasn't going to fix.
On Tue, Aug 16, 2005 at 01:46:26PM -0700, David Fetter wrote:
On Tue, Aug 16, 2005 at 11:39:04PM +0300, Marko Kreen wrote:
On Tue, Aug 16, 2005 at 10:38:37AM -0700, David Fetter wrote:
If somebody has figured out a way to make a PL/Python (without the
U), that's great, but nothing has
On Mon, Aug 15, 2005 at 01:06:15PM -0400, Tom Lane wrote:
So, if you've got any pending patches for the back branches, now would
be a good time to get 'em done up and sent in.
http://archives.postgresql.org/pgsql-patches/2005-07/msg00291.php
--
marko
---(end of
On Tue, Aug 23, 2005 at 03:51:35PM -0400, Bruce Momjian wrote:
I have finished working on the release notes for the moment:
http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1
I will update them just before we put out the beta.
Here's bit clarified pgcrypto summary:
/ anymore.
***
*** 1756,1762
listitem
para
! Remove support for filenamelibmhash/ and filenamelibmcrypt/
(Marko Kreen)
/para
/listitem
--- 1756,1762
listitem
para
! Remove support
On Sun, Sep 11, 2005 at 05:59:49PM -0400, Tom Lane wrote:
The second reason that the futex patch is helping is that when
a spinlock delay does occur, it allows the delaying process to be
awoken almost immediately, rather than delaying 10 msec or more
as the existing code does. However, given
On Tue, Sep 13, 2005 at 10:10:13AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
On Sun, Sep 11, 2005 at 05:59:49PM -0400, Tom Lane wrote:
However, given that we are only expecting
the spinlock to be held for a couple dozen instructions, using the
kernel futex mechanism is huge
On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
ARM platform fails the point test see below.
For the 7.4 release we got a report for the ARM platform where all tests
passed:
On Thu, Jan 06, 2005 at 09:07:14AM -0500, Jim Buttafuoco wrote:
I am using the stock Debian 2.4.27 kernel. Don't know how to
change the fp setup. Do you have any instructions for me?
It can be changed by configuring and recompiling kernel.
I checked the kernel-image-2.4.27-arm package from
On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
For the 7.4 release we got a report for the ARM platform where all tests
passed:
http://archives.postgresql.org/pgsql-hackers/2003-10/msg01212.php
Additional info point:
(sid)noel ( at ) debussy:~/postgresql-cvs/pgsql$
On Thu, Jan 06, 2005 at 10:21:43AM -0500, Jim Buttafuoco wrote:
I will recompile the kernel and get back to the list
Thanks. This way we can be sure it is FP-emulation effect.
--
marko
---(end of broadcast)---
TIP 8: explain analyze is your
On Thu, Jan 06, 2005 at 11:39:14AM -0500, Jim Buttafuoco wrote:
I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25
(with has CONFIG_FPE_NWFPE=y) and ALL
tests passed. So I will file a bug report with Debian. We should also put
something in the Postgresql readme
On Thu, Jan 06, 2005 at 12:32:12PM -0500, Andrew Dunstan wrote:
Marko Kreen wrote:
The question is rather how to handle it in PostgreSQL
regression testing:
1) Document the need for NWFPE - which gives standard results.
2) Use FastFPE results on Linux/ARM.
3) Autodetect - ok, that was a joke
On Thu, Jan 06, 2005 at 02:05:17PM -0500, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
I have not looked at pg_regress much and had not noticed the
'unconditional alternative' feature. I only thought of the
resultmap alternative. Unconditionally adding FastFPE results
may even
On Wed, Mar 16, 2005 at 07:46:23AM -0800, Moran.Michael wrote:
How do you encrypt() decrypt() data of types INT4 or DATE?
The PGCrypto methods encrypt() and decrypt() each take BYTEA as input:
i.e.,
encrypt( data::bytea, key::bytea, type::text)
decrypt( data::bytea, key::bytea,
On Thu, Mar 24, 2005 at 08:40:54AM -0800, Moran.Michael wrote:
# select * from crypto;
id | title |crypted_content
+---+
1 | test1 | \307\266xI\235\210a\363=\201\222\247\2660\215
2 | test2 |
On 12/9/05, Peter Eisentraut [EMAIL PROTECTED] wrote:
Tom Lane wrote:
As I said already, if the user wishes the password to be secure, he
needs to encrypt it on the client side.
Maybe we should provide a backslash command in psql for secure password
entry, say, \password [username]. This
On 12/12/05, Bruce Momjian pgman@candle.pha.pa.us wrote:
Qingqing Zhou wrote:
Seems we don't link against the port/qsort.c - is there any reason for
that? My tests indicates our qsort is much much faster than the libc's.
Are you willing to say that we should always prefer pgport over
On 23 Dec 2005 09:12:52 -0500, Greg Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
AndrewSN can't post at the moment, but asked me to post this for him:
Knowing the md5 hash is enough to authenticate via the 'md5'
+listitemparaFix bug in filename/contrib/pgcrypto/ Openwall
+gen_salt processing (Marko Kreen/para/listitem
I guess it should be bit more explicit:
listitemparaFix bug in filename/contrib/pgcrypto/ gen_salt,
which caused it not to use all available salt space for md5 and
xdes algorithms (Marko
On 1/23/06, Tom Lane [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Attached is a patch that merges postmaster and postgres into just a
postmaster command.
I had some second thoughts about this, specifically about which
direction do we really want to go in. With this
On 2/7/06, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Rawnsley [EMAIL PROTECTED] writes:
IMHO the #1 priority in the current PITR/WAL shipping system is to make the
standby able to tolerate being shut down and restarted, i.e. actually having
a true standby mode and not the current method of
On 2/9/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
What happens right now when you want to bring the standby up? Do you
have to kill it out of recovery mode and re-start, forcing it to replay
WAL again anyway?
touch $LOGDIR/STOP ...
--
marko
---(end of
On 2/9/06, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe this should be a configure flag, just like the port number is.
It is ... that isn't the issue, the problem is exactly that Debian
chooses to exercise the option to make their installations different
On 2/10/06, Dave Page dpage@vale-housing.co.uk wrote:
Something broke snake again :-(. Looks like tsearch2 through the haze of
my Lemsip... I hate winter :-(
AFAIR the reason for different length of psql's '' header lines
was database encoding being UNICODE not SQL_ASCII. Can this be the
On 2/10/06, Marko Kreen [EMAIL PROTECTED] wrote:
On 2/10/06, Dave Page dpage@vale-housing.co.uk wrote:
Something broke snake again :-(. Looks like tsearch2 through the haze of
my Lemsip... I hate winter :-(
AFAIR the reason for different length of psql's '' header lines
was database
I want to update one row from possibly several backends. In case
of SERIALIZABLE transactions, the update command may fail. To
hide it from calling transaction, I use a subtransaction and try
to catch and hide the error.
With help of plpgsql source, I wrote following code that _seems_
to work.
On 2/20/06, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
BeginInternalSubTransaction(NULL);
res = SPI_connect();
if (res 0)
elog(ERROR, cannot connect to SPI);
This seems like a pretty bad idea: if the SPI_connect fails you
On 2/21/06, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
On 2/20/06, Tom Lane [EMAIL PROTECTED] wrote:
This seems like a pretty bad idea: if the SPI_connect fails you lose
control without having unwound the subtransaction. That's unlikely,
but still wrong
On 3/17/06, Tom Lane [EMAIL PROTECTED] wrote:
The standard does address the issue of transactions that cannot be committed
because of an error. In 16.6. commit statement GR 6 it basically says
that
if the transaction cannot be completed (here: because of a constraint
violation), then
On 4/16/06, Bruce Momjian pgman@candle.pha.pa.us wrote:
Hannu Krosing wrote:
I guess that writing our own pg_tar, which cooperates with postgres
backends to get full pages, is still in the realm of possible things,
even on kernels which dont guarantee atomic visibility of write() calls.
On 5/11/06, Martijn van Oosterhout kleptog@svana.org wrote:
On Wed, May 10, 2006 at 04:03:51PM -0500, Jim C. Nasby wrote:
If the existing application is trying to start a new transaction from
within an existing one, I'd say it's already broken and we're just
hiding that fact.
Well maybe,
On 5/26/06, Martijn van Oosterhout kleptog@svana.org wrote:
On Fri, May 26, 2006 at 08:21:56AM +0200, Hans-Jürgen Schönig wrote:
I got a bug request for the following unicode character in PostgreSQL
8.1.4: 0xedaeb8
ERROR: invalid byte sequence for encoding UTF8: 0xedaeb8
Your character
On 5/27/06, Tom Lane [EMAIL PROTECTED] wrote:
I wrote:
I'm off for a little visit with oprofile...
It seems the answer is that fwrite() does have pretty significant
per-call overhead, at least on Fedora Core 4.
That may be because of the locking ritual all stdio functions
like to do, even
On 5/27/06, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
If you want to use fwrite as string operator, then maybe
should replace it with fwrite_unlocked?
ISTM that in a single-threaded application such as the backend,
it should be libc's responsibility to avoid
On 5/27/06, Martijn van Oosterhout kleptog@svana.org wrote:
Given there is no way to know if you're running single threaded or not,
I don't think glibc can take chances like that.
There's CPP symbol _REENTRANT for that and in run time,
libc can detect call to pthread_create [1].
In any case,
On 5/27/06, Tom Lane [EMAIL PROTECTED] wrote:
Historically pg_dump has taken pains to dump ASCII control characters
as backslash constructs, for instance \t for tab. I am thinking this
is not such a great idea, and that it'd be more portable rather than
less so if we got rid of that logic and
On 5/28/06, Martijn van Oosterhout kleptog@svana.org wrote:
With -lpthread
lock.enabled 323s
lock.disabled 50s
lock.unlocked 36s
I forgot to test with -lpthread, my bad. Indeed by default
something less expensive that full locking is going on.
The crux of the matter is though,
On 5/30/06, Bruce Momjian pgman@candle.pha.pa.us wrote:
The crux of the matter was if its possible to use fwrite
as easy string combining mechanism and the answer is no,
because it's not lightweight enough.
So your patch to src/backend/storage/file/fd.c should be discarded? OK.
Yes. It
On Thu, Oct 12, 2000 at 09:34:05PM +0200, Peter Eisentraut wrote:
Well, what are we going to do with this? I think we should take it.
Since I encouraged him to write it, I'd volunteer to take care of it.
Nice :)
We might want to change the bitxor operator to # (or at least something
On Thu, Oct 19, 2000 at 07:31:28PM +0200, Karel Zak wrote:
On Thu, 19 Oct 2000, Marko Kreen wrote:
http://www.l-t.ee/marko/pgsql/pgcrypto-0.1.tar.gz(11k)
At the last second I thougt that I should generate the 'configure'
so its 20k actually...
If it's really allows use all
On Thu, Oct 19, 2000 at 01:33:35PM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
If there is interest I can package it as a contrib or even
mainstream diff against CVS ???
Sure, I think people would be interested. It might be best to make it
contrib for now, until you
1 - 100 of 655 matches
Mail list logo
