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 statements, so the
functions are all created VOLATILE. Shouldn't most of them be
IMMUTABLE? Or do the algorithms have side effects?
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 statements, so the
functions are all created VOLATILE. Shouldn't
Bruce Momjian pgman@candle.pha.pa.us writes:
I have an idea! Currently we write the backup pages (copies of pages
modified since the last checkpoint) when we write the WAL changes as
part of the commit. See the XLogCheckBuffer() call in XLogInsert().
Can someone explain exactly what the
On Sat, 2 Jul 2005, Oliver Jowett wrote:
Sorry to keep beating on this, but I still don't see where the spec says
that you must have only one RM per transaction branch.
Sure, it's important to get this right.
2.2.6 says:
2.2.6 Transaction Branches
A global transaction has one or more
Bruce Momjian wrote:
Andreas Pflug wrote:
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 02 July 2005 21:30
To: Bruce Momjian
Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
On 7/3/05, Andreas Pflug [EMAIL PROTECTED] wrote:
Yup, attached. Per our earlier conversation, pg_dbfile_size() now
returns the size of a table or index, and pg_relation_size() returns the
total size of a relation and all associated indexes and toast tables
etc.
pg_relation_size's name
On Sun, 3 Jul 2005 04:47 pm, Greg Stark wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I have an idea! Currently we write the backup pages (copies of pages
modified since the last checkpoint) when we write the WAL changes as
part of the commit. See the XLogCheckBuffer() call in
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 Sat, Jul 02, 2005 at 09:46:19PM +0200 I heard the voice of
Peter Eisentraut, and lo! it spake thus:
Bruce Momjian wrote:
Does the FreeBSD one actually produce different output?
If it did not, why would they bother making a separate package
called gnu-autoconf with the note This port is
On Sun, Jul 03, 2005 at 03:59:51PM +0300, Marko Kreen wrote:
On Sun, Jul 03, 2005 at 12:43:32AM -0600, Michael Fuhr wrote:
Yeah, I see that gen_salt() needs to be volatile, but I was thinking
about functions like digest(), encrypt(), decrypt(), etc., that
would be expected to return the
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
Greg Stark [EMAIL PROTECTED] writes:
Can someone explain exactly what the problem being defeated by writing whole
pages to the WAL log?
Partial writes. Without the full-page image, we do not have enough
information in WAL to reconstruct the correct page contents.
A further optimization would
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 functions, I am increasingly
favouring throwing error in case of
Dawid Kuroczko [EMAIL PROTECTED] writes:
Oh, I think pg_dbfile_size is best so far.
I think it's by far the ugliest suggestion yet :-(
Andreas's suggestion of having just one function with a bool parameter
might be a workable compromise.
regards, tom lane
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
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 have mainly issues with decrypt part. I'd like
to say, if
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 Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
As for the crypt() case, lets say you have a new user with
hashed password field NULL. In addition, you have client
program that compares crypt() result with hashed field
itself, in addition it
Alvaro Herrera [EMAIL PROTECTED] writes:
Marko Kreen marko@l-t.ee writes:
As for the crypt() case, lets say you have a new user with
hashed password field NULL. In addition, you have client
program that compares crypt() result with hashed field
itself, in addition it handles NULL's as empty
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Can someone explain exactly what the problem being defeated by writing whole
pages to the WAL log?
Partial writes. Without the full-page image, we do not have enough
information in WAL to reconstruct the correct
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Partial writes. Without the full-page image, we do not have enough
information in WAL to reconstruct the correct page contents.
Sure, but why not?
If a 8k page contains 16 low level segments on disk and the old data is
Tom Lane wrote:
Hmm ... I suppose the implication of that is that the upstream zic
files *are* architecture-independent, else people wouldn't keep them
in /share; and looking at the code, it does seem some effort is made
in that direction.
With that in mind, I have installed the original
Marko Kreen wrote:
On Sun, Jul 03, 2005 at 07:54:47AM -0600, Michael Fuhr wrote:
In the functions marked STRICT, should I leave the PG_ARGISNULL()
checks in place as a precaution? Removing those checks could cause
problems if people use the new code but have old (non-STRICT) catalog
entries.
On Mon, Jul 04, 2005 at 11:42:14AM +1000, Neil Conway wrote:
Assuming the STRICT / IMMUTABLE changes are only going into HEAD, you
can safely remove the PG_ARGISNULL() checks -- people upgrading from a
prior version of Postgres (and therefore pgcrypto) will need to dump and
reload anyway.
Michael Fuhr wrote:
But if they restore a dump made with pg_dump or pg_dumpall, they'll
get the old catalog entries sans STRICT, no? People might rebuild
the module when they upgrade, but they might not think to drop and
recreate the functions since the definitions are already in the
dump.
I
CVS tip fails with
./configure --with-openssl \
--with-includes=/usr/local/ssl/include --with-libs=/usr/local/ssl/lib
...
make[3]: Entering directory `/home/postgres/pgsql/src/interfaces/libpq'
...
/usr/ccs/bin/ld +h libpq.sl.4 -b +b /home/postgres/testversion/lib fe-auth.o
fe-connect.o
Here is a rough outline of what is coming for 8.1:
o On Monday, we will collect all submitted patches.
o Within the next 2-4 weeks, we will apply all patches that
can be applied.
o We will make sure all changes since 8.1 are working resonably
well and are documented. This is the cleanup
Tom Lane wrote:
It appears that somebody has changed things so that the -L switches
appear after the -l switches (ie, too late). I'm too tired to
investigate now, but my money is on Autoconf 2.59 being the problem ...
Perhaps this:
On Sun, Jul 03, 2005 at 08:15:07PM +0300, Marko Kreen wrote:
Michael, the result is, you can make them all STRICT.
OK. Does anybody else have thoughts on removing the PG_ARGISNULL()
checks? Neil suggests removing them because they'd be unnecessary,
but I'm concerned about people who'd use
Michael Fuhr [EMAIL PROTECTED] writes:
OK. Does anybody else have thoughts on removing the PG_ARGISNULL()
checks? Neil suggests removing them because they'd be unnecessary,
but I'm concerned about people who'd use the new code with old
catalog entries that aren't STRICT (e.g., restored from
On Mon, 4 Jul 2005, Bruce Momjian wrote:
Here is a rough outline of what is coming for 8.1:
o On Monday, we will collect all submitted patches.
o Within the next 2-4 weeks, we will apply all patches that
can be applied.
o We will make sure all changes since 8.1 are working resonably
31 matches
Mail list logo
