On Wed, 2005-07-27 at 19:09 -0400, Alvaro Herrera wrote:
> 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
On Wed, 27 Jul 2005, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > I ran across this yesterday on HEAD:
>
> > template1=# grant select on foo, foo to swm;
> > ERROR: tuple already updated by self
>
> Seems to fail similarly in every version back to 7.2; probably further,
> but th
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
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 use
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'
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
>
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 eith
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 co
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 d
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 list_append_all_distinct(
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 address
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 broadcast)-
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 as
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
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
> clause, then those fields have to be "loaded into memory", *then*
> ORDERed, and
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 bette
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 case
Why does the sanity check test start with a VACUUM? Why not a VACUUM
FULL?
--
Alvaro Herrera ()
"Los románticos son seres que mueren de deseos de vida"
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.
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,
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]>;
"Larry Rosenman" 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 | t
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
fast_em
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. T
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
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
> n
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
On Tue, 2005-07-26 at 19:15 -0400, Tom Lane wrote:
> Josh Berkus 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 no patc
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 an
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, 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
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 post
On Wed, 27 Jul 2005 13:30:01 -0700
Josh Berkus 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.
> What's i
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, 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?
> >
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
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:
#autovacuum_vac
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]
> [
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
8.0
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]>
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 ()
"I'm always right, but sometimes I'm more right than other times."
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, Share
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.
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, funct
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 hid
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 probl
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
>
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 t
--On tisdag, juli 26, 2005 15.17.57 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman 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 compromise is to a
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 install
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 McAr
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
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
> rein
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
for
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
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 co
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 (
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
>s
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
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 da
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
60 matches
Mail list logo
