On 4/6/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> So adopting the mixing changes would make it faster yet. What we need
> to be certain of is that this doesn't expose us to poorer hashing.
> We know that it is critical that all bits of the input affect all bits
> of the hash fairly uniformly --
On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> > I wonder if there's much of a use case for any statements aside from
> CREATE
> > statements. If we restrict it to CREATE statements we could h
Sorry to keep replying to myself, but part of the point of doing a
patch was to force myself (and whoever else is interested to examine
stuff that comes up...
On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan <[EMAIL PROTECTED]> wrote:
> None of that suggests that an uninstaller script would be needed
Simon Riggs wrote:
>> Few comments:
>>
>> * smart shutdown waits for sessions to complete, yet this just ignores
>> smart shutdowns which is something a little different. I think we
>> should wait for the backup to complete and then shutdown.
>
> If we add a function called something like BackupI
Attached patch implements wal_sync_method as an enum. I'd like someone
to look it over before I apply it - I don't have the machines to test
all codepaths (and some of it is hard to test - better to read it and
make sure it's right).
In order to implement the enum guc, I had to break out a new
SYN
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
During my work I found some header files, which include useless headers
and on other way there are some headers which silently assume that
requested header will be included by some ot
On Sun, Apr 06, 2008 at 12:02:25PM -0400, Tom Lane wrote:
> Kenneth Marshall <[EMAIL PROTECTED]> writes:
> > Okay, I will strip the VALGRIND paths. I did not see a real need for them
> > either.
>
> I have a patch ready to commit (as soon as I fix the regression test
> issues) that incorporates al
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >> Added to TODO:
> >> o Add ability to obfuscate function bodies
>
> > For the record. I think this todo is bogus.
>
> For the record, I think so too ;-). The agreed-on TODO wording ma
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> OK, I found an example that does NOT fit the "just drop all
> dependencies" scenario, but that I would still like to support. I just
> had a look at the postgis pl/java support, and its install does stuff
> like "SELECT sqlj.install_jar('file://${PWD}/pos
Albe Laurenz wrote:
Moreover, if Shutdown == SmartShutdown, new connections won't be accepted,
and nobody can connect and call pg_stop_backup().
So even if I'd add a check for
(pmState == PM_WAIT_BACKENDS) && !BackupInProgress() somewhere in the
ServerLoop(), it wouldn't do much good, because the
On Mon, Apr 7, 2008 at 7:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Tom Dunstan" <[EMAIL PROTECTED]> writes:
> > OK, I found an example that does NOT fit the "just drop all
> > dependencies" scenario, but that I would still like to support. I just
> > had a look at the postgis pl/java support
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
During my work I found some header files, which include useless headers
and on other way there are some headers which silently assume that
requested header will be included by some ot
Tom Lane napsal(a):
Bruce Momjian <[EMAIL PROTECTED]> writes:
Zdenek Kotala wrote:
bufpage.h includes bufmgr.h, but bufpage.h does not require any definition from
bufmgr.h. I think this dependency is there for long time.
My scripts should have found this issue, see
src/tools/pginclude/pgrmin
Zdenek Kotala wrote:
> PS: Is there any reason to do not start to use inline functions instead
> of macros in some cases?
Not all compilers like (== support) inline macros apparently.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Comman
On Sun, Apr 06, 2008 at 11:29:50PM +0100, Gregory Stark wrote:
> I wonder if there's much of a use case for any statements aside from
> CREATE statements.
Yes. Some modules could have COPY or equivalent in them, as they
could easily contain data.
Cheers,
David.
--
David Fetter <[EMAIL PROTECTE
Zdenek Kotala wrote:
> Alvaro Herrera napsal(a):
>> Zdenek Kotala wrote:
>>
>>> PS: Is there any reason to do not start to use inline functions
>>> instead of macros in some cases?
>>
>> Not all compilers like (== support) inline macros apparently.
>
> Is it your assumption or do you mean some spe
Zdenek Kotala wrote:
Is it your assumption or do you mean some specific compiler? IIRC,
inline is defined in C99 and my assumption :-) is that it should be
supported by all compilers today. I try to look on buildmachine, There
should be some useful configure output.
My recollection is t
Magnus Hagander wrote:
> Attached patch implements wal_sync_method as an enum. I'd like someone
> to look it over before I apply it - I don't have the machines to test
> all codepaths (and some of it is hard to test - better to read it and
> make sure it's right).
>
> In order to implement the enu
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
PS: Is there any reason to do not start to use inline functions instead
of macros in some cases?
Not all compilers like (== support) inline macros apparently.
Is it your assumption or do you mean some specific compiler? IIRC, inline is
defined
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Alvaro Herrera napsal(a):
>> Not all compilers like (== support) inline macros apparently.
> Is it your assumption or do you mean some specific compiler? IIRC, inline is
> defined in C99 and my assumption :-) is that it should be supported by all
> com
There's a bunch of mails in the patch queue about the indexam API, so we
need to discuss that.
The first question is: do we want to refactor the bitmap index scan API,
if we don't have any immediate use for it? Namely, since we don't have
anyone actively working on the bitmap index patch nor t
On Tue, 8 Apr 2008, Heikki Linnakangas wrote:
There's a bunch of mails in the patch queue about the indexam API, so we need
to discuss that.
The first question is: do we want to refactor the bitmap index scan API, if
we don't have any immediate use for it? Namely, since we don't have anyone
22 matches
Mail list logo
