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
well
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
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 t
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:
http://archives.postgresql.org/pgsql-hackers/2005-07/msg0008
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
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 f
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 t
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 any
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.
Patch removed from queue.
---
Neil Conway wrote:
> A coworker of mine reported a subtle issue in ATExecAlterColumnType() in
> tablecmds.c. Suppose we have the following DDL:
>
> CREATE TABLE pktable (a int primary key, b i
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 c
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 o
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
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Marko Kreen 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 emp
On Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote:
> Marko Kreen 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 handle
On Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote:
> Marko Kreen 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 h
Marko Kreen 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 decrypt su
On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
> Marko Kreen 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 function
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
---
Marko Kreen 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 NULL argume
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
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_sal
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 ret
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 p
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 FUNC
On Sun, 3 Jul 2005 04:47 pm, Greg Stark wrote:
>
> Bruce Momjian 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().
>
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_s
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
I
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 trans
29 matches
Mail list logo