On 26 Aug 2002 at 14:46, Sir Mordred The Traitor wrote:
> [snip]
> static int recv_and_check_password0(Port *port) {
> int32 len;
> char *buf;
>
> if (pq_getint(&len, 4) == EOF)
> return STATUS_EOF;
> len -= 4;
> buf = palloc(len); /* len is taken from
On 3 Sep 2002 at 8:55, Mario Weilguni wrote:
> I know everyone is busy with the 7.3beta, but maybe this is something to think of
>before releasing the beta. Currently VACUUM will vacuum every table, but sometimes
> it's desireable to leave tables untouched because the're mostly static or protoco
On 3 Sep 2002 at 15:14, Christopher Kings-Lynne wrote:
> > Personally I would prefer to have a trigger on a metadata table
> > where I could
> > trigger vacuuming a particular table each n number of
> > transactions(Oh it would
> > be great if that vacuum runs in background not blocking meta data
On 3 Sep 2002 at 9:36, Mario Weilguni wrote:
> That is not really practicable, one datebase has 107 tables, and making a
> cron job
> with 107 vacuum calls is completly out of question and very error prone
> anyway.
That's correct.. What are the possible alternatives? Either backend has to
suppo
On 3 Sep 2002 at 15:39, Christopher Kings-Lynne wrote:
> > Actually that's what I did. Update global transaction counter
> > than trigger the
> > vacuum from a spare thread.
> >
> > but having it in DB has advantages of centralisation. It's just a
> > good to have
> > kind of thing..
>
> Care t
On 31 Aug 2002 at 5:28, Zhicong Leo Liang wrote:
> Hi all,
> Just briefly describe my problem.
> I have two tables.
> create table A(
>a1 serial primary key,
>a2 varchars(10)
that should be varchar..
> );
> create table B(
> b1 integer primary key,
> b2 Integer,
>
On 3 Sep 2002 at 9:49, Tom Lane wrote:
> In terms of what might happen for 7.4 or beyond, what I'd personally
> like to see is some "auto vacuum" facility that would launch background
> vacuums automatically every so often. This could (eventually) be made
> self-tuning so that it would vacuum he
On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
> OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
>
> I used the same HISTORY categories Peter made in 7.2. I liked them.
>
> Please review the HISTORY file. I am sure there are improvements that
> can be made.
Some minor s
Hi all,
One of my friends is evaluating postgres for large databases. This is a select
intensive application which is something similar to data-warehousing as far as
I can see.
The data is 150GB in flat files so would swell to 200GB+ with indexes.
Is anybody running that kind of site? Any url
On 17 Sep 2002 at 16:11, Christopher Kings-Lynne wrote:
> > What I can't understand is the attitude of some people here. Yes,
> > Microsoft are evil, but the bottom line is, millions of people use
> > Windows. Just look at the number of downloads for pgAdmin (shown at
> > http://www.pgadmin.org/d
On 19 Sep 2002 at 11:19, Johnson, Shaunn wrote:
>
> --howdy:
> --not that the process is doing a lot or taking up
> --a lot of resources, it's just something
> --that i allow the users to kill and then
> --it get's passed to me for correction if the
> --simple 'kill ' thing doesn't work.
> --wha
On 19 Sep 2002 at 11:49, Tom Lane wrote:
> "Shridhar Daithankar" <[EMAIL PROTECTED]> writes:
> > I guess a backend should terminate as if connection is closed. What say?
>
> No.
>
> It will terminate when it tries to read the next query from the cl
On 20 Sep 2002 at 16:33, Justin Clift wrote:
> Hi everyone,
>
> Have gotten a new PostgreSQL utility together called "pg_autotune" that
> load tests using Tatsuo's pgbench code over multiple-iterations,
> attempting to determine decent buffer settings for a specified client
> load.
>
> It's mor
Hi all,
While testing for large databases, I am trying to load 12.5M rows of data from
a text file and it takes lot longer than mysql even with copy.
Mysql takes 221 sec. v/s 1121 sec. for postgres. For postgresql, that is around
11.5K rows per second. Each tuple has 23 fields with fixed lengt
On 20 Sep 2002 at 21:22, Shridhar Daithankar wrote:
> Mysql takes 221 sec. v/s 1121 sec. for postgres. For postgresql, that is around
> 11.5K rows per second. Each tuple has 23 fields with fixed length of around 100
> bytes
>
> I wrote a programs which does inserts in batches b
On 20 Sep 2002 at 10:26, Jonah H. Harris wrote:
> Also, did you disable fsync?
Aarrrgggh.. If that turns out to be culprit, I will kill him..;-)
Problem is I can't see postgresql.conf nor can access his command history and
he has left for the day..
I will count that in checklist but this is p
On 20 Sep 2002 at 10:14, Jonah H. Harris wrote:
> Are you using copy within a transaction?
No. Will that help? I can try. But the utility I wrote, I could insert say 10K
records in a transaction. Copy seems to be doing it all in one transaction. I
don't get any value for select count(*) in ano
On 20 Sep 2002 at 10:27, Mike Benoit wrote:
> On Fri, 2002-09-20 at 08:52, Shridhar Daithankar wrote:
>
> > Besides there is issue of space. Mysql takes 1.4GB space for 1.2GB text data
> > and postgresql takes 3.2GB of space. Even with 40 bytes per row overhead
> >
Hi all,
I just submitted a project to GBorg. I got it submitted and it told me that
GBorg staff would be back to me after review.
I would love to have a check box on project registration page which asks
whether you have some code to submit or not.
Because in my case I have some..;-)
TIA..
B
On 20 Sep 2002 at 18:41, Nigel J. Andrews wrote:
> On Fri, 20 Sep 2002, Shridhar Daithankar wrote:
>
> > In select test where approx. 15 rows where reported with query on index field,
> > mysql took 14 sec. and psotgresql took 17.5 sec. Not bad but other issues
> > ecl
Hello All,
I have written a small daemon that can automatically vacuum PostgreSQL
database, depending upon activity per table.
It sits on top of postgres statistics collector. The postgres installation
should have per row statistics collection enabled.
Features are,
* Vacuuming based on acti
On 23 Sep 2002 at 14:50, Lee Kindness wrote:
> Shridhar,
>
> Might be useful to add a .tag.gz to the downloads, so people do not
> have to use CVS to take a look.
There is a development snapshot..
Bye
Shridhar
--
In most countries selling harmful things like drugs is punishable.Then howcome
On 23 Sep 2002 at 13:28, Matthew T. O'Connor wrote:
> On Monday 23 September 2002 09:43 am, Shridhar Daithankar wrote:
> > Hello All,
> >
> > I have written a small daemon that can automatically vacuum PostgreSQL
> > database, depending upon activity per tab
On 24 Sep 2002 at 8:42, Mario Weilguni wrote:
> Am Dienstag, 24. September 2002 08:16 schrieb Shridhar Daithankar:
> IMO there are still several problems with that approach, namely:
> * every database will get "polluted" with the autovacuum table, which is undesired
I agre
On 25 Sep 2002 at 1:10, Matthew T. O'Connor wrote:
> > It doesn't have to make its way into the postgresql daemon itself -- in
> fact since some people like tuning the vacuuming, it makes more sense to
> make this a daemon. No, my suggestion is simple that some sort of
> auto-vacuumer be compiled
Hello all,
Some time back I posted a query to build a site with 150GB of database. In last
couple of weeks, lots of things were tested at my place and there are some
results and again some concerns.
This is a long post. Please be patient and read thr. If we win this, I guess we
have a good m
On 26 Sep 2002 at 14:05, Shridhar Daithankar wrote:
> Some time back I posted a query to build a site with 150GB of database. In last
> couple of weeks, lots of things were tested at my place and there are some
> results and again some concerns.
> 2) Creating index takes huge am
On 26 Sep 2002 at 10:51, [EMAIL PROTECTED] wrote:
> Hi,
> it seems you have to cluster it, I don't think you have another choise.
Hmm.. That didn't occur to me...I guess some real time clustering like usogres
would do. Unless it turns out to be a performance hog..
But this is just insert a
On 26 Sep 2002 at 11:50, Mario Weilguni wrote:
> >Well the test runs were for 10GB of data. Schema is attached. Read in fixed
> >fonts..Last nullable fields are dummies but may be used in fututre and
> varchars
> >are not acceptable(Not my requirement). Tuple size is around 100 bytes..
> >The i
On 26 Sep 2002 at 12:28, Michael Paesold wrote:
> But why is performance so much degrading? After 1 updates
> on a row, the row seems to be unusable without vacuum! I hope
> the currently discussed autovacuum daemon will help in such a
> situation.
Let mw know if it works. Use CVS BTW.. I am
On 26 Sep 2002 at 11:17, Mario Weilguni wrote:
> On 26 Sep 2002 at 14:05, Shridhar Daithankar wrote:
> > Some time back I posted a query to build a site with 150GB of database. In
> last
> > couple of weeks, lots of things were tested at my place and there are some
> >
On 26 Sep 2002 at 19:17, Justin Clift wrote:
> Shridhar Daithankar wrote:
>
> > 3) Any suggsestions for runtime as data load and query will be going in
> > parallel.
>
> That sounds unusual. From reading this, it *sounds* like you'll be
> running queries against
On 26 Sep 2002 at 19:05, Martijn van Oosterhout wrote:
> On Thu, Sep 26, 2002 at 02:05:44PM +0530, Shridhar Daithankar wrote:
> > 1) Database load time from flat file using copy is very high
> > 2) Creating index takes huge amount of time.
> > 3) Any suggsestions for run
On 26 Sep 2002 at 10:33, Tom Lane wrote:
> "Shridhar Daithankar" <[EMAIL PROTECTED]> writes:
> > RedHat7.2/PostgreSQL7.1.3
>
> I'd suggest a newer release of Postgres ... 7.1.3 is pretty old ...
I agree.. downloadind 7.2.2 right away..
> > Cre
On 26 Sep 2002 at 10:42, Tom Lane wrote:
> Justin Clift <[EMAIL PROTECTED]> writes:
> > If it's any help, when I was testing recently with WAL on a separate
> > drive, the WAL logs were doing more read&writes per second than the main
> > data drive.
>
> ... but way fewer seeks. For anything inv
On 27 Sep 2002 at 1:12, Justin Clift wrote:
> Shridhar Daithankar wrote:
> As a curiosity point, how predictable are the queries you're going to be
> running on your database? They sound very simple and very predicatable.
Mostly predictable selects. Not a domain expert on telec
On 28 Sep 2002 at 17:08, Justin Clift wrote:
> Have moved the indexes to another drive, then created symlinks to them.
> Ran a benchmark against the database, REINDEX'd the tables, VACUUM FULL
> ANALYZE'd, prepared to re-run the benchmark again and guess what?
>
> The indexes were back on the or
On 28 Sep 2002 at 17:51, Justin Clift wrote:
> Shridhar Daithankar wrote:
>
> > Looks like we should have a subdirectory in database directory which stores
> > index.
>
> That was my first thought also, but an alternative/additional approach
> would be this
On 28 Sep 2002 at 12:18, Tom Lane wrote:
> Justin Clift <[EMAIL PROTECTED]> writes:
> > Shridhar Daithankar wrote:
> >> Looks like we should have a subdirectory in database directory which stores
> >> index.
>
> > That was my first thought also, but an
On 29 Sep 2002 at 0:43, Justin Clift wrote:
> Shridhar Daithankar wrote:
> The reason that I was thinking of having a different path per index
> would be for high volume situations like this:
>
> /dev/dsk1 : /pgdata <- data here
> /dev/dsk2 : /pgindexes1 <- some
Hi,
Today we concluded test for database performance. Attached are results and the
schema, for those who have missed earlier discussion on this.
We have (almost) decided that we will partition the data across machines. The
theme is, after every some short interval a burst of data will be enter
On 4 Oct 2002 at 9:46, Hans-Jürgen Schönig wrote:
> Did anybody think about threaded sorting so far?
> Assume an SMP machine. In the case of building an index or in the case
> of sorting a lot of data there is just one backend working. Therefore
> just one CPU is used.
> What about starting a t
On 3 Oct 2002 at 19:33, Shridhar Daithankar wrote:
> On 3 Oct 2002 at 13:56, Nigel J. Andrews wrote:
> > It's one hell of a DB you're building. I'm sure I'm not the only one interested
> > so to satisfy those of us who are nosey: can you say what the applicat
On 3 Oct 2002 at 8:54, Charles H. Woloszynski wrote:
> Can you comment on the tools you are using to do the insertions (Perl,
> Java?) and the distribution of data (all random, all static), and the
> transaction scope (all inserts in one transaction, each insert as a
> single transaction, some
On 3 Oct 2002 at 11:23, Greg Copeland wrote:
> On Thu, 2002-10-03 at 10:56, Shridhar Daithankar wrote:
> > Well, we were comparing ext3 v/s reiserfs. I don't remember the journalling
> > mode of ext3 but we did a 10 GB write test. Besides converting the RAID to RAID-
>
On 3 Oct 2002 at 18:53, Manfred Koizar wrote:
> On Thu, 03 Oct 2002 21:47:03 +0530, "Shridhar Daithankar"
> <[EMAIL PROTECTED]> wrote:
> >I believe that was vacuum analyze only.
>
> Well there is
>
> VACUUM [tablename];
>
> and the
size say 32K
rather than 8K default? Will it saev some overhead and offer better performance
in data load etc?
Will keep you guys updated..
Regards,
Shridhar
---
Shridhar Daithankar
LIMS CPE Team Member, PSPL.
mailto:[EMAIL P
On 4 Oct 2002 at 21:13, Hans-Jürgen Schönig wrote:
> Bingo = great :).
> The I/O problem seems to be solved :).
>
> A table space concept would be top of the histlist :).
>
> The symlink version is not very comfortable and I think it would be a
> real hack.
> Also: If we had a clean table spac
On 5 Oct 2002 at 23:56, Antoine Lobato wrote:
>
> I currently develop an interface to simulate a indexed sequential file
> management with PostgreSql. I must reproduce the same philosophy used of
> control of locking of the records.
> I seek a solution to lock and unlock implicitly a row of a
forgot to copy postgresql.conf to data directory
after he modified it.
This time results are correct. Postgresql loads data faster, indexes it faster
and queries in almost same time.. Way to go..
Regards,
Shridhar
---
Shridhar Daithankar
L
On 7 Oct 2002 at 15:52, Hans-Jürgen Schönig wrote:
> >Can anybody please tell me in detail.(Not just a pointing towards TODO items)
> >1) What a table space supposed to offer?
> They allow you to define a maximum amount of storage for a certain set
> of data.
Use quota
> They help you to defin
On 7 Oct 2002 at 16:49, Hans-Jürgen Schönig wrote:
> >Mount a directory on a partition. If the data exceeds on that partition, there
> >would be disk error. Like tablespace getting overflown. I have seen both the
> >scenarios in action..
> Of course it can be done somehow. However, with tablesp
On 7 Oct 2002 at 10:30, Tom Lane wrote:
> "Shridhar Daithankar" <[EMAIL PROTECTED]> writes:
> > MySQL 3.23.52 with innodb transaction support:
>
> > 4 concurrent queries:- 257.36 ms
> > 40 concurrent queries :- 35.12 ms
>
> &
On 7 Oct 2002 at 11:21, Tom Lane wrote:
> "Shridhar Daithankar" <[EMAIL PROTECTED]> writes:
> > I say if it's a char field, there should be no indicator of length as
> > it's not required. Just store those many characters straight ahead..
>
> Yo
On 7 Oct 2002 at 13:48, Neil Conway wrote:
> "Sandeep Chadha" <[EMAIL PROTECTED]> writes:
> > Postgresql has been lacking this all along. I've installed postgres
> > 7.3b2 and still don't see any archive's flushed to any other
> > place. Please let me know how is hot backup procedure implemented
On 9 Oct 2002 at 10:00, Manfred Koizar wrote:
> On Mon, 07 Oct 2002 15:07:29 +0530, "Shridhar Daithankar"
> <[EMAIL PROTECTED]> wrote:
> >Only worry is database size. Postgresql is 111GB v/s 87 GB for mysql.
>
> Shridhar,
>
> here is an implementat
On 9 Oct 2002 at 10:00, Manfred Koizar wrote:
> On Mon, 07 Oct 2002 15:07:29 +0530, "Shridhar Daithankar"
> <[EMAIL PROTECTED]> wrote:
> >Only worry is database size. Postgresql is 111GB v/s 87 GB for mysql.
>
> Shridhar,
>
> here is an implementat
On 9 Oct 2002 at 9:32, Tom Lane wrote:
> Manfred Koizar <[EMAIL PROTECTED]> writes:
> > here is an implementation of a set of user types: char3, char4,
> > char10.
>
> Coupla quick comments on these:
>
> > CREATE FUNCTION charNN_lt(charNN, charNN)
> > RETURNS boolean
> > AS '$libdir/fix
On 10 Oct 2002 at 15:30, Manfred Koizar wrote:
> On Wed, 09 Oct 2002 10:00:03 +0200, I wrote:
> >here is an implementation of a set of user types: char3, char4,
> >char10.
>
> New version available. As I don't want to spam the list with various
> versions until I get it right eventually, you ca
On 11 Oct 2002 at 16:16, Anuradha Ratnaweera wrote:
>
> Hi all,
>
> I am trying to add some replication features to postgres (yes, I have
> already looked at ongoing work), in a peer to peer manner. The goal
> is to achive `nearly complete fault tolerence' by replicating data.
Sounds a lot li
On 11 Oct 2002 at 16:20, Antti Haapala wrote:
> Check out:
> http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html
Well, I guess there are many threads on this. You can dig around archives..
> > Upgrading MySQL Server is painless. When you are upgrading MySQL Server,
> > you don't need to
On 11 Oct 2002 at 8:30, Greg Copeland wrote:
> I'd be curious to hear in a little more detail what constitutes "not
> good" for postgres on a mosix cluster.
> On Fri, 2002-10-11 at 06:15, Anuradha Ratnaweera wrote:
> > On Fri, Oct 11, 2002 at 04:29:53PM +0530, Shrid
On 14 Oct 2002 at 11:55, Anuradha Ratnaweera wrote:
> On Fri, Oct 11, 2002 at 07:10:26PM +0530, Shridhar Daithankar wrote:
> > On 11 Oct 2002 at 8:30, Greg Copeland wrote:
> >
> > > I'd be curious to hear in a little more detail what constitutes "not
> >
On 16 Oct 2002 at 1:25, Bruce Momjian wrote:
> Anuradha Ratnaweera wrote:
> > Thanks, Bruce. But what I want to know is whether multithreading is
> > likely to get into in postgresql, say somewhere in 8.x, or even in 9.x?
> > (as they did with Apache). Are there any plans to do so, or is postgr
On 16 Oct 2002 at 15:40, Gavin Sherry wrote:
> > In that case, I wonder if it is worth folking a new project to add
> > threading support to the backend? Of course, keeping in sync with the
> > original would be lot of work.
>
> http://sourceforge.net/projects/mtpgsql
Last discussion that happ
On 15 Oct 2002 at 18:19, Bruce Momjian wrote:
> We are showing up in places I never expected: .org registry, tons of
> books, conventions, everywhere. It is just a wave that keeps getting
> bigger and bigger. I am starting to imagine what Linus felt seeing
> Linux take off; you just sit around
On 18 Oct 2002 at 18:10, Ulrich Neumann wrote:
> Marc,
>
> not only the global variables are a problem. PostgreSQL doesn't clean
> up
> all the memory before a process terminates and you must deal with
> signals between threads.
OK, first of all let me say this. I am interested in seeing postgre
choose index scan over sequential scan. I am sure it's already convinced..
Regards,
Shridhar
---
Shridhar Daithankar
LIMS CPE Team Member, PSPL.
mailto:shridhar_daithankar@;persistent.co.in
Phone:- +91-20-5678900 Extn.270
Fax :- +91-20-5678901
-
On 11 Oct 2002 at 16:39, Anuradha Ratnaweera wrote:
> On Fri, Oct 11, 2002 at 04:04:29PM +0530, Shridhar Daithankar wrote:
> > On 11 Oct 2002 at 16:29, Anuradha Ratnaweera wrote:
> >
> > > On Fri, Oct 11, 2002 at 03:54:15PM +0530, Shridhar Daithankar wrote:
> > >
On 11 Oct 2002 at 16:29, Anuradha Ratnaweera wrote:
> On Fri, Oct 11, 2002 at 03:54:15PM +0530, Shridhar Daithankar wrote:
> I will look at it, too. Thanks for the link. In some cases, starting
> anew is faster than learning unmaintained existing code.
While that's true, usogre
On 12 Oct 2002 at 8:54, Giles Lean wrote:
> Portable code uses 'unsigned char' when using ctype.h features, even
> though for many platforms where 'char' is an unsigned type it's not
> necessary for correct functioning.
>
> I don't see any isspace() or similar in the code though, so I'm not
> sur
On 12 Oct 2002 at 2:54, Jeff Davis wrote:
> As far as I can tell, the order the attributes are returned makes no
> difference in a client application, unless you're referencing attributes by
> number. All applications that I've made or seen all use the name instead, and
> I've never heard other
On 27 Oct 2032 at 0:24, Timothy Chan wrote:
>
> Hi
> i would like to use postgresql to store any data (some include chinese),
> but when i access the chinese data inpostgresql, i can't get back correct
> data, it return any unknow word/data to me.
> How can i solve it? i am using the RedHat Li
On 4 Nov 2002 at 12:23, Mikheev, Vadim wrote:
> > My presumption would be that if you initialize 2 databases to
> > a known identical start, have all the same triggers and rules
> > on both, then send all queries to both databases, you will
> > have 2 identical databases at the end.
>
> This is
On 8 Nov 2002 at 11:03, Florian Litot wrote:
> yes it's good but can i have the date with each line?
Err.. I don't think so. Sounds like a good addition to me.
Any ideas?
Bye
Shridhar
--
Absentee, n.: A person with an income who has had the forethought to remove
himself from the sphere o
On 26 Nov 2002 at 21:54, Matthew T. O'Connor wrote:
> First: Do we want AVD integrated into the main source tree, or should it
> remain a "tool" that can be downloaded from gborg. I would think it
> should be controlled by the postmaster, and configured from GUC (at
> least basic on off settings)
On 27 Nov 2002 at 8:21, Al Sutton wrote:
> The problem I have with VMWare is that for the cost of a licence plus the
> additional hardware on the box running it (CPU power, RAM, etc.) I can buy a
> second cheap machine, using VMWare doesn't appear to save me my biggest
> overheads of training staf
On 27 Nov 2002 at 13:01, Matthew T. O'Connor wrote:
> On Wed, 2002-11-27 at 01:59, Shridhar Daithankar wrote:
> > I would not like postmaster forking into pgavd app. As far as possible, we
> > should not touch the core. This is a client app. and be it that way. Once we
&
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 put on this system. It might make sense to say allow upto X
> > concurrent vacuums, a 4 processor system might handle 4
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
> > > processor-intensive, but it is d
On 2 Dec 2002 at 12:05, Karel Zak wrote:
> On Sat, Nov 30, 2002 at 01:11:20PM -0800, Joe Conway wrote:
> > As I said, this is all very preliminary; comments, suggestions, requests
> > are all welcome.
> Only idea/dream: what implement dblink as "virtual" schema.
> CREATE SCHEMA myschema AS DBLIN
On 4 Dec 2002 at 8:13, Tommi Maekitalo wrote:
> I thought MySQL is marked as obsolete since PostgreSQL 7.3 ;-)
If you ask me, one should never under-estimate the compitition..No matter how
big upper hand you have..
If you want to compete in the first place, that is..
Bye
Shridhar
--
Ogden's
On 4 Dec 2002 at 20:41, Hannu Krosing wrote:
> hannu=# update seq set max_value = 99;
> ERROR: You can't change sequence relation seq
> hannu=# update pg_class set relkind = 'r' where relname = 'seq';
> UPDATE 1
> hannu=# update seq set max_value = 99;
> UPDATE 1
> hannu=# update pg_class set relk
On 9 Dec 2002 at 1:20, Kevin Brown wrote:
> 2. They need 24x7 support, and are convinced that they'll get better
> support for Oracle or DB2 than anything else.
I have experienced what oracle support means for 24x7. I wouldn't even wish
that penalty for my worst enemy.
I can tell a story a
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
On 12 Dec 2002 at 16:09, Stephan Szabo wrote:
>
> On Fri, 13 Dec 2002, [iso-8859-1] Diego T. wrote:
>
> > Hello I'm an Italian student of computer science at
> > University of Rome "La Sapienza". I've to analyze some
> > daemons which run under root privileges with a tool
> > developed by my dep
On 13 Dec 2002 at 1:22, Bruce Momjian wrote:
> Replication
>
> I have talked to Darren Johnson and I believe 7.4 is the time to
> merge the Postgres-R source tree into our main CVS. Most of the
> replication code will be in its own directory, with only minor
> changes to o
On Friday 13 December 2002 11:01 pm, you wrote:
> Good. This is the discussion we need. Let me quote the TODO list
> replication section first:
>
> * Add replication of distributed databases [replication]
> o automatic failover
Very good. We need that for HA.
> o load balanc
On 14 Dec 2002 at 18:02, Justin Clift wrote:
> For PITR-log-based-replication, how much data would be required to be pushed out to
>each slave system in order to bring
> it up to date?
>
> I'm having visions of a 16MB WAL file being pushed out to slave systems in order to
>update them with a fe
On Monday 16 December 2002 07:26 pm, you wrote:
> I'm curious, what would be the recovery strategy for PITR master-slave
> replication should the master fail (assuming hot fail over/backup)? A
> simple dump/restore? Are there/is there any facilities in PorstgreSQL
> for PITR archival which preven
On Monday 16 December 2002 07:43 pm, you wrote:
> Consider that on the slave which is now the active server (master dead),
> it's possible that the slave's PITR's will be recycled before the master
> can come back up. As such, unless there is a, an archival process for
> PITR or b, a method of str
On Monday 16 December 2002 08:07 pm, you wrote:
> On Mon, 2002-12-16 at 08:20, Shridhar Daithankar wrote:
> > I don't know about WAL numbering but AFAIU, it increments and old files
> > are removed once there are enough WAL files as specified in
> > posgresql.conf. IIRC
On 18 Dec 2002 at 8:54, scott.marlowe wrote:
>
> www.linuxtoday.com has weekly updates from many gnu / OSS projects which
> are far less interesting than our 7.3.1 release is. I could see posting a
> minor upgrade release notice there and on other OSS news web site
> (freshmeat, slashdot, etc.
Hi all,
I am sure, many of you would like to delete this message before reading, hold
on. :-)
There is much talk about threading on this list and the idea is always
deferred for want of robust thread models across all supported platforms and
feasibility of gains v/s efforts required.
I think
On Saturday 04 January 2003 03:20 am, you wrote:
> >I am sure, many of you would like to delete this message before reading,
> > hold on. :-)
>
> I'm afraid most posters did not read the message. Those who replied
>
> "Why bother?" did not address your challenge:
Our challenges may be..;-)
Anyw
On 6 Jan 2003 at 12:22, Ulrich Neumann wrote:
> Hello all,
> If someone is interested in the code I can send a zip file to everyone
> who wants.
I suggest you preserver your work. The reason I suggested thread are mainly two
folds.
1) Get I/O time used fuitfully
2) Use multiple CPU better.
It
On 6 Jan 2003 at 6:48, Greg Copeland wrote:
> > 1) Get I/O time used fuitfully
> AIO may address this without the need for integrated threading.
> Arguably, from the long thread that last appeared on the topic of AIO,
> some hold that AIO doesn't even offer anything beyond the current
> implementa
On 17 Jan 2003 at 1:16, Tom Lane wrote:
> Currently, the default sysid assigned to a user or group is computed as
> "max(sysid)+1". We've seen a couple of complaints now from people who
> deleted their newest user, made another user, and found that permissions
> from the deleted user carried over
On Thursday 23 January 2003 08:40 pm, you wrote:
> On Thu, Jan 23, 2003 at 02:40:33PM +0530, Shridhar
Daithankar<[EMAIL PROTECTED]> wrote:
> > I would like to know if ECPG is thread safe and I can use an arbitrary
> > PGconn* object pulled from a connection pool.
> Not
On Thursday 23 January 2003 08:42 pm, you wrote:
> On Sat, 4 Jan 2003, Christopher Kings-Lynne wrote:
> > Also remember that in even well developed OS's like FreeBSD, all a
> > process's threads will execute only on one CPU.
>
> I doubt that - it certainly isn't the case on Linux and Solaris.
> A t
1 - 100 of 280 matches
Mail list logo
