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_GETARG_TEXT_P(0);
Is this
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
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
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 **'
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
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 to the
*
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 current estimate
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.
It
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 their
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
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
completely
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 SET
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
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
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 results of
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 away. That seems
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 =
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
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
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'
double
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
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 tracking.
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
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 names
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
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
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 right
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 place
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:
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 the
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 above gripes
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
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, pl and
all. Or
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 so we
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
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 functions are
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 now too, it's
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.
This is
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 who
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 agree with that; we
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 earlier
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).
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.
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 issue
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
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 seem to
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
-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.
Are we
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: [HACKERS]
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');
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 out
the meaningless
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,
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 some
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 or
54 matches
Mail list logo
