>>>"scott.marlowe" said:
> On 11 Feb 2003, Greg Copeland wrote:
> > Besides, I'm not sure that it makes sense to let other product needs
> > dictate the default configurations for this one. It would be one thing
> > if the vast majority of people only used PostgreSQL with Apache. I know
> >
Hi all!
Things are very unclear to me. Are we in a personal war with Microsoft and I'm not aware?
I don't really much care what's the OS our product is running on. I care much about our product's high availability, speed, scalability etc. In the last month I saw on this list a lot of opinions rega
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > I assume $PGDATA was around long before GUC?
>
> Yes, it was. But I have not yet seen an argument here that justifies
> why $SOMECONFIGDIRECTORY/postgresql.conf is better than
> $PGDATA/postgresql.conf.
Okay, here's one: most Unix s
I think the problem you see is due to the the mapping table changes
between 7.2 and 7.3. It seems there are more changes other than
u301c. Moreover according to the recent discussion in Japanese local
mailing list, 7.3's JDBC driver now relies on the encoding conversion
performed by the backend. ie
>>>Vatamanescu Victor said:
> I don't really much care what's the OS our product is running on. I care muc
h about our product's high availability, speed, scalability etc. In the la
st month I saw on this list a lot of opinions regarding the differences be
tween various operating sy
On Tuesday 11 February 2003 20:56, Lamar Owen wrote:
> Being that this group of hackers is one I trust, and that this is a pretty
> common scenario for contract programming, I thought I'd ask this group a
> question. I hope you don't mind.
I want to thank everyone for their responses. We will se
Well, I havent seen much that unstable API. If you saw something unstable please provide me source code that proves Windows API is unstable. Don't tell me about some "expert"'s oppinion: if you have a problem with Windows show it to me. We are not users here. I agree that Windows 95/98 was a sh...,
>>>Vatamanescu Victor said:
> Well, I havent seen much that unstable API. If you saw something unstable pl
ease provide me source code that proves Windows API is unstable. Don't tel
l me about some "expert"'s oppinion: if you have a problem with Windows sh
ow it to me. We are not us
I think there should be a special mailing list set up called
pg-sql-win32-advocacy where people can continually harass the postgres
dev team and debate the merits of the win32 operating system. In
particular, make sure to insult them for being elitists (while at the
same time asking them to work
>
> > Another way of looking at it is memory mapped files. This probably
most
> > closely resembles unix shared memory and is the de facto standard
way
> > for interprocess memory block sharing. Sadly, performance will
suffer
> > because you have to rely on the virtual memory system (think:
writ
On Wed, 2003-02-12 at 08:24, Kevin Brown wrote:
> Tom Lane wrote:
> > You can only justify it as simpler if you propose hardwiring a value
> > for $SOMECONFIGDIRECTORY ...
>
> Making things simpler from the standpoint of the code isn't the point.
> Making things simpler for the DBA and/or Unix sys
On Thu, 23 Jan 2003 11:19:36 -0700 (MST)
"scott.marlowe" <[EMAIL PROTECTED]> wrote:
> On 23 Jan 2003, Hannu Krosing wrote:
>
> > Curt Sampson kirjutas N, 23.01.2003 kell 17:42:
> > > If the OS can handle the scheduling (which, last I checked, Linux couldn't,
> >
> > When did you do your checking
Hi!
Insert function of any type of index must returns palloced InsertIndexResult
(contains blkno and offset).
This result is returned by index_insert (backend/access/indexam/indexam.c).
This function is called in 3 places:
./access/heap/tuptoaster.c
./catalog/indexing.c
./executor/execUtils.c
Bu
Le Mercredi 12 Février 2003 15:49, Merlin Moncure a écrit :
> I think there should be a special mailing list set up called
> pg-sql-win32-advocacy where people can continually harass the postgres
> dev team and debate the merits of the win32 operating system.
I realize my views about PostgreSQL
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> [ why do we have InsertIndexResult and not just a bool? ]
Good question. Perhaps it was used once upon a time? That API has been
like that since Berkeley days.
I can't offhand see a good reason to return the index tuple's tid.
There isn't any legitima
On Tue, 2003-02-11 at 21:00, Tatsuo Ishii wrote:
> >
> > while 200 may seem high, 32 definitely seems low. So, what IS a good
> > compromise? for this and ALL the other settings that should probably be a
> > bit higher. I'm guessing sort_mem or 4 or 8 meg hits the knee for most
> > folks, an
On Tue, Feb 11, 2003 at 05:25:29PM -0700, Rick Gigger wrote:
> The type of person who can't configure it or doesnt' think to try is
> probably not doing a project that requires any serious performance.
I have piles of email, have fielded thousands of phone calls, and
have had many conversations w
Well said
I was just trying to be funny. Since we are all programmers here, I'll try and
re-express my thought in a (somewhat) portable language:
char HackerThought[] = "Maybe there really is something to this windows business.
Perhaps its time to consider a port".
int iAnnoyanceLevel = 0;
Pe
On Wed, 2003-02-12 at 11:39, Andrew Sullivan wrote:
> On Tue, Feb 11, 2003 at 05:25:29PM -0700, Rick Gigger wrote:
>
> > The type of person who can't configure it or doesnt' think to try is
> > probably not doing a project that requires any serious performance.
>
> I have piles of email, have fie
On Wed, 2003-02-12 at 10:36, Robert Treat wrote:
> On Tue, 2003-02-11 at 21:00, Tatsuo Ishii wrote:
> > >
> > > while 200 may seem high, 32 definitely seems low. So, what IS a good
> > > compromise? for this and ALL the other settings that should probably be a
> > > bit higher. I'm guessing s
On Tue, Feb 11, 2003 at 05:32:58PM -0700, scott.marlowe wrote:
> So, what OSes would have a problem, if any, with boosting something
> like max connects to 200? What are the breaking points on other OSes?
Solaris 8 broke at 200, the last time I tried on a new box. 150
didn't break it, though.
Robert Treat <[EMAIL PROTECTED]> writes:
> Had this happen at a previous employer, and it definitely is bad. I
> believe we had to do a reboot to clear it up. And we saw the problem a
> couple of times since the sys admin wasn't able to deduce what had
> happened the first time we got it. IIRC the
I can't offhand see a good reason to return the index tuple's tid.
One reason why existing interface is not good:
Who say, that for one heap tuple should exists only one index tuple?
For example, Oleg and Vadim Mikheev had discussian pair years ago about
indexing arrays by B-tree: for each heap t
On Wed, 12 Feb 2003, GB Clark wrote:
> On Thu, 23 Jan 2003 11:19:36 -0700 (MST)
> "scott.marlowe" <[EMAIL PROTECTED]> wrote:
>
> > On 23 Jan 2003, Hannu Krosing wrote:
> >
> > > Curt Sampson kirjutas N, 23.01.2003 kell 17:42:
> > > > If the OS can handle the scheduling (which, last I checked, Li
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> One reason why existing interface is not good:
> Who say, that for one heap tuple should exists only one index tuple?
Good point. Is that reason enough to change it? Not sure. The index
AM doesn't really have to bother with telling the truth in the
In
Ran into this in cvs tip checked out as of yesterday:
db=> SELECT sum(CASE WHEN (upper(substr((select 'en'::varchar),1,1)) not between 'A'
and 'Z') THEN 1 ELSE 0 END) AS n FROM tab;
ERROR: transformExpr: does not know how to transform node 309 (internal error)
309 is T_FuncExpr. Is this a no
On Tue, 11 Feb 2003, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > ... If he starts running out of semaphores, that's a
> > problem he can address while his database is still up and running in most
> > operating systems, at least in the ones I use.
>
> Back in the day, this
Oh, another setting that should be a "default" for most users is to initdb
automatically with locale of C. If they need a different locale, they
should have to pick it.
The performance of Postgresql with a locale other than C when doing like
and such is a serious ding. I'd much rather have th
I've been thinking hard for the last few days about how to do space
reclamation in b-tree indexes, i.e., recycle pages that are in
no-longer-useful portions of the tree structure. We know we need this to
solve the "index bloat" problem that occurs when the distribution of keys
changes over time.
Tom Lane writes:
> Well, as I commented later in that mail, I feel that 1000 buffers is
> a reasonable choice --- but I have to admit that I have no hard data
> to back up that feeling.
I know you like it in that range, and 4 or 8 MB of buffers by default
should not be a problem. But personally
hi, does anyone know what lockmethod means in the lock.h file and whats the use of lockmethodTable.?
thank you
SumairaAdd photos to your messages with MSN 8. Get 2 months FREE*.
In a plpython trigger, if you return "MODIFY", the parsing of the
TD["new"] dictionary uses the wrong (c array) index to locate the
atttypmod value, leading to subtle bugs dependent on the exact types,
names, and order of fields in the table in question.
(Types need to be those that use the typmod
Christopher Kings-Lynne wrote:
>
>I reckon that sort_mem is the hardest thing to optimise1
>
Agreed... in part because it depends a lot on the query.
Also, if I understand correctly sort_mem not only affects sorts
but also hash table stuff as well, right? If that's true for
the new hash aggrega
Tom Lane wrote:
The deletion procedure could be triggered immediately upon removal of the
last item in a page, or when the next VACUUM scan finds an empty page.
Not sure yet which way is better.
Having it triggered immediately upon removal of the last item in a page
would make for a more "self
> Okay, here's one: most Unix systems store all of the configuration
> files in a well known directory: /etc. These days it's a hierarchy of
> directories with /etc as the root of the hierarchy. When an
> administrator is looking for configuration files, the first place he's
> going to look is in
> Had this happen at a previous employer, and it definitely is bad. I
> believe we had to do a reboot to clear it up. And we saw the problem a
> couple of times since the sys admin wasn't able to deduce what had
> happened the first time we got it. IIRC the problem hit somewhere around
> 150 connec
> Seriously, I know Linux can change these on the fly, and I'm pretty sure
> Solaris can too. I haven't played with BSD for a while so can't speak
> about that. Anyone else know?
You cannot change SHMMAX on the fly on FreeBSD.
Chris
---(end of broadcast)-
> > binaries (he doesn't necessarily have access to the sources that the
> > binaries were compiled from, which is all that matters here).
>
> No goddammit - /usr/local/etc. Why can't the Linux community respect
> history
History? It's the only way to make a read-only / (enforced by
secure-
I'm still getting failure, but it gets weirder:
regression=# drop table timetz_tbl;
DROP TABLE
regression=# CREATE TABLE TIMETZ_TBL (f1 time(2) with time zone);
INSERT INTO TIMETZ_TBL VALUES ('00:01 PDT');
CREATE TABLE
regression=#
regression=# INSERT INTO TIMETZ_TBL VALUES ('00:01 PDT');
INSERT
On Wednesday 12 February 2003 20:37, Christopher Kings-Lynne wrote:
> > Okay, here's one: most Unix systems store all of the configuration
> > files in a well known directory: /etc. These days it's a hierarchy of
> No [snip] - /usr/local/etc. Why can't the Linux community respect
> history
Justin Clift <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The deletion procedure could be triggered immediately upon removal of the
>> last item in a page, or when the next VACUUM scan finds an empty page.
>> Not sure yet which way is better.
> Having it triggered immediately upon removal of t
Oops - just to clarify I accidentally copied too many INSERTs into the
email. The result of the first SELECT is correct compared to the INSERTs
that I did. I copied the INSERTs and CREATE TABLE as-is from timetz.sql
Chris
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMA
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> What the heck!!?!?!?! The SELECT statement has somehow edited
>> the data in the table or something??? From this point forward,
>> the table is all stuffed...
Hm, time to dig out the debugger and figure out where the breakage
is. Do you w
I've been playing around with the source for psql, and as a result I
did some cleaning up in common.c. Would anyone be interested in seeing
patches for that? The main benefit is some eliminated code duplication,
plus the removal of some warts like 'continue' and 'break' where they
weren't needed.
> Christopher Kings-Lynne wrote:
> > > Someone asked about this at FOSDEM. The only way I know to do it is look
> > > in the pgsql_temp directory, but they disappear pretty quickly. Folks,
> > > do we need something to report sort file usage?
Fwiw here's the perl one-liner I used to tune sort_me
While using PL/R in a web based application, I noticed that the library
load and initialization time is significant enough to be annoying. So I
wrote a quick hack to load and initialize the library on postmaster
startup. This way, the backends get a fully initialized copy of the
interpreter when th
Greg Stark wrote:
> Not a big deal though, since I doubt anyone's actually parsing
> postgres logs. Hm, brings up an interesting idea though, I wonder
> if it would be useful to log directly into postgres tables.
I was wondering roughly the same thing. If you ran an external
program to process t
Joe Conway <[EMAIL PROTECTED]> writes:
> 2. It seems to me that other libraries such as those for PL/Tcl,
> PL/Perl, etc may have the same issue. Is there any merit in
> a GUC variable to allow libraries such as this to be loaded
> and initialized at postmaster start? I'll generaliz
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> I've been playing around with the source for psql, and as a result I
> did some cleaning up in common.c. Would anyone be interested in seeing
> patches for that? The main benefit is some eliminated code duplication,
> plus the removal of some wa
Joe Conway <[EMAIL PROTECTED]> writes:
> [ what about autoloading libraries into the postmaster? ]
I can see a couple possible downsides: (a) the library might have some
weird behavior across fork boundaries; (b) the additional memory space
that has to be duplicated into child processes will cost
Hi Everyone,
I've just spent the last day and a half trying to benchmark our new database
installation to find a good value for wal_buffers. The quick answer - there
isn't, just leave it on the default of 8.
The numbers just swing up and down so much it's impossible to say that one
setting is be
At 12:31 AM -0500 2/13/03, mlw wrote:
The idea that a, more or less, arbitrary data location determines
the database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do it.
Isn't the database d
On Thu, 2003-02-13 at 00:16, Christopher Kings-Lynne wrote:
> Even if you look at the attached charts and you think that 128 buffers are
> better than 8, think again - there's nothing in it. Next time I run that
> benchmark it could be the same, lower or higher. And the difference between
> the w
Peter Bierman wrote:
At 12:31 AM -0500 2/13/03, mlw wrote:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to do it
>>>Bruce Momjian said:
[...]
> For example, we can ask them how many rows and tables they will be
> changing, on average, between VACUUM runs. That will allow us set the
> FSM params. We can ask them about using 25% of their RAM for shared
> buffers. If they have other major apps running on
Before I get started, I should note that it may be a good compromise
to have the data directory be the same as the config file directory,
when neither the config file nor the command line specify something
different. So the changes I think may make the most sense are:
1. We add a new GUC variab
Patch applied. Thanks.
---
Ross J. Reedstrom wrote:
> On Fri, Jan 10, 2003 at 11:02:55PM +0100, Peter Eisentraut wrote:
> > Ross J. Reedstrom writes:
> >
> > > I already posted a one-line patch to implement this, but it d
Bruce Momjian <[EMAIL PROTECTED]> writes:
> One nice thing is that each element is orthoginal. But, for the
> functionality desired, we have to merge log_statement and log_duration
> and have it print for statements taking over X milliseconds. I have no
> problem adding it, but it has to be clear
> > One option is to have log_query output an identifier with the query such as a
> > hash of the query or the pointer value for the plan, suppressing duplicates.
> > Then log_duration prints the identifier with the duration.
> Actually, log_pid is the proper way to do this. You can then add lo
Dear Friends,
As a minor contributor to pgAdmin, I would like to express ideas as regards
the Windows port. As a personal point of view, it may or may not reflect the
community ideas, who knows. Don't flame me too much, I am only a casual user
of PostrgreSQL...
On Tue, 2003-02-11 at 20:17, Bruce Momjian wrote:
> I hate to poo-poo this, but this "web of trust" sounds more like a "web
> of confusion". I liked the idea of mentioning the MD5 in the email
> announcement. It doesn't require much extra work, and doesn't require a
> 'web of %$*&" to be set up t
Hi Ishii-san,
Thanks for the reply. Why was the particular change made between 7.2 and
7.3? It seems to have moved away from the standard. I found the
following file...
src/backend/utils/mb/Unicode/UCS_to_EUC_JP.pl
Which generates the mappings. I found it references 3 files from unicode
organisa
I don't see any jdbc specific requirements here, other than the fact
that jdbc assumes that the following conversions are done correctly:
dbcharset <-> utf8 <-> java/utf16
where the dbcharset to/from utf8 conversion is done by the backend and
the utf8 to/from java/utf16 is done in the jdbc driv
Someone at Red Hat is working on point-in-time recovery, also known as
incremental backups. It will be in 7.4.
---
Martin Marques wrote:
> How's this issue going on the 7.4 development tree?
> I saw it on the TODO list, but
Or create a sequence, and make each table in the inheritance hierarchy
use the same sequence as it's default value.
---
Oliver Elphick wrote:
> On Sat, 2003-02-08 at 19:34, Samuel Sieb wrote:
> > Is there any workaround for
Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > > Looking at the log_duration postgresql.conf option. How about adding an
> > > option log_duration_min which is a value in milliseconds that is the minimum
> > > time a query
It is going to be non-threaded in 7.4. SRA may contribute their
threaded version to a future release of PostgreSQL, but I don't think it
will be 7.4. We are using PeerDirect's Win32 port, with a few
improvements from SRA's port (minus their thread changes). I am going
to work on it in March.
-
> Someone at Red Hat is working on point-in-time recovery, also known as
> incremental backups. It will be in 7.4.
Does that mean that the poor guy/gal is implementing redo for all the index
types?
Chris
---(end of broadcast)---
TIP 3: if posting
--On Thursday, February 13, 2003 09:47:28 +0800 Christopher Kings-Lynne
<[EMAIL PROTECTED]> wrote:
Seriously, I know Linux can change these on the fly, and I'm pretty sure
Solaris can too. I haven't played with BSD for a while so can't speak
about that. Anyone else know?
You cannot change S
> Tom is right here. log_duration _just_ prints the duration, so we would
> need to basically create a merged param that does log_duration and
> log_statement and have it activate only if the statement takes more than
> X milliseconds, something like log_long_statement, or something like
> that.
>
Christopher Kings-Lynne wrote:
> > Someone at Red Hat is working on point-in-time recovery, also known as
> > incremental backups. It will be in 7.4.
>
> Does that mean that the poor guy/gal is implementing redo for all the index
> types?
No idea.
--
Bruce Momjian| h
Christopher Kings-Lynne wrote:
> > Tom is right here. log_duration _just_ prints the duration, so we would
> > need to basically create a merged param that does log_duration and
> > log_statement and have it activate only if the statement takes more than
> > X milliseconds, something like log_long
> Someone asked about this at FOSDEM. The only way I know to do it is look
> in the pgsql_temp directory, but they disappear pretty quickly. Folks,
> do we need something to report sort file usage?
How about a new GUC variable: log_sort_tempfiles
And in the code that creates the temp file, if th
Christopher Kings-Lynne wrote:
> > Seriously, I know Linux can change these on the fly, and I'm pretty sure
> > Solaris can too. I haven't played with BSD for a while so can't speak
> > about that. Anyone else know?
>
> You cannot change SHMMAX on the fly on FreeBSD.
And part of the reason is
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> wrote:
> > Okay, here's one: most Unix systems store all of the configuration
> > files in a well known directory: /etc. These days it's a hierarchy of
> > directories with /etc as the root of the hierarchy. When an
> > administrator is looking for
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I know you like it in that range, and 4 or 8 MB of buffers by default
> should not be a problem. But personally I think if the optimal buffer
> size does not depend on both the physical RAM you want to dedicate to
> PostgreSQL and the nature and size
Well, part of the issue here is that it isn't always bad to use sort
file; certainly it is better to use them than to swap.
We have a checkpoint_warning in 7.4 that will warn about excessive
checkpointing. What would our criteria be for warning about sort_mem?
Seems we would have to know how m
Bruce Momjian <[EMAIL PROTECTED]> writes:
> It would be nice if VACUUM FULL would be able to compress the actual
> index file and return unused space to the operating system. REINDEX
> does this, but I was thinking of something a little lighter that could
> be done automatically as part of VACUUM
>> You cannot change SHMMAX on the fly on FreeBSD.
I think we suffered some topic drift here --- wasn't the last question
about whether SEMMAX can be increased on-the-fly? That wouldn't have
anything to do with memory-mapping strategies...
regards, tom lane
-
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > It would be nice if VACUUM FULL would be able to compress the actual
> > index file and return unused space to the operating system. REINDEX
> > does this, but I was thinking of something a little lighter that could
> > be done automa
I think having VACUUM record free index pages just like free heap pages
makes perfect sense, and is consistent.
This brings up one item it would be nice to address at the same time.
It would be nice if VACUUM FULL would be able to compress the actual
index file and return unused space to the ope
Sure. Shoot them over.
---
Jeroen T. Vermeulen wrote:
> I've been playing around with the source for psql, and as a result I
> did some cleaning up in common.c. Would anyone be interested in seeing
> patches for that? The
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > One nice thing is that each element is orthoginal. But, for the
> > functionality desired, we have to merge log_statement and log_duration
> > and have it print for statements taking over X milliseconds. I have no
> > problem adding
Tom Lane wrote:
Kevin Brown <[EMAIL PROTECTED]> writes:
I assume $PGDATA was around long before GUC?
Yes, it was. But I have not yet seen an argument here that justifies
why $SOMECONFIGDIRECTORY/postgresql.conf is better than
$PGDATA/postgresql.conf. The latter keeps
Christopher Kings-Lynne wrote:
> I'm not sure what I could test next. Does FreeBSD support anything other
> than fsync? eg. fdatasync, etc. I can't see it in the man pages...
You are already getting the best default for your OS. It say 'fsync'
for default, but the comment says the default is O
mlw <[EMAIL PROTECTED]> writes:
> The idea that a, more or less, arbitrary data location determines the
> database configuration is wrong. It should be obvious to any
> administrator that a configuration file location which controls the
> server is the "right" way to do it.
I guess I'm just den
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right" way to d
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Well, as I commented later in that mail, I feel that 1000 buffers is
> > a reasonable choice --- but I have to admit that I have no hard data
> > to back up that feeling.
>
> I know you like it in that range, and 4 or 8 MB of buffers by default
> s
88 matches
Mail list logo
