On Wednesday 04 May 2005 8:18 pm, Marc G. Fournier wrote:
Just curious here ... but do any of the version control systems provide
per directory user restrictions? Where I could give CVS access to
Joshua, for instance, just to the plphp directory?
Subversion does.
On Thursday 06 Jan 2005 3:52 pm, Peter Eisentraut wrote:
First, we still do not have any test with 8.0 on the following platforms:
HP-UX
All the 96 tests are passed on RC3. I can rerun the tests with additional
configure flags if required..But I can not install anything new on HP-UX
machine.
On Monday 09 Aug 2004 9:18 pm, Robert Treat wrote:
but I was pretty sure I had lpthread library on my machine (and verified
this with some help from irc). however Makefile.global told me
PTHREAD_CFLAGS = -pthread -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS
PTHREAD_LIBS
[EMAIL PROTECTED] wrote:
The session table is a different issue, but has the same problems. You
have an active website, hundreds or thousands of hits a second, and you
want to manage sessions for this site. Sessions are created, updated many
times, and deleted. Performance degrades steadily until
Glen Parker wrote:
It has been suggested in past to add such a visibility to index
tuple header so
that index and heaps can be cleaned out of order. In such a case
other backround
It seems to me that the benefit of this wouldn't be all that impressive
*when accessing the cache*, which is the
[EMAIL PROTECTED] wrote:
I have a LOT of opinions about postgresql.conf, and frankly, I think more
comments are not where the problems lie.
If you *really* want to make configuring postgresql easier,
postgresql.conf HAS to live outside the data directory and specify where
everything is.
Honza Pazdziora wrote:
On Wed, Jun 09, 2004 at 07:53:19PM +0530, Shridhar Daithankar wrote:
Well, the statement 'postgresql.conf outside data directory' isn't going to
win I think.
One day there won't be any data directory because the data will be
on raw partitions. Then you will _have_ to have
Andrew Dunstan wrote:
Shridhar Daithankar wrote:
Leaving it for a full build as I am calling it a day. Will give it
another go tomorrow morning..
What you would need to test is not #ifdefing the whole thing out -
rather you would need to enable the fputc by removing the #ifndef and
#endif
Hi,
I checked out the windows port to play with. It compiled file but 'make check'
produced attached regression diff.
I am using the nightly snapshot. Is it too early to look at these failures or
did I do something wrong? I was following usual ./configure;make procedure after
installing mingw.
Andrew Dunstan wrote:
Shridhar Daithankar wrote:
Hi,
I checked out the windows port to play with. It compiled file but
'make check' produced attached regression diff.
I am using the nightly snapshot. Is it too early to look at these
failures or did I do something wrong? I was following usual
Bruce Momjian wrote:
http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out
Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.
ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz
It is
Bruce Momjian wrote:
Shridhar Daithankar wrote:
Bruce Momjian wrote:
http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out
Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.
ftp
June 2004 18:01, Shridhar Daithankar wrote:
On Tuesday 01 June 2004 14:12, Shridhar Daithankar wrote:
Actually I need to find out few more things about it. It is not as simple
as adding a assign_hook. When I tried to initdb with changes, it demanded
64MB of shared buffers which I (now) think
On Wednesday 02 June 2004 20:16, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
Any updates/opinions? Should we convert assign hooks to perform actual
assignment and custom validation instead of just custom validation? It is
clear from README that it is for validation
On Wednesday 02 June 2004 20:59, Tom Lane wrote:
Frank Wiles [EMAIL PROTECTED] writes:
This may be an unreasonable suggestion, but how about allowing both?
I've seen several configuration systems do the following:
shared_buffers = 1 ( shared_buffers in pages )
On Monday 31 May 2004 22:00, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
Right now following are measured in pages
wal_buffers
shared_buffers
effective_cachesize
while rest of the memory parameters are in kb. I thought being uniform
would be good. Besides
On Tuesday 01 June 2004 14:12, Shridhar Daithankar wrote:
Actually I need to find out few more things about it. It is not as simple
as adding a assign_hook. When I tried to initdb with changes, it demanded
64MB of shared buffers which I (now) think that somewhere NBuffers are used
before
On Sunday 30 May 2004 21:33, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
I was toying around with idea of converting all the memory related
parameters in postgresql.conf to kilobytes for simplicity and
uniformity.
Why is that a good idea?
Right now following
On Monday 31 May 2004 18:41, Bruce Momjian wrote:
Shridhar Daithankar wrote:
On Sunday 30 May 2004 21:33, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
I was toying around with idea of converting all the memory related
parameters in postgresql.conf to kilobytes
On Sunday 30 May 2004 19:37, Bruce Momjian wrote:
The relevant configure messages read
-
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads
On Saturday 29 May 2004 18:10, [EMAIL PROTECTED] wrote:
Having internal PostgreSQL variables that are not present on disk, or
maybe, variables that are mirrored on disk may be good.
Yes. I agree. I can see why you proposed no transactions few posts ago. Take
an example of a count variable. It
Hi,
I was toying around with idea of converting all the memory related parameters
in postgresql.conf to kilobytes for simplicity and uniformity.
Attached is a proof of concept patch that converts shared_buffers to kilobytes
using assign_hook.
It compiled all-right but I experienced a strange
Hi,
Platform Slackware linux 9.1/ Linux 2.6.4
I did a make distclean and ./configure --enable-thread-safety. The build
aborted with following error messages
make[4]: Leaving directory `/home/shridhar/postgresql/pgsql/src/port'
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
On Saturday 29 May 2004 04:38, [EMAIL PROTECTED] wrote:
Now, I could roll my own system pretty easily, and probably will do so. It
won't take too much, however, it would be neat if this was in PostgreSQL.
I fully expect that people would worry about this, and I don't blame them.
It is a *bad*
On Wednesday 19 May 2004 00:19, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
This makes me worried. That's the way we *used* to do things, but the
sleazy IP lawyers are looking for anything with which they can create
the
impression of impropriety. The open source and free projects
Hi,
I was thinking other way round. What if we write to WAL pages only to those
portions which we need to modify and let kernel do the job the way it sees fit?
What will happen if it fails?
Bruce Momjian wrote:
Our current WAL implementation writes copies of full pages to WAL before
modifying
On Sunday 07 March 2004 20:28, Michael Meskes wrote:
On Wed, Mar 03, 2004 at 07:40:40PM +0530, Shridhar Daithankar wrote:
Is this fine?
* Allow a 'connection *' pointer to be specified instead of a string to
denote a connection.
...
I personally have no problem with this as long
On Sunday 07 March 2004 09:16, Tom Lane wrote:
Personally I consider -c format the only one of the three that is
readable for reviewing purposes, so even if I weren't intending
immediate application, I'd ask for -c before looking at the patch.
There are some folks who consider -u format
Zeugswetter Andreas SB SD wrote:
- Dispose names of connectiong and replace them with a pointer.
You cannot dispose the names, you can only add something to also allow pointers.
The names are in the ESQL/C standard.
Can you point me to the standards text? I am googling for it but nothing
AT :s_connection SELECT it INTO :s_it FROM some_table;
return( s_it );
}
which could be run concurrently by multiple threads.
L.
Shridhar Daithankar writes:
On Friday 27 February 2004 20:54, Michael Meskes wrote:
On Fri, Feb 27, 2004 at 04:22:33PM +0530, Shridhar Daithankar wrote:
How about, allowing
Lee Kindness wrote:
Shridhar, want to discuss this off list a bit to work through the various
options and then revent back to the list with a suitable to-do (for
discussion)?
I don't mind. Just for summary, I am listing the discussion/proposal so far on
this issue..
- Dispose names of
Tom Lane wrote:
I think also that Simon completely misunderstood my intent in saying
that this could be user-scriptable policy. By that I meant that the
*user* could write the code to behave whichever way he liked. Not that
we were going to go into a mad rush of feature invention and try to
On Tuesday 02 March 2004 06:29, Paul Tillotson wrote:
However, for this to be useful, your table must not have any indexes,
views, foreign keys, sequences, triggers, etc., or else you must be
prepared to re-create all of them using application level code.
Which isn't a big deal is it? You can
On Tuesday 24 February 2004 22:13, Stephen wrote:
Hi,
Recently, I ran a huge update on an Integer column affecting 100 million
rows in my database. What happened was my disk space increased in size and
my IO load was very high. It appears that MVCC wants to rewrite each row
(each row was
On Friday 27 February 2004 22:24, Lee Kindness wrote:
Sort of related, I was thinking about adding some more thread-related
code such that if a connection wasn't explicitely specified then the
last connection SET or CONNECTed to for the current thread is used,
rather than just the last
Michael Meskes wrote:
On Mon, Feb 23, 2004 at 09:27:40PM +0530, Shridhar Daithankar wrote:
What I wonder is, do we really need to maintain that level of lookup? Can't we
just say a connection is a 'struct connection *' which should be opaque and
should not be touched or poked inside, just like
Zeugswetter Andreas SB SD wrote:
I am asking for CONNECTION being a variable of data type 'connection *' rather
than 'const char *'. That would avoid name lookups.
Is that out of spec?
Yes, but the preprocessor could still add an optimization ala 'connection *' for
the hardcoded cases (exec sql
On Friday 27 February 2004 19:59, Andrew Dunstan wrote:
I believe it should not be hard to do a one-time bulk registration of
everyone on the lists, if that was desired.
I agree. If possible we could also run postgresql registration system where we
can track general usage of postgresql on
On Friday 27 February 2004 20:54, Michael Meskes wrote:
On Fri, Feb 27, 2004 at 04:22:33PM +0530, Shridhar Daithankar wrote:
How about, allowing 'connection *'? If somebody puts a 'connection *'
there it is used. If it is a string a name search is performed. Best of
both worlds.
How shall
On Thursday 26 February 2004 15:37, Gavin Sherry wrote:
Tying it all together:
The catalogs pg_database, pg_namespace, and pg_class will have a 'tblspc'
field. This will be the OID of the table space the object resides in, or 0
(default table space). Since we can then resolve relid/relname,
http://www.osnews.com/printer.php?news_id=6136
Shridhar
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Tuesday 24 February 2004 21:15, scott.marlowe wrote:
On Tue, 24 Feb 2004, Shridhar Daithankar wrote:
http://www.osnews.com/printer.php?news_id=6136
That page gets a please don't link to printer ready pages error and
redirects to here:
http://www.osnews.com/story.php?news_id=6136
My bad
Hi all,
I was just going thr. the ecpg sources checking for thread safety.
It looks like the mutex protects the connections list in connection.c. I do
not like that from a application developers perspective.
If I am developing an application and using multiple connections in multiple
Hi all,
Just stumbled upon this. just an FYI,
http://www.microsoft.com/sql/yukon/productinfo/top30features.asp
Shridhar
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
On Thursday 05 February 2004 20:24, Tom Lane wrote:
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
So Imho the target should be to have not much IO open for the checkpoint,
so the fsync is fast enough, even if serial.
The best we can do is push out dirty pages with write() via the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Ezra Epstein wrote:
I'd like to extend SET SESSION AUTHORIZATION to support a form which takes a
password.
Uh, a password? What purpose would that serve?
Indeed. SET SESSION AUTH is already allowed only to superusers --- a
superuser
On Saturday 20 December 2003 00:00, Josh Berkus wrote:
In discussions with Linux kernel hackers online, they blame the way that
PostgreSQL uses shared memory. Whether or not they are correct, the
effect of the issue is to harm PostgreSQL's performance and make us look
bad on one of the major
On Thursday 18 December 2003 17:37, Dave Cramer wrote:
test_thread.pgc:51: undefined reference to `pthread_create'
undefined reference to `pthread_join'
It is not linking against pthreads library. Do you have -lpthread cause in
your compilation/linking command?
Shridhar
On Thursday 18 December 2003 18:03, Dave Cramer wrote:
Shridhar,
Obviously not, but I just did make inside the test directory, so I
assume the Makefile needs to be fixed.
I don't think so.. Check this..
[EMAIL PROTECTED] pgsql]$ find . -name Makefile.global
./src/Makefile.global
[EMAIL
On Thursday 18 December 2003 20:16, Robert Treat wrote:
On Wed, 2003-12-17 at 21:37, Bruce Momjian wrote:
I have put up a list of projects being worked on and their TODO lists in
hope that people will find it easier to work on them:
Andrew Dunstan wrote:
Not to mention it would kill PostgreSQL's current speedy performance!
Maybe, maybe not. Modern JVMs have much better performance
characteristics than was once the case. Also, some of the things that
Java buys you (memory management, threading, for example) might
Bruce Momjian wrote:
Guys, where are we on tablespaces? Should I set up a project page or
does it need organization? I think we need to define the command syntax
and then implementation details. I don't think it is that hard and
certainly is possible for 7.5.
There was a offlist group
On Wednesday 03 December 2003 13:59, Mark Kirkwood wrote:
How about:
Implement a function estimated_count that can be used instead of
count. It could use something like the algorithm in
src/backend/commands/analyze.c to get a reasonably accurate psuedo count
quickly.
The advantage of this
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
I was looking thr. the source and thought it would be worth to seek
opinion on this proposal.
This has been discussed and rejected before. See the archives.
I went thr. this for details.
http://developer.postgresql.org/cvsweb.cgi
Christopher Kings-Lynne wrote:
Hi everyone,
I'm just interested in what everyone's personal plans for 7.5
development are?
Shridar, Gavin and myself are trying to get the tablespaces stuff off
the ground. Hopefully we'll have a CVS set up for us to work in at some
point (we didn't think
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
I covered only first point in my post. IMO it is not such a unsolvable
problem. If a postmaster crashes hard but leaves a backend running,
would it clean pid file etc? I don't think so. So if a postmaster can
start on a 'pid-clean
Tom Lane wrote:
1. You can't easily generate a clean diff of your local version against
the original imported from postgresql.org. The changes you actually
made get buried in a mass of useless $Foo$ diff lines. Stripping those
out is possible in theory but painful.
Is that the reason linux does
Hello All,
I was looking thr. the source and thought it would be worth to seek opinion on
this proposal.
From what I understood so far, the core shared memory handling is done in
pgsql/src/backend/port/sysv_shmem.c. It is linked by configure as per the
runtime environment.
So I need to write
Matthew T. O'Connor wrote:
But we track tuples because we can compare against the count given by
the stats system. I don't know of a way (other than looking at the FSM,
or contrib/pgstattuple ) to see how many dead pages exist.
I think making pg_autovacuum dependent of pgstattuple is very good
On Thursday 20 November 2003 13:09, David Fetter wrote:
On Thu, Nov 20, 2003 at 11:45:06AM +0530, Shridhar Daithankar wrote:
Joshua D. Drake wrote:
Is there some way to remove this piece of sh^H^Hlegacy from the
configure script? Does anybody actually use info?
All of GNU
Josh Berkus wrote:
Shridhar,
However I do not agree with this logic entirely. It pegs the next vacuum
w.r.t current table size which is not always a good thing.
No, I think the logic's fine, it's the numbers which are wrong. We want to
vacuum when updates reach between 5% and 15% of total
On Thursday 20 November 2003 20:00, Matthew T. O'Connor wrote:
Shridhar Daithankar wrote:
I will submit a patch that would account deletes in analyze threshold.
Since you want to delay the analyze, I would calculate analyze count as
deletes are already accounted for in the analyze threshold
On Thursday 20 November 2003 20:29, Shridhar Daithankar wrote:
On Thursday 20 November 2003 20:00, Matthew T. O'Connor wrote:
Shridhar Daithankar wrote:
I will submit a patch that would account deletes in analyze threshold.
Since you want to delay the analyze, I would calculate analyze
Jean-Michel POURE wrote:
OK, now, some of us will complain that Win32 is not needed at a time when the
Debian Synaptic graphical installer gives access to 13.748 packages. Win32
sounds like an old Atari game station. Agreed. On the long-run, everyone
will leave Win32, even my grand-mother.
Josh Berkus wrote:
Shridhar,
I was looking at the -V/-v and -A/-a settings in pgavd, and really don't
understand how the calculation works. According to the readme, if I set -v
to 1000 and -V to 2 (the defaults) for a table with 10,000 rows, pgavd would
only vacuum after 21,000 rows had
Joshua D. Drake wrote:
Is there some way to remove this piece of sh^H^Hlegacy from the
configure script? Does anybody actually use info?
All of GNU.
Additionally it is very good resource when you use Konqueror to browse it as html..
Shridhar
---(end of
Jan Wieck wrote:
I committed the first part of the background writer process. We had a
consensus on attempting to avoid write() calls from regular backends,
but did no come to any conclusions what to do to force the kernel to
actually do some IO.
Consequently, this patch is a separate process
Bruce Momjian wrote:
Shridhar Daithankar wrote:
On Friday 14 November 2003 22:10, Jan Wieck wrote:
Shridhar Daithankar wrote:
On Friday 14 November 2003 03:05, Jan Wieck wrote:
For sure the sync() needs to be replaced by the discussed fsync() of
recently written files. And I think
Hannu Krosing wrote:
Tom Lane kirjutas E, 17.11.2003 kell 02:08:
Neil Conway [EMAIL PROTECTED] writes:
Hmmm... I agree this behavior isn't ideal, although I can see the case
for viewing this as a mistake by the application developer: they are
assuming that they know exactly when transactions
Zeugswetter Andreas SB SD wrote:
1. Open WAL files with O_SYNC|O_DIRECT or O_SYNC(Not sure if
Without grouping WAL writes that does not fly. Iff however such grouping
is implemented that should deliver optimal performance. I don't think flushing
WAL to the OS early (before a tx commits) is
On Friday 14 November 2003 22:10, Jan Wieck wrote:
Shridhar Daithankar wrote:
On Friday 14 November 2003 03:05, Jan Wieck wrote:
For sure the sync() needs to be replaced by the discussed fsync() of
recently written files. And I think the algorithm how much and how often
to flush can
On Friday 14 November 2003 03:05, Jan Wieck wrote:
For sure the sync() needs to be replaced by the discussed fsync() of
recently written files. And I think the algorithm how much and how often
to flush can be significantly improved. But after all, this does not
change the real checkpointing at
Austin Gonyou wrote:
What facilities are/will be available for hot(online) backups with the
7.4 release? PITR, something else? TIA.
pg_dump?
Did you mean hot failover or hot backup? Postgresql does hot backup for a long time.
Bye
Shridhar
---(end of
Austin Gonyou wrote:
On Wed, 2003-11-12 at 01:00, Shridhar Daithankar wrote:
Austin Gonyou wrote:
What facilities are/will be available for hot(online) backups with the
7.4 release? PITR, something else? TIA.
pg_dump?
Did you mean hot failover or hot backup? Postgresql does hot backup
On Tuesday 11 November 2003 18:55, Jan Wieck wrote:
Shridhar Daithankar wrote:
On Tuesday 11 November 2003 00:50, Neil Conway wrote:
Jan Wieck [EMAIL PROTECTED] writes:
We can't resize shared memory because we allocate the whole thing in
one big hump - which causes the shmmax problem
On Tuesday 11 November 2003 19:19, Peter Eisentraut wrote:
Andrew Dunstan writes:
Seriously, I have wondered if it might be a good idea to assemble a
small hit team that would take some high profile open source projects
and make sure they worked with Postgres. Bugzilla would be the most
Peter Eisentraut wrote:
Shridhar Daithankar writes:
So forming a new group is quite beneficial?
No, we don't need one group, we need many individuals (or possibly small
groups) to get in contact with their second favorite projects and hang out
there.
I meant lets form a group within advocacy
Greg Stark wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
If the parent postmaster mmaps anonymous memory segments and shares them with
children, postgresql wouldn't be dependent upon any kernel resourse aka
shared memory anymore.
Anonymous memory mappings aren't shared, at least
On Tuesday 11 November 2003 00:50, Neil Conway wrote:
Jan Wieck [EMAIL PROTECTED] writes:
We can't resize shared memory because we allocate the whole thing in
one big hump - which causes the shmmax problem BTW. If we allocate
that in chunks of multiple blocks, we only have to give it a
Hi,
Last week, there was a thread whether solely in memory vacuum can be performed
or not.(OK, that was a part of thread but anyways)
I suggested that a page be vacuumed when it is pushed out of buffer cache. Tom
pointed out that it can not be done as index tuples stote heap tuple id and
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
What are (more) reasons for not adding transaction information to
index tuple, in addition to heap tuple?
Cons are bloated indexes. The index tuple size will be close to 30
bytes minimum.
And extra time to perform an update
Thiago Fernandes Moesch wrote:
It would be great for maintainance if every object had a timestamp of
the last vaccum run on it. From time to time we're working with several
databases and I can't tell wich one needs a new vacuum.
Another important information would be the rate of disposable
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
I was thinking about it. How about vacuuming a page when it is been
pushed out of postgresql buffer cache? It is is memory so not much IO
is involved.
You keep ignoring the problem of removing index entries. To vacuum an
individual
Gaetano Mendola wrote:
The vacuum cost is the same of a full scan table ( select count(*) ) ?
Why not do a sort of vacuum if a scan table happen ( during a simple
select that invole a full scan table for example )?
I was thinking about it. How about vacuuming a page when it is been pushed out
of
Tom Lane wrote:
I was just thinking of a GUC parameter: wait N milliseconds between
pages, where N defaults to zero probably. A user who wants to run his
vacuum as a background process could set N larger than zero. I don't
believe we are anywhere near being able to automatically adjust the
delay
Jean-Michel POURE wrote:
Dear friends,
I would like to port Compiere CRM from Oracle to PostgreSQL (and release it
for free).
At first I would like to convert the data schema. This is not difficult as
Compiere is written using portable types like NUMBER (i,d) which can be
replaced by NUMERIC
Andrew Sullivan wrote:
On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
I am slightly confused here. IIRC pg_autovacuum never did a vacuum full. At
the most it does vacuum /vacuum analyse, none of which chew disk bandwidth.
The latter is false. VACUUM FULL certainly uses
Alvaro Herrera wrote:
On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
And if pg_autovacuum is running along with postmaster all the time, with
aggressive polling like 5 sec, the database should not accumulate any dead
tuples nor it would suffer xid wraparound
Alvaro Herrera wrote:
On Fri, Oct 17, 2003 at 07:41:38PM +0530, Shridhar Daithankar wrote:
Alvaro Herrera wrote:
On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
The database can suffer XID wraparound anyway if there's at least one
table without updates, because
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
What part of plain vacuum takes disk bandwidth?
Reading (and possibly rewriting) all the pages.
I was under impression that was for shared memory pages only and not for disk pages.
OK. I can see difference of understanding here
Matthew T. O'Connor wrote:
On Fri, 2003-10-17 at 10:25, Shridhar Daithankar wrote:
OK. So here is what I understand. I have a table which contains 100 rows which
appeated there due to some insert operation. Then I vacuum it. And sit there for
internity for rest of the database to approach
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
Would it be possible to have a vacuum variant that would just shuffle thr.
shared buffers and not touch disk at all?
What would be the use of that? You couldn't predict *anything* about
the coverage. Maybe you find all the free
Rod Taylor wrote:
On Fri, 2003-10-17 at 10:22, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
What part of plain vacuum takes disk bandwidth?
Reading (and possibly rewriting) all the pages.
Would it be possible for the backend to keep a list of the first N (N
being a large
Joshua D. Drake wrote:
Hello,
I believe that the Int8/BigInt items are known issues but I have a knew
programmer that ran into it
over the weekend (he didn't call me when he encountered the problem,
when he should of) and we have a
customer that burned some significant time on it as well.
On Monday 29 September 2003 15:58, Christopher Kings-Lynne wrote:
So a db designer made a bloody mistake.
The problem is there's no easy way to find out what's missing.
I'd really like EXPLAIN to display all subsequent triggered queries
also, to see the full scans caused by missing indexes.
On Sunday 28 September 2003 11:53, mlg7 wrote:
On Saturday 27 September 2003 19:46, Peter Eisentraut wrote:
mlg7 writes:
Is there a centralized list of pgsql PL's ?
I'm not aware of one.
http://techdocs.postgresql.org/guides/PLLanguages
Josh posted it on advocacy few days back.
On Saturday 27 September 2003 20:17, Bruce Momjian wrote:
Richard Huxton wrote:
I have been thinking it might be time to start allowing external
programs to be called when certain events occur that require
administrative attention --- this would be a good case for that.
Administrators could
On Saturday 27 September 2003 19:46, Peter Eisentraut wrote:
mlg7 writes:
Is there a centralized list of pgsql PL's ?
I'm not aware of one.
http://techdocs.postgresql.org/guides/PLLanguages
Josh posted it on advocacy few days back.
Shridhar
---(end of
Hornyak Laszlo wrote:
I think it is not that simple. How should I explain the company leaders
why I must stop the system. It may risk their bussiness success too. I can
tell them that the new db is more stable, but until the old one does the
job, it is still acceptable for them (it served the
Greg Stark wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
The little pthreads programming I did on linux/freeBSD tells me that it
supports majority of features except TLS(linux2.4/linuxthreads) and per thread
signals.
LinuxThreads is dead. NPTL is the way and the light.
It has ELF TLS
1 - 100 of 267 matches
Mail list logo
