Maybe it needs CASCADE/RESTRICT added?
Seems like overkill, considering that this is a very marginal feature.
I'm happy to decree that it works in whichever way is the easiest to
implement.
In that case, it seems to me that it has to be default RESTRICT. If
anything depend on it, it must fail. O
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> The problem appears to be that ALTER TABLE SET WITHOUT OIDS doesn't make
>> the index on the OID column go away.
> Maybe it needs CASCADE/RESTRICT added?
Seems like overkill, considering that this is a very marginal feature.
I'm happy to decr
The problem appears to be that ALTER TABLE SET WITHOUT OIDS doesn't make
the index on the OID column go away.
I don't have a strong opinion on whether to fix this by forcing a drop
of the index or by rejecting the ALTER command. Seems like we have to
do one or the other though.
This is actually ju
Neil Conway <[EMAIL PROTECTED]> writes:
> Attached is a patch for this issue. I've checked with Chris, and this
> patch allows the regression tests to pass on his machine. I also
> updated float8-exp-three-digits expected file, but I wasn't able to
> test these changes (I don't have access to a
Christopher Kings-Lynne wrote:
This has not yet been fixed...
Attached is a patch for this issue. I've checked with Chris, and this
patch allows the regression tests to pass on his machine. I also
updated float8-exp-three-digits expected file, but I wasn't able to
test these changes (I don't hav
Doh - I think I understand now why this is normal behavior - sorry!
Chris
Christopher Kings-Lynne wrote:
What's going on here:
usa=> select user_id from users_users where joindate >= '2004-03-09';
ERROR: column "user_id" does not exist
usa=> select * from shop_orders where user_id in (select u
What's going on here:
usa=> select user_id from users_users where joindate >= '2004-03-09';
ERROR: column "user_id" does not exist
usa=> select * from shop_orders where user_id in (select user_id from
users_users where joindate >= '2004-03-09');
[waits and waits and waits...have to cancel]
^CCan
Josh Berkus wrote:
Syslog support. I'm not sure this is really needed, but a simple patch was
submitted by one user and perhaps that can be reviewed / improved and
applied.
I need it, and am glad to hear there is a patch. Several of my clients use
centralized syslog servers, and do *
Josh Berkus wrote:
Inability to customize thresholds on a per table basis
This hasn't been a big problem for me. I would judge that 80% of my clients
would make no use of this feature.
Ok.
Inability to set default thresholds on a per database basis
This would be much more useful
On Mon, Mar 22, 2004 at 04:50:57PM -0500, Matthew T. O'Connor wrote:
> Could you please explain this better, I don't really understand what the
> problem is. If you want pg_autovacuum to perform a vacuum on a table
> that has had exactly X updates no matter what, you can just run it with
> -V0
I had a suspicion and it was confirmed:
test=# create table oidtest (a int4, unique(oid));
NOTICE: CREATE TABLE / UNIQUE will create implicit index
"oidtest_oid_key" for table "oidtest"
CREATE TABLE
test=# select oid from oidtest;
oid
-
(0 rows)
test=# alter table oidtest set without oids;
This has not yet been fixed...
Chris
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
Attached are the test failures I'm currently getting.
It looks like Neil didn't update expected/float8-small-is-zero.out
for his recent changes (for which, shame on him). Would you get
to
Matthew,
I am replying to the below as a pg_autovacuum user for multiple client
databases. My thoughts:
> Inability to customize thresholds on a per table basis
This hasn't been a big problem for me. I would judge that 80% of my clients
would make no use of this feature.
> Inability to se
Matthew T. O'Connor wrote:
Joe Conway wrote:
This would be *really* nice to have. In my recent case, if
pg_autovacuum could work for say 3 minutes, and then back off for 2
minutes or so while the batch transactions hit, it would be ideal.
I'm not sure what you are suggesting here. As it stands
Matthew T. O'Connor wrote:
Could you please explain this better, I don't really understand what the
problem is. If you want pg_autovacuum to perform a vacuum on a table
that has had exactly X updates no matter what, you can just run it with
-V0 -vX (where X is the vacuum threshold) same thing
Gavin Sherry wrote:
I was initially against the idea of using libpq but its growing on me too.
I think it would be good if the core functions of pg_autovacuum: threshold
algorithms, connection, issuing commands can be (re?)designed such that
not only the backend can link against it but also a str
Joe Conway wrote:
Matthew T. O'Connor wrote:
* Inability to schedule vacuums during off-peak times
This would be *really* nice to have. In my recent case, if
pg_autovacuum could work for say 3 minutes, and then back off for 2
minutes or so while the batch transactions hit, it would be ideal.
Matthew T. O'Connor wrote:
* Inability to customize thresholds on a per table basis
I ran headlong into this one. IMHO fixing this is critical.
* Inability to set default thresholds on a per database basis
* Inability to exclude specific databases / tables from pg_autovacuum
monitoring
These would
--On Montag, März 22, 2004 18:00:55 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
That sounds bogus to me. It's obvious that columns not present in the
view can't be updated through the view --- you simply do not have a way
to name them, so how could you affect them?
What the spec actually says, if
Bernd Helmle <[EMAIL PROTECTED]> writes:
> Currently no SQL spec handy (i will have one soon) ,
BTW, I find that the SQL92 spec is vastly more readable than SQL99,
partly because it's vastly shorter, and partly because the SQL99 authors
seem to have been into unnecessary formalism and obscurantism
Bernd Helmle <[EMAIL PROTECTED]> writes:
> Currently no SQL spec handy (i will have one soon) , i took a look onto
> O'Reillys "SQL in a
> Nutshell", where the WITH CHECK OPTION is defined as follows (translated
> from German):
> Only data that can be read from the specific view can be updat
On Mon, 22 Mar 2004, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > Well this certainly sounds like something that would be easy to do,
> > which appeals to me at least as a first cut. Question: Does this mean
> > that I lose many of the advantages of being "in the backen
Bernd Helmle <[EMAIL PROTECTED]> writes:
> --On Montag, März 22, 2004 16:17:34 -0500 Tom Lane <[EMAIL PROTECTED]>
> wrote:
>> We might need to mark automatically created rules as such, and be
>> prepared to drop them if the user then defines a manually-created rule.
> Not going into deeper detail
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There is no "direct pipe connection" to the stats collector,
> I probably said that wrong, but how do backends get their stats data?
They read it out of a flat file that the stats collector rewrites every
so often.
> Meanin
--On Montag, März 22, 2004 16:17:34 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Bernd Helmle <[EMAIL PROTECTED]> writes:
[...]
We might need to mark automatically created rules as such, and be
prepared to drop them if the user then defines a manually-created rule.
Otherwise we will have backwards-
--On Montag, März 22, 2004 16:48:29 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Gavin Sherry <[EMAIL PROTECTED]> writes:
If the user specifically asked for an updatable view, then they can't
have one. If they didn't specifically ask, they get the usual read only
view.
"Specifically asked" how? A
Tom Lane wrote:
If you aren't a backend then you couldn't safely access shared memory,
including FSM in particular. I see no reason you couldn't use GUC
though. There is no "direct pipe connection" to the stats collector,
except in the output direction which is not what you want, so I'm not
seei
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> regression=# insert into bar values (1);
>> ERROR: cannot insert into a view
> Oh, good. What release fixed this?
[experiments...] 7.1.
regards, tom lane
---(end of broadcast)-
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was thinking we create an updatable view if possible, and throw an
> > error if they try to insert/update/delete into a non-updatable view.
>
> Right.
>
> > Right now we ignore such activity, but that seems wrong.
>
> Nonsense.
>
Thought I would throw out my plans for the coming weeks.
This Wednesday-Friday I am in New York City at the SRA office for
business meetings.
I have already started working on open issues from my mailbox, and I
will continue on those for the next few weeks. There are items that
need cleanup due
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking we create an updatable view if possible, and throw an
> error if they try to insert/update/delete into a non-updatable view.
Right.
> Right now we ignore such activity, but that seems wrong.
Nonsense.
regression=# create view bar as se
Tom Lane wrote:
> Bernd Helmle <[EMAIL PROTECTED]> writes:
> > a) Definition of an updateable view?
>
> > The first thing what i thought about was, what defines a updateable view.
>
> The SQL spec clearly defines the requirements for a view to be
> updateable. It seems sufficient to me to handl
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Well this certainly sounds like something that would be easy to do,
> which appeals to me at least as a first cut. Question: Does this mean
> that I lose many of the advantages of being "in the backend"? That is,
> would pg_autovacuum still b
Alex J. Avriette wrote:
Hi, Matthew. For our uses, we found that pg_autovacuum did not behave
as expected with vacuum_threshold set to 0. For our purposes, we have
a very good idea of how many tuples need to be slurped up over a given
interval, and would like the autovacuum daemon to simply go th
Tom Lane wrote:
From the point of view of the postmaster a GUC-controlled delay would
seem like the best thing. We could discuss having the autovacuum code
try to feed back adjustments in the delay, but remember that one of the
golden virtues for the postmaster proper is simplicity; that translat
Bernd Helmle <[EMAIL PROTECTED]> writes:
> a) Definition of an updateable view?
> The first thing what i thought about was, what defines a updateable view.
The SQL spec clearly defines the requirements for a view to be
updateable. It seems sufficient to me to handle the cases required by
the sp
> > As such, I
> > think that a vacuum backend for a specific database should be forked upon
> > the first connect. Also, the backend might like to try and workout if
> > there are any active backends for its database every so often and if not,
> > perform a final vacuum (if necessary) and exit, so
On Mon, 22 Mar 2004, Bernd Helmle wrote:
> I am currently thinking of updateable views for a possible student research
> project. In this
> case there comes some points to my mind, i want to share with the list.
>
> a) Definition of an updateable view?
The SQL spec. You should definately get a lo
I am currently thinking of updateable views for a possible student research
project. In this
case there comes some points to my mind, i want to share with the list.
a) Definition of an updateable view?
The first thing what i thought about was, what defines a updateable view.
An updateable
view
On Sun, Mar 21, 2004 at 05:32:59PM -0500, Matthew T. O'Connor wrote:
> Lately I have been thinking about the next steps for the pg_autovacuum
> daemon. I have written up a document that describes what I'm planning
> to do next. Please read the attached and response as I would really
> like some
--On Monday, March 22, 2004 13:15:15 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
--On Monday, March 22, 2004 12:49:00 -0500 Tom Lane
<[EMAIL PROTECTED]>=20 wrote:
If you can fix it yourself in a reasonably non-intrusive way, we'll take
the patch ... that
Larry Rosenman <[EMAIL PROTECTED]> writes:
> --On Monday, March 22, 2004 12:49:00 -0500 Tom Lane <[EMAIL PROTECTED]>=20
> wrote:
>> If you can fix it yourself in a reasonably non-intrusive way, we'll take
>> the patch ... that's about the extent of the cooperation you can expect.
> would a dlsym-b
--On Monday, March 22, 2004 12:49:00 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
I really, really, really want to see threads enabled for libpq for this
platform, especially since SCO will be distributing it at some point in
time.
I think very few of the
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I really, really, really want to see threads enabled for libpq for this
> platform, especially since SCO will be distributing it at some point in
> time.
I think very few of the folks on this list will see that as a reason
why they should expend any eff
[EMAIL PROTECTED] wrote:
> On 18 Mar, Tom Lane wrote:
> > Josh Berkus <[EMAIL PROTECTED]> writes:
> >> 1) This is an OSS project. Why not just recruit a bunch of people on
> >> PERFORMANCE and GENERAL to test the 4 different synch methods using real
> >> databases? No test like reality, I say
[EMAIL PROTECTED] writes:
> I could certainly do some testing if you want to see how DBT-2 does.
> Just tell me what to do. ;)
Just do some runs that are identical except for the wal_sync_method
setting. Note that this should not have any impact on SELECT
performance, only insert/update/delete pe
--On Monday, March 22, 2004 12:33:56 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
> One other option is to disable threads on this platform for 7.5 unless
> we find another platforms that need this to use threads. That is the
> direction I will take for the moment. If
On 18 Mar, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
>> 1) This is an OSS project. Why not just recruit a bunch of people on
>> PERFORMANCE and GENERAL to test the 4 different synch methods using real
>> databases? No test like reality, I say
>
> I agree --- that is like
On Sunday 14 March 2004 1:00 pm, Tom Lane wrote:
...
> So it seems fairly likely that the fsync-by-default business is
> indeed a Linux-ism not shared by other Unixen.
Excerpt from the Postfix 2.0.8 README_FILES/LINUX_README file in case
it proves interesting:
-
LINUX syslogd uses
Larry Rosenman wrote:
> > One other option is to disable threads on this platform for 7.5 unless
> > we find another platforms that need this to use threads. That is the
> > direction I will take for the moment. If someone needs a threaded libpq
> > on this platform, then can enable threads, comp
--On Monday, March 22, 2004 09:52:54 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Bruce Momjian wrote:
Larry Rosenman wrote:
> The a.out (not any library) should be linked with -Kpthread (not
> -lpthread).
> This will force libthread to be linked in the right order relative to
> libc, libC,
On Mon, 2004-03-22 at 10:51, Tom Lane wrote:
> > 2.Use a config file. This would require some additional coding to add
> > the required parsing, but is possible.
>
> Personally I like #2. The claim that this requires extra code seems
> bogus to me --- when you are working at the C code level,
On Mon, 2004-03-22 at 04:23, Karel Zak wrote:
> All. It's important do it as backend process. Because libpq has very,
> very limited and slow resources for work with backend stuff.
Agreed.
> The base should be the standard backend with different "main loop" that
> will instead socket chec
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Well, seems like what you have to do is leave it as relation_expr
>> as far as bison is concerned, but test in the C-code action and error
>> out if "*" was specified. (Accepting ONLY seems alright to me.)
> Actually, it occurs to me that the
On Mon, 2004-03-22 at 10:58, Tom Lane wrote:
> Lots of idle processes sitting around is right out, too. Remember that
> each one would eat a backend connection slot. I think we are going to
> have to limit this to *one* process at a time. What that probably means
> is that we successively launch
On Mon, 2004-03-22 at 07:25, Richard Huxton wrote:
> On Monday 22 March 2004 03:36, Matthew T. O'Connor wrote:
> > 1.Store config data inside a special pg_autovacuum table inside
> > existing databases that wants custom settings.
> >
> > 2.Use a config file. This would require some additional co
Gavin Sherry <[EMAIL PROTECTED]> writes:
> One point is this: vacuum() assumes that you are running in a fully
> fledged backend. There'd be a fair bit of work involved in allowing a
> single process to call vacuum() against multiple databases.
Make that "it isn't going to happen".
> As such, I
>
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> There are differing opinions as to the best way to providing these this
> feature. The primary debate is where to save the configuration data. I
> see three options:
> 1.Store config data inside a special pg_autovacuum table inside
> existing
On Mon, 2004-03-22 at 03:36, Gavin Sherry wrote:
> One point is this: vacuum() assumes that you are running in a fully
> fledged backend. There'd be a fair bit of work involved in allowing a
> single process to call vacuum() against multiple databases.
I can't imagine we want to do that.
> As su
Karel Zak <[EMAIL PROTECTED]> writes:
> On Fri, Mar 19, 2004 at 09:54:37AM -0500, Tom Lane wrote:
>> Why? The client-side code doesn't have any real say over the meaning of
>> the data, at least not in psql-class clients. I suppose a client app
>> that tries to interpret the data could get confus
Philip Warner wrote:
> At 03:13 AM 17/03/2004, Bruce Momjian wrote:
> > * Allow pg_dumpall to use non-text output formats
>
> Is anyone working on this?
Nope. It was just added to the TODO list. I am working on having
pg_dump use SET with_default_oids instead of WITH OIDS, and I have
com
Fabien COELHO <[EMAIL PROTECTED]> writes:
>>> More over, I have other ideas for CONTEXT, which should really be a stack.
>> It already is a stack.
> Ok, I agree that there is a "push", but I'm still looking fot the "pop".
> Maybe I missed something, but it seemed to me that strings are appended
>
Bruce Momjian wrote:
> Larry Rosenman wrote:
> > The a.out (not any library) should be linked with -Kpthread (not
> > -lpthread).
> > This will force libthread to be linked in the right order relative to
> > libc, libC, networking libraries, etc.
> >
> > In other words, the entire application ei
Gavin Sherry wrote:
On Sun, 21 Mar 2004, Matthew T. O'Connor wrote:
On Sun, 2004-03-21 at 20:31, Christopher Kings-Lynne wrote:
> > I think these configuration issues will become a lot easier if you make
> > the autovacuum daemon a subprocess of the postmaster (like, say, the
> > checkpoint proces
Hello Hackers,
I had some performance problems with a plpgsql function I developped,
because the function is very costly (it involves querying tables) and the
query optimiser assumed basically that it was an inexpensive function.
I found a workaround, but the problem may worth being adressed:
I
On Monday 22 March 2004 03:36, Matthew T. O'Connor wrote:
> 1. Per Database defaults and Per table Thresholds:
>
> There are differing opinions as to the best way to providing these this
> feature. The primary debate is where to save the configuration data. I
> see three options:
>
> 1.Store con
At 03:13 AM 17/03/2004, Bruce Momjian wrote:
* Allow pg_dumpall to use non-text output formats
Is anyone working on this?
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A
Hello hackers,
> please find attached a quick proof of concept for a 'pg_advisor' schema.
I'm still pushing my agenda, despite lack of reaction on the list;-)
I had time this week-end to improve my current 'pg_advisor'
prototype schema.
This new version is now less a proof of concept and more a
On Mon, Mar 22, 2004 at 02:35:37AM -0500, Matthew T. O'Connor wrote:
> On Sun, 2004-03-21 at 23:00, Bruce Momjian wrote:
> > > > C) Most importantly, I'm not backend hacker. If someone wants to do the
> > > > initial work of getting it running as a backend process, I can take it
> > > > from there
Dear Tom,
> The point is that CONTEXT is essentially a record of "how we got here".
Yes, but for human eyes.
> In a situation where the actual error occurs inside a couple of levels
> of nesting, you want to be able to report the outer queries as well as
> the one that directly caused the error
> > Ok, thanks for the offer to help, but I think I understated things above
> > when I said I'll need a "little" help :-)
> >
>
> I haven't looked at the code but...
>
> > I have a few big picture questions. Once pg_autovacuum is launched as a
> > postmaster sub-process, what changes? That is, c
On Mon, 22 Mar 2004, Matthew T. O'Connor wrote:
> On Sun, 2004-03-21 at 23:00, Bruce Momjian wrote:
> > > > C) Most importantly, I'm not backend hacker. If someone wants to do the
> > > > initial work of getting it running as a backend process, I can take it
> > > > from there. A while ago, Bruc
72 matches
Mail list logo
