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.
http://svnbook.red-bean.
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
machin
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_
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 proble
[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 a
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
[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. postgresql.
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
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
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 tim
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 follo
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.
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 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
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
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
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
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
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
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
>
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
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 -Wmissing-de
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 b
On Saturday 29 May 2004 20:48, [EMAIL PROTECTED] wrote:
> I was thinking that it could be done as a contrib/pgfoundary function. I
> think, but am not sure, that a function can be pre-loaded into the main
> postgresql backend (postmaster) prior to starting other connections. I'll
> have to check th
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 *
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 fr
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 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 rea
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.
> > ...
>
>
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
resembl
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
sup
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 connection
EXEC SQL END DECLARE SECTION;
EXEC SQL 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:33
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 ca
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 wa
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 con
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
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 var
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
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 in
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/relnam
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/printer.php?news_id=6136
Shridhar
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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
threads,
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 t
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() vi
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 ma
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:
> >
> > http://momjian.postgresql.org/main/writings/
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 PR
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
--
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 actually
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 communi
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 advanta
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 n
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
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 gett
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/cvsw
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 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 dela
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 ac
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 act
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
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
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 broadcast)
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 been
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.
Wel
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 necess
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 b
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 the
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
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
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 for a
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 broadcast)-
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
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 adv
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
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
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 i
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 data
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 upd
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
depen
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 vac
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
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
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 a
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 approac
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 understandin
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, becaus
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 as there are
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
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
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
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. Will
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
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 advoc
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 broadca
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 cou
On Friday 26 September 2003 20:19, Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > We really don't need threads to replace existing functionality. That
> > would be dog work.
>
> No, that's not the point at all. The problem we are facing
1 - 100 of 280 matches
Mail list logo
