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 database
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 no
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
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 se
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 none-
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
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
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 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
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 miss
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 <[E
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 o
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 pro
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
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 pghacke
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 any
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 ta
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 s
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 be
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 compress
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 p
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| __-
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
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 user/db/pa
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
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
> > 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 impleme
> > 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 impleme
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.
-
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 t
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
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.
>
>
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
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
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
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]
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.
>
> \d would show something like
> \dt [tables] \ds [sequences] \dv [views] ...
That won't work. The actual completion and the view o
> 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 \d providing prompts, and DESCRIBE is a little more
> portable & memorable than \d
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 w
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.1127.0.
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 c
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 permissi
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
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 forgot
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'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 dro
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
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 imagine larger systems with multiple CPUs and m
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 conversatio
(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 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 t
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 fr
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 ye
(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 the
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 ma
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.
>
> >"\D" works though.)
> >
> >Any objections out there?
>
> My only complaint here is being forced to use the 'shift' key on commands
> that will be com
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 mo
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 reposit
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
> > 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 datab
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
"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
archive
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
> > > >
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
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
65 matches
Mail list logo
