Andrew Dunstan <[EMAIL PROTECTED]> writes:
> However, neither the new nor the old scripts run ECPG tests on my setup,
> so I have been unable to test that.
I'm confused. We have MSVC buildfarm animals that show green, so aren't
they getting through ECPG tests?
> I can commit the new scripts now
On 9/21/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> Well, my first round of results are so far not showing the big gains I
> saw with hot in some of the earlier patches...so far, it looks
> approximately to be a wash although with the reduced need to vacuum.
let me correct myself here. I did
I have reduced the build and regress .bat files to one liners:
build.bat:
@perl build.pl %*
vcregress.bat:
@perl vcregress.pl %*
These mirror exactly what the buildfarm will do when it's modified.
In fact, an unmodified buildfarm client run goes through cleanly with
these files.
However, n
>>> On Thu, Sep 6, 2007 at 7:31 PM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
On Thu, Sep 6, 2007 at 7:03 PM, in message
> <[EMAIL PROTECTED]>, Jeff Davis <[EMAIL PROTECTED]>
> wrote:
>>
>> I think ... there's still room for a simple tool that can zero ou
The right lib files to link readline are the .a ones...
Like this:
if ($solution->{options}->{readline})
{
$psql->AddIncludeDir($solution->{options}->{readline} .
'\include');
$psql->AddLibrary($solution->{options}->{readline} .
'\lib\libreadline.dll.a');
Also, I think I told you the wrong file to link to. I think it is the
.a files, not the .lib files.
Let me check on that.
> -Original Message-
> From: Chuck McDevitt
> Sent: Monday, September 24, 2007 10:34 AM
> To: 'Magnus Hagander'
> Cc: pgsql-hackers@postgresql.org
> Subject: RE: [HACK
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Riggs wrote:
> On Mon, 2007-09-24 at 13:09 -0400, Tom Lane wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>>> So it should be stats_command_string --> monitor_activity
>>> ...and the other one would be monitor_counts? OK, that fits for me.
>>
Please see if the attached patch works.
cheers
andrew
Chuck McDevitt wrote:
Of course it is better not to remove the readonly on all files in the
target dir. That's just a workaround I did because it didn't involve
changing the perl scripts.
I don't know the "right" perl way to change the re
On Mon, 2007-09-24 at 13:09 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > So it should be stats_command_string --> monitor_activity
> > ...and the other one would be monitor_counts? OK, that fits for me.
>
> Are we worried about having them both singular or both plural?
> I
Sorry, completion_matches hasn't existed in readline for a long time.
You need to define:
#define HAVE_RL_COMPLETION_APPEND_CHARACTER 1
#define HAVE_RL_COMPLETION_MATCHES 1
#define HAVE_RL_FILENAME_COMPLETION_FUNCTION 1
Just like we do on Linux.
> -Original Message-
> From: Magnus Haga
Of course it is better not to remove the readonly on all files in the
target dir. That's just a workaround I did because it didn't involve
changing the perl scripts.
I don't know the "right" perl way to change the readonly attribute on a
file. If there isn't one, you could have the perl code issu
Simon Riggs <[EMAIL PROTECTED]> writes:
> So it should be stats_command_string --> monitor_activity
> ...and the other one would be monitor_counts? OK, that fits for me.
Are we worried about having them both singular or both plural?
I seem to recall that point coming up in the prior thread.
It seems that the overhead is unnoticeable if disabled, very visible
for lightweight functions and heavy callers. Almost unnoticeable for
more compute intensive functions.
The very high system times seem odd. Maybe you have a machine with
slow gettimeofday()?
So it seems (on Ubuntu 7.04). Re
On Mon, 2007-09-24 at 12:50 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I'm sorry to raise this now. The earlier proposal for "track_" wasn't
> > supported by anyone that I can see, even though we decided to change the
> > way the stats parameters were arranged on those ear
"Tom Lane" <[EMAIL PROTECTED]> writes:
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>
>> I think we also should move the NumericData and declaration to numeric.c and
>> make the Numeric type an opaque pointer for the rest of the source
>> tree.
>
> I don't ag
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm sorry to raise this now. The earlier proposal for "track_" wasn't
> supported by anyone that I can see, even though we decided to change the
> way the stats parameters were arranged on those earlier threads.
Well, there was at least one other person wh
Darcy Buskermolen wrote:
> On September 23, 2007 09:12 pm, Alvaro Herrera wrote:
> > Darcy Buskermolen wrote:
> > > On September 14, 2007 06:36 am, Alvaro Herrera wrote:
> > > > Darcy, please also apply the following patch and see if it reduces the
> > > > CPU consumption to a reasonable level.
> >
On September 23, 2007 09:12 pm, Alvaro Herrera wrote:
> Darcy Buskermolen wrote:
> > On September 14, 2007 06:36 am, Alvaro Herrera wrote:
> > > Darcy, please also apply the following patch and see if it reduces the
> > > CPU consumption to a reasonable level.
> >
> > This is looking much better no
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm. One suggestion would be to have an internal function declared
>> as taking and returning "struct varlena *", with a comment saying that
>> we depend on text and bytea both being compatible with this. All three
>> SQL-visible fun
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have changed it. The thing is, though, that this function not only
performs the convert() function but acts as the engine for convert_to()
and convert_from(). Those functions do some silent transformations, in
one case passing a
Gregory Stark <[EMAIL PROTECTED]> writes:
> We previously discussed compressing the numeric data type for small values:
> http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php
> We didn't do this for 8.3 but in any case Tom did suggest we ought to reverse
> the weight and sign/dscale s
Martin Pihlak <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> That seems a confusing set of values. Perhaps "off", "pl", and "all"
>> would be clearer?
> Makes sense. It appears that the stats_ prefixed GUC names are deprecated now.
> Will rename to "track_functions" and change values to "off"
We previously discussed compressing the numeric data type for small values:
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php
We didn't do this for 8.3 but in any case Tom did suggest we ought to reverse
the weight and sign/dscale so we could do this sometime without introducing
Gregory Stark wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>
> > Simon Riggs wrote:
> >> On Mon, 2007-09-24 at 10:02 +0100, Heikki Linnakangas wrote:
> >>> How about just using MaxHeapTuplesPerPage? With the default 8K block
> >>> size, it's not that much more than 200, but makes the
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have changed it. The thing is, though, that this function not only
> performs the convert() function but acts as the engine for convert_to()
> and convert_from(). Those functions do some silent transformations, in
> one case passing a text Datum as
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
We can and possibly should change the GETARG call, but the varlena types
are structurally equivalent, so it's not a mortal sin being committed here.
We *definitely* should change it --- the reason for having all those
variant
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> We can and possibly should change the GETARG call, but the varlena types
> are structurally equivalent, so it's not a mortal sin being committed here.
We *definitely* should change it --- the reason for having all those
variant macros in the first plac
"Tom Lane" <[EMAIL PROTECTED]> writes:
> (It might be interesting to make textin produce a packed result when
> possible, just to see what breaks; but I would be afraid to try to do
> that for production...)
Reassuringly all checks pass with a hack like that in place. (attached)
I think the righ
Yes, I always tend to mix slash and backslash. No idea why ^^'.
Postgres version is:
PostgreSQL 8.2.4 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC)
3.4.2 (mingw-special)
and it does have this setting, but it was set to off.
Now, having this set I'll have to test it :)
Thank you for your ansew
Andrew Dunstan wrote:
src/bin/psql/common.c has a routine that lets psql get round this, by
not sending a BEGIN in the case of the offending statements. I have no
idea if this might be helpful for pgadmin though.
Yeah, unfortunately it's not that we wrap the statement in a begin/end -
we r
Neil Conway wrote:
On Thu, 2007-09-20 at 16:08 +0300, Martin Pihlak wrote:
The GUC variable stats_function_level now takes 3 values: on, off and all.
That seems a confusing set of values. Perhaps "off", "pl", and "all"
would be clearer?
Makes sense. It appears that the stats_ prefixed GUC na
I confess I have never used cvs edit.
Maybe it comes into the realm of "don't do that".
To answer Magnus' question elsewhere, you can't make File::Copy::copy()
do it automatically, nor Win32::CopyFile(). We would need a wrapper
that explicitly unlinked the target before copying. That's certa
On Mon, 2007-09-24 at 12:51 +0200, Peter Eisentraut wrote:
> Am Montag, 24. September 2007 schrieb Simon Riggs:
> > I would personally prefer the verb "monitor" rather than track. The
> > chapter in the docs is already called "Monitoring Database Activity".
>
> What the database system does is tra
This is the wrong list to ask this question. This list is about
development, not usage. Please ask on -general in future.
I presume that where you have "/" you really mean "\".
What version of postgres are you using? If you use a modern version with
standard_conforming_strings on then you do
Thea wrote:
> My problem is that PG behaves differently than other supported DBMSes
> (MSSQL and MySQL) - when I'm passing a query containing LIKE phrase to
> it, a double amount of '/' literals is needed to obtain expected
> result. I do realize that this is caused by a parser 'collapsing'
> doubl
Hello folks :)
I am working on a system that is possible to configure to work with
several DBMSes, including PG.
My problem is that PG behaves differently than other supported DBMSes
(MSSQL and MySQL) - when I'm passing a query containing LIKE phrase to
it, a double amount of '/' literals is need
src/bin/psql/common.c has a routine that lets psql get round this, by
not sending a BEGIN in the case of the offending statements. I have no
idea if this might be helpful for pgadmin though.
cheers
andrew
Dave Page wrote:
Heikki Linnakangas wrote:
Dave Page wrote:
I get the above error m
Brendan Jurd wrote:
Hi hackers,
In the process of trying to unify the various text/cstring conversions
in the backend, I came across some stuff that seemed weird in
pg_convert().
>From src/backend/utils/mb/mbutils.c:345:
Datum
pg_convert(PG_FUNCTION_ARGS)
{
bytea *string = PG_GE
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> On Mon, 2007-09-24 at 10:02 +0100, Heikki Linnakangas wrote:
>>> How about just using MaxHeapTuplesPerPage? With the default 8K block
>>> size, it's not that much more than 200, but makes the above gripes
>>> completely go aw
Am Montag, 24. September 2007 schrieb Simon Riggs:
> I would personally prefer the verb "monitor" rather than track. The
> chapter in the docs is already called "Monitoring Database Activity".
What the database system does is tracking. Then you use an administrator or
Nagios to monitor the resul
Heikki Linnakangas wrote:
Dave Page wrote:
I get the above error message when creating a database in pgAdmin now:
CREATE DATABASE demo
WITH ENCODING='SQL_ASCII'
TABLESPACE=pg_default;
COMMENT ON DATABASE demo IS 'This is the demo database';
GRANT ALL ON DATABASE demo TO public;
ALTER D
Simon Riggs wrote:
> On Mon, 2007-09-24 at 10:39 +0100, Heikki Linnakangas wrote:
>> Let's keep it simple. Per-table setting would be much more complex and
>> would be something that the DBA would need to calculate and set. If you
>> really do run into this problem, you can just dial down
>> mainte
Dave Page wrote:
> I get the above error message when creating a database in pgAdmin now:
>
> CREATE DATABASE demo
> WITH ENCODING='SQL_ASCII'
>TABLESPACE=pg_default;
> COMMENT ON DATABASE demo IS 'This is the demo database';
> GRANT ALL ON DATABASE demo TO public;
> ALTER DATABASE demo
On Mon, 2007-09-24 at 10:39 +0100, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2007-09-24 at 10:02 +0100, Heikki Linnakangas wrote:
> >> How about just using MaxHeapTuplesPerPage? With the default 8K block
> >> size, it's not that much more than 200, but makes the above gripes
> >> c
I get the above error message when creating a database in pgAdmin now:
CREATE DATABASE demo
WITH ENCODING='SQL_ASCII'
TABLESPACE=pg_default;
COMMENT ON DATABASE demo IS 'This is the demo database';
GRANT ALL ON DATABASE demo TO public;
ALTER DATABASE demo SET search_path=demo;
I understa
On Sun, 2007-09-23 at 12:51 -0400, Tom Lane wrote:
> Personally I would favor
>
> track_activities
> track_counts
I would personally prefer the verb "monitor" rather than track. The
chapter in the docs is already called "Monitoring Database Activity".
Sysadmins know t
Simon Riggs wrote:
> On Mon, 2007-09-24 at 10:02 +0100, Heikki Linnakangas wrote:
>> How about just using MaxHeapTuplesPerPage? With the default 8K block
>> size, it's not that much more than 200, but makes the above gripes
>> completely go away. That seems like the safest option at this point.
>
On Mon, 2007-09-24 at 10:02 +0100, Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > Log Message:
> > ---
> > Reduce the size of memory allocations by lazy vacuum when processing a small
> > table, by allocating just enough for a hardcoded number of dead tuples per
> > page. The curren
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
>> Idle thought here: did anything get done with the idea of decoupling
>> main-table vacuum decisions from toast-table vacuum decisions? vacuum.c
>> comments
>>
>> * Get a session-level lock too. This will protect our access
Alvaro Herrera wrote:
> Log Message:
> ---
> Reduce the size of memory allocations by lazy vacuum when processing a small
> table, by allocating just enough for a hardcoded number of dead tuples per
> page. The current estimate is 200 dead tuples per page.
200 sounds like a badly chosen v
What version readline are you using?
I tried with the latest download, and I get about 200 warnings like:
1>.\src\bin\psql\tab-complete.c(600) : warning C4013: 'completion_matches'
undef
ined; assuming extern returning int
1>.\src\bin\psql\tab-complete.c(600) : warning C4047: '=' : 'char **'
diffe
Hrrm. I wonder how likely that is, but I can see it's a problem.
That said, it's probably not a bad idea to fix it anyway - it would
correspond to setting the permissions on a unix install, which we do.
For the xcopy commansd, it should be easier to just add a /R switch. But
most files are copie
Well, I was checking out from a different cvs server, and had things set
to use CVS EDIT, where everything is read-only by default, until you
issue a cvs edit command.
So many files that aren't built by the build system, but just get copied
as-is, end up read-only.
But it would be true for any fil
53 matches
Mail list logo
