On 10 Dec 2002 at 0:56, Tom Lane wrote:
Dan Langille [EMAIL PROTECTED] writes:
Is the process documented? Any set procedure? Who knows how to do
it?
Er ... nope, nope, the core bunch ...
Sounds like we need to do a brain dump then. I just happen to have
some equipment left over from
On Fri, 2002-11-29 at 07:19, Shridhar Daithankar wrote:
On 29 Nov 2002 at 7:59, Matthew T. O'Connor wrote:
On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
On 28 Nov 2002 at 10:45, Tom Lane wrote:
This is almost certainly a bad idea. vacuum is not very
Dan Langille [EMAIL PROTECTED] writes:
--- for example: Marc owns, runs, and pays for the
postgresql.org servers.
Is the cvs repo mirrored?
Anyone running cvsup would have a complete copy of the source CVS,
I believe. It would be more troubling to reconstruct the mailing list
archives; I'm
On 10 Dec 2002 at 9:34, Tom Lane wrote:
Dan Langille [EMAIL PROTECTED] writes:
--- for example: Marc owns, runs, and pays for the
postgresql.org servers.
Is the cvs repo mirrored?
Anyone running cvsup would have a complete copy of the source CVS, I
believe. It would be more
On 10 Dec 2002 at 9:42, Rod Taylor wrote:
Perhaps a more appropriate rule would be 1 AVD per tablespace? Since
PostgreSQL only has a single tablespace at the moment
Sorry I am talking without doing much of it(Stuck to windows for job) But
actually when I was talking with Matthew offlist,
Dan Langille writes:
On 10 Dec 2002 at 9:34, Tom Lane wrote:
Anyone running cvsup would have a complete copy of the source CVS, I
believe. It would be more troubling to reconstruct the mailing list
archives; I'm not sure that those are mirrored anywhere
Do you mean the repository, or
On Tue, 10 Dec 2002, Tom Lane wrote:
Dan Langille [EMAIL PROTECTED] writes:
--- for example: Marc owns, runs, and pays for the
postgresql.org servers.
Is the cvs repo mirrored?
Anyone running cvsup would have a complete copy of the source CVS,
I believe. It would be more troubling to
Hi, if I may add to the wishlist for 7.4 in order of importance. Some items
may have been mentioned or disputed already but I think they are quite
important:
1. Avoid needing REINDEX after large insert/deletes or make REINDEX not use
exclusive lock on table.
2. Automate VACUUM in background and
On Fri, 2002-11-29 at 06:59, Matthew T. O'Connor wrote:
On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
On 28 Nov 2002 at 10:45, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
interesting thought. I think this boils down to how many knobs do we
need to
Not sure what you mean by that, but it sounds like the behaviour of my AVD
(having it block until the vacuum command completes) is fine, and perhaps
preferrable.
I can easily imagine larger systems with multiple CPUs and multiple disk
and card bundles to support multiple databases.
On Mon, 2002-12-09 at 23:12, Philip Warner wrote:
At 05:13 PM 9/12/2002 -0500, Tom Lane wrote:
Seems like a fine idea to me.
Ditto.
\Dsomething works though.)
Any objections out there?
My only complaint here is being forced to use the 'shift' key on commands
that will be common.
(crossposting to hackers)
On Tuesday 10 December 2002 00:47, Tom Lane wrote:
In the next protocol version update (hopefully 7.4) I would like to see
the basic version string (eg, "7.3.1" or "7.4devel") delivered to the
client automatically during connection startup and then
Ian Barwick [EMAIL PROTECTED] writes:
Sounds good to me. Is it on the todo-list? (Couldn't see it there).
Probably not; Bruce for some reason has resisted listing protocol change
desires as an identifiable TODO category. There are a couple of threads
in the pghackers archives over the last year
Ian Barwick writes:
On Tuesday 10 December 2002 00:47, Tom Lane wrote:
In the next protocol version update (hopefully 7.4) I would like to see
the basic version string (eg, 7.3.1 or 7.4devel) delivered to the
client automatically during connection startup and then available from a
On Tuesday 10 December 2002 00:24, Justin Clift wrote:
RPM's SRPM's
- Co-ordinate with Lamar to have these ready before the general
announcement?
As I am merely a volunteer in this, the availability of RPMs is directly
impacted by my workload. There are several times during the year that
(no followup to [EMAIL PROTECTED], getting a little OT there)
On Tuesday 10 December 2002 16:54, Lee Kindness wrote:
Ian Barwick writes:
Something along the lines of
char *PQversion(const PGconn *conn) ?
Probably:
int PQversion(const PGconn *conn)
On Tue, 2002-12-10 at 09:36, Stephen L. wrote:
6. Compression between client/server interface like in MySQL
Mammoth is supposed to be donating their compression efforts back to
this project, or so I've been told. I'm not exactly sure of their
time-line as I've slept since my last conversation
Would it be possible to make compression an optional thing, with the default
being off?
I'm in a position that many others may be in where the link between my app
server and my database server isn't the bottleneck, and thus any time spent
by the CPU performing compression and decompression tasks
I've been looking at the recently-committed ALTER DOMAIN patch, and I
think it's got some serious if not fatal problems. Specifically, the
approach to adding/dropping constraints associated with domains doesn't
work.
1. Insufficient locking, guise 1: there's no protection against someone
else
On Tue, 2002-12-10 at 12:00, Greg Copeland wrote:
On Tue, 2002-12-10 at 08:42, Rod Taylor wrote:
Not sure what you mean by that, but it sounds like the behaviour of my AVD
(having it block until the vacuum command completes) is fine, and perhaps
preferrable.
I can easily
Dan Langille wrote:
But if you want to try to document the process better, there are some
details written down already (eg, src/tools/RELEASE_CHANGES) and I'm
sure Marc and Bruce would cooperate in writing down more.
That's a good start. It looks like a list of things easily forgotten
On Tue, 2002-12-10 at 11:25, Al Sutton wrote:
Would it be possible to make compression an optional thing, with the default
being off?
I'm not sure. You'd have to ask Command Prompt (Mammoth) or wait to see
what appears. What I originally had envisioned was a per database and
user permission
On 10 Dec 2002, Rod Taylor wrote:
Not sure what you mean by that, but it sounds like the behaviour of my AVD
(having it block until the vacuum command completes) is fine, and perhaps
preferrable.
I can easily imagine larger systems with multiple CPUs and multiple disk
and card
With this pg_hba.conf (line numbers from vi, of course):
48 # TYPE DATABASEUSERIP-ADDRESS IP-MASK METHOD 49
50 local all all ident
sameuser
51 hostall 127.0.0.1
On Tue, 2002-12-10 at 12:39, Tom Lane wrote:
I've been looking at the recently-committed ALTER DOMAIN patch, and I
think it's got some serious if not fatal problems. Specifically, the
approach to adding/dropping constraints associated with domains doesn't
work.
1. Insufficient locking,
Greg Copeland wrote:
On Tue, 2002-12-10 at 11:25, Al Sutton wrote:
Would it be possible to make compression an optional thing, with the default
being off?
I'm not sure. You'd have to ask Command Prompt (Mammoth) or wait to see
what appears. What I originally had envisioned was a per
Hi,
I am doing some experiments on dead tuples, I am looking of reusing the
dead tuples apace in a particular page during the Update.This patch
is meant for the tables
which are heavily updated to avoid vacuum very frequently.By using it
will arrest the size of
table for heavily updated
At 01:25 AM 10/12/2002 -0500, Tom Lane wrote:
Let's
get a bit realistic on the ease-of-typing arguments here.
It's a fair cop, but don't forget the memory argument as well - I did say
I
was happy with \dtab providing prompts, and DESCRIBE is a little more
portable memorable than
Alvaro Herrera writes:
Would it work to make \d tab-completable in a way that showed both the
commands that are available and the objects they describe? e.g.
\dtab would show something like
\dt [tables] \ds [sequences] \dv [views] ...
That won't work. The actual completion and the view of
Rod Taylor [EMAIL PROTECTED] writes:
2. Insufficient locking, guise 2: there's no protection against someone
else adding a column or table while you're processing an ALTER DOMAIN,
either. This means that constraint checks will be missed. Example:
Locking the entry in pg_type doesn't prevent
On Tue, 2002-12-10 at 22:56, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
2. Insufficient locking, guise 2: there's no protection against someone
else adding a column or table while you're processing an ALTER DOMAIN,
either. This means that constraint checks will be missed.
Christopher Kings-Lynne writes:
We could do DESCRIBE commands as well. Also, what happened to the
INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that?
What happened to it?
Ooops. Yeah, let's get this in. Where should I put it?
--
Peter Eisentraut [EMAIL PROTECTED]
Janardhan [EMAIL PROTECTED] writes:
Does it breaks anythings by overwriting the dead tuples ?.
Yes. You cannot do that unless you've first removed index entries
pointing at the dead tuples --- and jumped through the same locking
hoops that lazy vacuum does while removing index entries.
Rod Taylor [EMAIL PROTECTED] writes:
On Tue, 2002-12-10 at 22:56, Tom Lane wrote:
relation's pg_class row. We have no such locks on types at present,
but I think it may be time to invent 'em.
I'd be happy to use them once created.
I think you misunderstood me ;=) ... that was a
At 03:54 PM 9/12/2002 -0500, Tom Lane wrote:
I have some uncommitted patches concerning the FSM management heuristics
from Stephen Marshall, which I deemed too late/risky for 7.3, but we
should get something done for 7.4. Anyone interested in playing around
in this area?
I'd be interested in
Tom Lane wrote:
Janardhan [EMAIL PROTECTED] writes:
Does it breaks anythings by overwriting the dead tuples ?.
Yes. You cannot do that unless you've first removed index entries
pointing at the dead tuples --- and jumped through the same locking
hoops that lazy vacuum
Janardhan [EMAIL PROTECTED] writes:
if i am not wrong while updating a tuple, we are also creating a new
index entry .
Yes.
so if the
tuple is dead then the index entry pointing it also a dead index tuple.
Yes.
so even if dead index tuple is not
removed then also it should not break
Done.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
I see the problem with the line number here. I will work on a fix now.
Thanks.
---
Oliver Elphick wrote:
With this pg_hba.conf (line numbers from vi, of course):
48 # TYPE DATABASEUSERIP-ADDRESS
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
That's a pain. Is there no way for config.guess to tell the difference
between your system and the -STABLE versions?
As I remember, the issue is that the only info is in a system header
file.
This is a bit of a kluge, but what about
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
That's a pain. Is there no way for config.guess to tell the difference
between your system and the -STABLE versions?
As I remember, the issue is that the only info is in a system header
file.
This is a bit of
Peter Eisentraut [EMAIL PROTECTED] writes:
Christopher Kings-Lynne writes:
We could do DESCRIBE commands as well. Also, what happened to the
INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that?
What happened to it?
Ooops. Yeah, let's get this in. Where should I put it?
On Tue, 2002-12-10 at 13:38, Bruce Momjian wrote:
I haven't heard anything about them contributing it. Doesn't mean it
will not happen, just that I haven't heard it.
This was in non-mailing list emails that I was told this by Joshua Drake
at Command Prompt. Of course, that doesn't have to
Yes, the issue was that give our TODO list, compressed transfer wasn't
very high, and it was unknown how valuable it would be. However, if it
were contributed, we could easily test its value with little work on our
part and include the code if it were a win.
We could do DESCRIBE commands as well. Also, what happened to the
INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that?
What happened to it?
Ooops. Yeah, let's get this in. Where should I put it?
I wouldn't mind having a look at the patch. Where do you implement this
We could do DESCRIBE commands as well. Also, what happened to the
INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that?
What happened to it?
Ooops. Yeah, let's get this in. Where should I put it?
I wouldn't mind having a look at the patch. Where do you implement this
On Tue, 2002-12-10 at 13:09, scott.marlowe wrote:
On 10 Dec 2002, Rod Taylor wrote:
Perhaps a more appropriate rule would be 1 AVD per tablespace? Since
PostgreSQL only has a single tablespace at the moment
But Postgresql can already place different databases on different data
I have added the following TODO item on protocol changes:
* Wire Protocol Changes
o Show transaction status in psql
o Allow binding of query parameters, support for prepared queries
o Add optional textual message to NOTIFY
o Remove hard-coded limits on
OK, seeing that we don't have a third number, do people want me to
increment the interface numbers for 7.3.1, or just wait for the
increment in 7.4?
---
Peter Eisentraut wrote:
Tom Lane writes:
It is not real clear to
At 06:36 PM 10/12/2002 -0500, Bruce Momjian wrote:
do people want me to
increment the interface numbers for 7.3.1
I'd like it because I have to support build against multiple versions.
Philip Warner|
Seems like a mistake was made. Let's (don't ya love how that sounds
like I'm actually involved in the fix? ;) fix it sooner rather than
later.
Just curious, after a release, how come the numbers are not
automatically bumped to ensure this type thing gets caught sooner rather
than later? Is it
Without getting into too many details, why not send toast data to
non-local clients? Seems that would be the big win. The data is
already compressed, so the server wouldn't pay cpu time to recompress
anything. And since toast data is relatively large anyway, it's the
stuff you'd want to
This has been brought up a couple of times now. Feel free to search the
old archives for more information. IIRC, it would of made the
implementation more problematic, or so I think it was said.
When I originally brought the topic (compression) up, it was not well
received. As such, it may of
Greg Copeland wrote:
Seems like a mistake was made. Let's (don't ya love how that sounds
like I'm actually involved in the fix? ;) fix it sooner rather than
later.
Just curious, after a release, how come the numbers are not
automatically bumped to ensure this type thing gets caught sooner
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Copeland wrote:
Is it possible to automate this as part of the build
process so that they get grabbed from some version information during
the build?
Version bump is one of the few things we do at the start of
development.
The real problem here
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Copeland wrote:
Is it possible to automate this as part of the build
process so that they get grabbed from some version information during
the build?
Version bump is one of the few things we do at the start of
development.
I have bumped minor versions for 7.3 and 7.4. If we decide to do
something different later, fine, but this way we will not forget to have
some update for 7.3.
---
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian
Rod Taylor wrote:
relation's pg_class row. We have no such locks on types at present,
but I think it may be time to invent 'em.
I'd be happy to use them once created.
Thanks again for the help.
Where does that leave the patch _until_ they are created?
--
Bruce Momjian
Bruce Momjian [EMAIL PROTECTED] writes:
Where does that leave the patch _until_ they are created?
I'd say it's under death sentence unless fixed before 7.4 release.
I don't want to back it out in toto right now, because that will
interfere with other edits I'm in process of making (and also Rod
Tom Lane wrote:
Ian Barwick [EMAIL PROTECTED] writes:
Sounds good to me. Is it on the todo-list? (Couldn't see it there).
Probably not; Bruce for some reason has resisted listing protocol change
desires as an identifiable TODO category. There are a couple of threads
in the pghackers
Can we free only the plans we want to free in geqo? I don't mind having
a different free method in geqo vs. the rest of the optimizer.
---
Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
[ GEQO doesn't work anymore
Bruce Momjian [EMAIL PROTECTED] writes:
Can we free only the plans we want to free in geqo? I don't mind having
a different free method in geqo vs. the rest of the optimizer.
GEQO calls the rest of the optimizer, and the space that we're
worried about is almost all allocated in the rest of the
I'd like to show/register interest.
I can see it being very useful when combined with replication for situations
where the replicatiant databases are geographically seperated (i.e. Disaster
Recover sites or systems maintaining replicants in order to reduce the
distance from user to app to
OK, I wonder if adding -ldl will help. You need to link to the library
containing the ldopen function.
---
Shibashish wrote:
Thanks for the help. I edited the src/makefiles/Makefile.sco and removed
the export. But the
64 matches
Mail list logo
