On Wed, Jul 27, 2005 at 12:56:15AM -0400, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Could this be platform-specific?
Seems that way. I tried it on HPUX 10.20/HPPA/gcc 2.95.3.
No luck on FreeBSD 4.11-STABLE/i386/gcc 2.95.4. The box that does
have a problem is Solaris
Michael Fuhr wrote:
Can anybody else reproduce the problem?
I couldn't repro it, on x86 / Debian unstable / gcc 3.4.4, with current
CVS sources.
-Neil
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
The target system for my reproduction is on FreeBSD.
Though I sitll cannot get the initdb started one to work the first time
around.
I cannot reproduce the bug on my linux machine, however I cannot test the
full initdb procedure until tomorrow on freebsd.
This error has come up in the last
Hello. I was just wondering, assume we have such tables:
CREATE TABLE data (
foo text,
somename_id integer not null references (somenames)
);
CREATE TABLE somenames (
somename_id serial PRIMARY KEY
somename text NOT NULL
);
And a view:
CREATE someview AS SELECT foo,somename FROM
In the meantime would'nt it be nice to try to understand what happens and
correct it?
I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.
Regards
On Tue, 26 Jul 2005, Larry Rosenman wrote:
Date: 26 Jul 2005 08:52:01 -0500
From: Larry Rosenman
Am Mittwoch, den 27.07.2005, 10:40 +0200 schrieb Dawid Kuroczko:
Hello. I was just wondering, assume we have such tables:
CREATE TABLE data (
foo text,
somename_id integer not null references (somenames)
);
CREATE TABLE somenames (
somename_id serial PRIMARY KEY
somename
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens
and correct it?
I'm a bit afraid that 8.1 is not used on unixware because people
don't have/want the patch installed.
Regards
Let's see what they find, first. They may have a work-around (they
On Tuesday 26 July 2005 16:53, Alvaro Herrera wrote:
On Tue, Jul 26, 2005 at 09:30:20PM +0100, Simon Riggs wrote:
I'd like to suggest altering the syntax of VACUUM so that it is possible
to issue the command VACUUM DATABASE. The keyword DATABASE would be
optional, to allow backward
On Wed, Jul 27, 2005 at 12:19:51AM -0700, Kevin McArthur wrote:
The target system for my reproduction is on FreeBSD.
What version of FreeBSD? What compiler and version? So far I
haven't been able to reproduce the problem on FreeBSD 4.11-STABLE/
i386/gcc 2.95.4.
Though I sitll cannot get the
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens and
correct it?
I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.
All the evidence is that this is a compiler bug. The apparent workaround
On Wed, Jul 27, 2005 at 12:19:51AM -0700, Kevin McArthur wrote:
This error has come up in the last week or so, and my suspicion remains
that its caused by something to do with roles but that could be way wrong.
The FreeBSD machines were confirmed to work as of about a week ago ( i
On Jul 27 2005, Andrew Dunstan wrote:
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens and
correct it?
I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.
All the evidence is that this is a
I cannot repoduce your experience with this bug. No matter what I do,
reconnect session or otherwise, it never returns a proper oid on the newer
cvs vers (I suspect it may be related to the roles update)
Kevin
- Original Message -
From: Michael Fuhr [EMAIL PROTECTED]
To: Kevin McArthur
On Jul 27 2005, Bruce Momjian wrote:
Andrew Dunstan wrote:
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens
and correct it?
I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.
--On tisdag, juli 26, 2005 15.17.57 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman ler@lerctr.org writes:
On Jul 26 2005, Jim C. Nasby wrote:
So the question now is: how do we fix the issue with threaded python?
how do we get libc_r into the mix on FreeBSD 4.11?
A possible
Andrew Dunstan wrote:
ohp@pyrenet.fr wrote:
In the meantime would'nt it be nice to try to understand what happens and
correct it?
I'm a bit afraid that 8.1 is not used on unixware because people don't
have/want the patch installed.
All the evidence is that this is a
On Wed, 27 Jul 2005, Dawid Kuroczko wrote:
Hello. I was just wondering, assume we have such tables:
CREATE TABLE data (
foo text,
somename_id integer not null references (somenames)
);
CREATE TABLE somenames (
somename_id serial PRIMARY KEY
somename text NOT NULL
);
And
On Tue, Jul 26, 2005 at 17:56:42 -0400,
Chris Browne [EMAIL PROTECTED] wrote:
There is evidently Something Strange about the state of stdout when it
is referenced inside a stored procedure.
I suspect this is related to trusted PLs not being able to write files.
It does seem like a problem
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
... what I was wondering about is creating a
'type' that is a rollup for:
- create parent table with int id field and text and indexes
- add RI to base table
- add triggers/views/rules/other glue to make the id field hidden
On 2005-07-27, Michael Fuhr [EMAIL PROTECTED] wrote:
So far the problem does seem to be specific to whatever PL/pgSQL's
is doing, and it affects ROW_COUNT as well as RESULT_OID. I haven't
been able to reproduce the problem with PL/Tcl or with C and SPI.
src/pl/plpgsql/src/pl_exec.c, function
Andrew - Supernews wrote:
On 2005-07-27, Michael Fuhr [EMAIL PROTECTED] wrote:
So far the problem does seem to be specific to whatever PL/pgSQL's
is doing, and it affects ROW_COUNT as well as RESULT_OID. I haven't
been able to reproduce the problem with PL/Tcl or with C and SPI.
Hello,
Just for clarification, will the new integrated autovacuum require that
statistics are on?
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services,
On Wed, Jul 27, 2005 at 12:53:40PM -0700, Joshua D. Drake wrote:
Just for clarification, will the new integrated autovacuum require that
statistics are on?
Yes. Row-level stats too.
--
Alvaro Herrera (alvherre[a]alvh.no-ip.org)
I'm always right, but sometimes I'm more right than other
Changing just the one appears to resolve the oid bug. Should probably talk
to neilc to see why he changed it.
I will pass along a patch for this particular case to -patches shortly
Kevin McArthur
- Original Message -
From: Andrew Dunstan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc:
Folks,
I ran a wal_buffer test series. It appears that increasing the
wal_buffers is indeed very important for OLTP applications, potentially
resulting in as much as a 15% average increase in transaction processing.
What's interesting is that this is not just true for 8.1, it's true for
Did anyone get a chance to think about this? I'd like to fix this for
8.1, but it should also make life easy with the new libpq based ODBC
driver improvements if I can produce an appropriate patch sooner rather
than later!
Regards, Dave.
-Original Message-
From: [EMAIL PROTECTED]
Alvaro Herrera wrote:
On Wed, Jul 27, 2005 at 12:53:40PM -0700, Joshua D. Drake wrote:
Just for clarification, will the new integrated autovacuum require that
statistics are on?
Yes. Row-level stats too.
Great Thanks... Could I get a better explanation of the following:
El Mié 27 Jul 2005 17:24, Alvaro Herrera escribió:
On Wed, Jul 27, 2005 at 12:53:40PM -0700, Joshua D. Drake wrote:
Just for clarification, will the new integrated autovacuum require that
statistics are on?
Yes. Row-level stats too.
Will there be a way to ballance the amount of stats
On Wed, Jul 27, 2005 at 06:05:26PM -0300, Martín Marqués wrote:
El Mié 27 Jul 2005 17:24, Alvaro Herrera escribió:
On Wed, Jul 27, 2005 at 12:53:40PM -0700, Joshua D. Drake wrote:
Just for clarification, will the new integrated autovacuum require that
statistics are on?
Yes.
On Wed, Jul 27, 2005 at 02:07:28PM -0700, Joshua D. Drake wrote:
Great Thanks... Could I get a better explanation of the following:
#autovacuum_vacuum_scale_factor = 0.4 # fraction of rel size before vacuum
#autovacuum_analyze_scale_factor = 0.2 # fraction of rel size before
analyze
On Wed, 27 Jul 2005 13:30:01 -0700
Josh Berkus josh@agliodbs.com wrote:
Folks,
I ran a wal_buffer test series. It appears that increasing the
wal_buffers is indeed very important for OLTP applications, potentially
resulting in as much as a 15% average increase in transaction processing.
El Mié 27 Jul 2005 18:23, Alvaro Herrera escribió:
On Wed, Jul 27, 2005 at 06:05:26PM -0300, Martín Marqués wrote:
Will there be a way to ballance the amount of stats the autovacuum gets?
Something like the analyze parameters that the contrib version has, but
integrated in
On Wed, 2005-07-27 at 13:30 -0700, Josh Berkus wrote:
I ran a wal_buffer test series. It appears that increasing the
wal_buffers is indeed very important for OLTP applications, potentially
resulting in as much as a 15% average increase in transaction processing.
What's interesting is
Neil (or anyone else with an opinion),
I'm finding several uses in the planner for some new List primitives
defined as below. I'd like to push these into list.c, but before that,
has anyone got any serious objections? How about suggestions for better
names?
regards, tom
On Wed, Jul 27, 2005 at 06:35:31PM -0300, Martín Marqués wrote:
El Mié 27 Jul 2005 18:23, Alvaro Herrera escribió:
On Wed, Jul 27, 2005 at 06:05:26PM -0300, Martín Marqués wrote:
Will there be a way to ballance the amount of stats the autovacuum gets?
Something like the analyze
On Tue, 2005-07-26 at 19:15 -0400, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
We should run tests with much higher wal_buffers numbers to nullify the
effect described above and reduce contention. That way we will move
towards the log disk speed being the limiting factor, patch or
On Wed, Jul 27, 2005 at 01:20:29PM -0700, Kevin McArthur wrote:
Changing just the one appears to resolve the oid bug. Should probably talk
to neilc to see why he changed it.
Initializing isnull to false in exec_stmt_getdiag() appears to fix
the bug on my Solaris 9 box as well. I'd guess the
Simon,
I guess I'd be concerned that the poor bgwriter can't do all of this
work. I was thinking about a separate log writer, so we could have both
bgwriter and logwriter active simultaneously on I/O. It has taken a
while to get bgwriter to perform its duties efficiently, so I'd rather
not
Alvaro,
Also, somebody (Rod Taylor I think) proposed changed the variable names
to
vacuum_auto_vacuum_scale_factor
vacuum_auto_analyze_scale_factor
I see what Rod's getting at, but I find that version of the option less
readable ...
--
--Josh
Josh Berkus
Aglio Database Solutions
San
On Wed, 2005-07-27 at 00:07 -0400, Robert Treat wrote:
On Tuesday 26 July 2005 16:53, Alvaro Herrera wrote:
On Tue, Jul 26, 2005 at 09:30:20PM +0100, Simon Riggs wrote:
I'd like to suggest altering the syntax of VACUUM so that it is possible
to issue the command VACUUM DATABASE. The
SCO is seeing the following failure without -O, but no failure with -O:
The sanity_check diffs show:
*** ./expected/sanity_check.out Wed Jul 27 17:58:12 2005
--- ./results/sanity_check.out Wed Jul 27 18:09:41 2005
***
*** 17,22
--- 17,24
circle_tbl | t
Larry Rosenman ler@lerctr.org writes:
SCO is seeing the following failure without -O, but no failure with -O:
*** ./expected/sanity_check.out Wed Jul 27 17:58:12 2005
--- ./results/sanity_check.out Wed Jul 27 18:09:41 2005
***
*** 17,22
--- 17,24
circle_tbl
Sounds plausible.
Can anyone comment on whether the other instances of isnull=false being
removed need to be reset to =false
Kevin McArthur
- Original Message -
From: Michael Fuhr [EMAIL PROTECTED]
To: Kevin McArthur [EMAIL PROTECTED]
Cc: Andrew Dunstan [EMAIL PROTECTED]; [EMAIL
On Wed, Jul 27, 2005 at 11:41:24PM +0100, Simon Riggs wrote:
Forgive me if this is wrong, but I took that Alvaro was applying a
reductio ad absurdum argument (i.e. taking the piss). I laughed
heartily at the thought of LAZY becoming a PostgreSQL keyword.
Ah, well, actually you are wrong, I
Why does the sanity check test start with a VACUUM? Why not a VACUUM
FULL?
--
Alvaro Herrera (alvherre[a]alvh.no-ip.org)
Los románticos son seres que mueren de deseos de vida
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
On Mon, 25 Jul 2005, Jeffrey W. Baker wrote:
On Mon, 2005-07-25 at 19:08 -0300, Marc G. Fournier wrote:
On Mon, 25 Jul 2005, Jeffrey W. Baker wrote:
On Mon, 2005-07-25 at 18:11 -0300, Marc G. Fournier wrote:
Just curious as to whether or not a warning or something should be issued
in a
On Wed, 27 Jul 2005, Tom Lane wrote:
Neil (or anyone else with an opinion),
I'm finding several uses in the planner for some new List primitives
defined as below. I'd like to push these into list.c, but before that,
has anyone got any serious objections? How about suggestions for better
Marc,
Basically, from how everyone has explained it, the ORDER BY will be done
after all the JOINs are done, and the product of the joins are
complete ... for it to be performed on a field not in the SELECT field
clause, then those fields have to be loaded into memory, *then*
ORDERed, and
On Wed, Jul 27, 2005 at 06:01:21PM -0400, Tom Lane wrote:
Neil (or anyone else with an opinion),
I'm finding several uses in the planner for some new List primitives
defined as below. I'd like to push these into list.c, but before that,
has anyone got any serious objections? How about
Hackers,
This is a list of things people mentioned as interesting to do for
vacuum/autovacuum, during the last autovacuum discussion thread. Some
of them are wishful thinking, others are doable.
Neil, Gavin: both of you mentioned that you didn't like autovacuum as a
long term solution. May I
David Fetter [EMAIL PROTECTED] writes:
How about list_push for both of these?
list_push to me would connote the functionality of lappend, ie,
unconditionally add the item to the list.
regards, tom lane
---(end of
Dave Page wrote:
Did anyone get a chance to think about this? I'd like to fix this for
8.1, but it should also make life easy with the new libpq based ODBC
driver improvements if I can produce an appropriate patch sooner rather
than later!
I have thought about it and it needs to be addressed
Gavin Sherry wrote:
list_add() doesn't really describe what it does.
I agree -- the functionality itself is fine, of course, but it would be
nice to have a better name.
I was thinking either list_cond_add() or list_merge().
What about list_append_distinct()? (And
On Wed, 27 Jul 2005, Alvaro Herrera wrote:
Hackers,
This is a list of things people mentioned as interesting to do for
vacuum/autovacuum, during the last autovacuum discussion thread. Some
of them are wishful thinking, others are doable.
Neil, Gavin: both of you mentioned that you didn't
Mark,
I'm starting to get results with dbt2 on a 4-way opteron system and
wanted to share what I've got so far since people have told me in the
past that this architecture is more interesting than the itanium2 that
I've been using.
This 4-way has 8GB of memory and four Adaptec 2200s
Neil Conway [EMAIL PROTECTED] writes:
I agree -- the functionality itself is fine, of course, but it would be
nice to have a better name.
Those were just the first names that came to mind, and of course the
reason I asked is that I felt they could be improved upon...
I was thinking either
On Thu, Jul 28, 2005 at 11:42:22AM +1000, Gavin Sherry wrote:
On Wed, 27 Jul 2005, Alvaro Herrera wrote:
* Change how we track the need to vacuum
I don't really think the use of row level stats are the best
indicator for a need to vacuum. I wonder if we could keep a
On Wed, Jul 27, 2005 at 07:32:34PM -0700, Josh Berkus wrote:
Mark,
I'm starting to get results with dbt2 on a 4-way opteron system and
wanted to share what I've got so far since people have told me in the
past that this architecture is more interesting than the itanium2 that
I've been
I have a situation where i need to select a couple of rows from an
inherited table
collection. The statement I'm using is:
SELECT * FROM parent NATURAL JOIN interesting
where interesting is a 1 column temporary table with the primary key's
of the rows
I'm interested in.
All the child tables
Tom Lane wrote:
How about list_append_distinct and list_concat_distinct?
Those names are fine with me.
-Neil
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
60 matches
Mail list logo