Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Tom Lane wrote:
>>> Ah, I finally realize why Magnus wanted to add a --bindir option to
>>> pg_regress: there's no other way to cope with testing a relocated
>>> installation. Seems better to call it --psqldir though, since th
Peter, I'll test the patch on Solaris. Thanks!
Regards,
-Robert
Peter Eisentraut wrote:
Here is a consolidated patch that contains all the files. I made some
configure and makefile adjustments and put standard comment headers in
all the files. You can use DTRACEFLAGS to pass options to co
Peter Eisentraut wrote:
Robert Lor wrote:
The user needs to have the flexibility to build a 32 bit PG binary
even when he run the 64 bit kernel. If I understand you correctly,
your suggestion will not allow a 32 bit binary to be built on a 64
bit OS.
I'm not sure about the context. H
Tom Lane wrote:
Also, it'd be interesting to count time spent holding shared lock
separately from time spent holding exclusive.
Tom,
Here is the break down between exclusive & shared LWLocks. Do the
numbers look reasonable to you?
Regards,
-Robert
bash-3.00# time ./Tom_lwlock_acquire.d
The cygwin buildfarm is failing:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=eel&dt=2006-07-21%2015:00:01
initdb failed
Examine ./log/initdb.log for the reason.
initdb.log is empty, but a dialog box pops up saying:
"initdb.exe - Unable To Locate DLL"
"The dynamic link library cygpq.dll coul
On Thursday 20 July 2006 18:16, Ron Mayer wrote:
> Peter Eisentraut wrote:
> > I think it would be useful to allow units to be added to these settings,
> > for example...
> > shared_buffers = 512MB
> > which is a bit cumbersome to calculate right now (you'd need = 65536).
> >
> > I haven't thought
Peter Eisentraut wrote:
Tom Lane wrote:
Ah, I finally realize why Magnus wanted to add a --bindir option to
pg_regress: there's no other way to cope with testing a relocated
installation. Seems better to call it --psqldir though, since the
only thing we need to find in that case is psql.
Tom Lane wrote:
> Ah, I finally realize why Magnus wanted to add a --bindir option to
> pg_regress: there's no other way to cope with testing a relocated
> installation. Seems better to call it --psqldir though, since the
> only thing we need to find in that case is psql.
Well, if the ecpg tests
Is this possible today in a stable and robust way? If so, can we
document the procedure? If not, should we alter the documentation so
it's not misleading? I've had several people ask me where to enable the
"hot standby" feature, not realizing that PostgreSQL only has some of
the raw materials
The documentation [1] says this about On-line backup and point-in-
time recovery:
If we continuously feed the series of WAL files to another machine
that has been loaded with the same base backup file, we have a "hot
standby" system: at any point we can bring up the second machine
and it w
Hi korry-san.
From: "korry"
>
> > I'm unqualified to comment on the server side design, but I was
> > wondering if there was consensus on how the client interface to the
> > debugger would work. From previous threads I saw DBGP mentioned
> > (http://xdebug.org/docs-dbgp.php), but I don't re
Hannu Krosing wrote:
Ühel kenal päeval, R, 2006-07-21 kell 13:29, kirjutas Andrew Dunstan:
What you are asking is essentially the equivalent of asking "How long is
a piece of string?" The question is meaningless and so will be any
answer. The fact that there are web sites which are happy to
So I would like either some mention of the more useful/stable modules
in core docs or a way for contrib modules to become 'official' add-on
modules (like PL-s are).
This is actually an issue that goes way beyond pgcrypto. I think the
manual should formally mention both /contrib and pgFoundry.
Ühel kenal päeval, R, 2006-07-21 kell 13:29, kirjutas Andrew Dunstan:
> What you are asking is essentially the equivalent of asking "How long is
> a piece of string?" The question is meaningless and so will be any
> answer. The fact that there are web sites which are happy to supply you
> with m
On Tue, Jul 18, 2006 at 03:37:52PM +0300, Marko Kreen wrote:
> On 7/14/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> >I don't see a strong need for moving pgcrypto into core, and there's at
> >least one argument against it: if someone needs a crypto-free version of
> >postgres for use someplace with be
When the plugin's shared library gets loaded, one way or the other,
it should construct the function-pointer struct and then pass it to a
function defined by plpgsql (this lets us hide/postpone the decision
about whether there can be more than one active plugin).
I forgot to note, that this patch doesn't contains last improvements Teodor
did on Code Sprint - significant speedup of index creation.
Oleg
On Fri, 21 Jul 2006, Monica D'Arcy wrote:
I thought I had successfully added the patch for gin support to my 8.1.4
installation, however I get the error:
You need initdb
Oleg
On Fri, 21 Jul 2006, Monica D'Arcy wrote:
I thought I had successfully added the patch for gin support to my 8.1.4
installation, however I get the error: access method "gin" does not exist.
There is no record for the "gin" index in the pg_am table, which I assume
needs to
I thought I had successfully added the patch for gin support to my
8.1.4 installation, however I get the error: access method "gin" does
not exist. There is no record for the "gin" index in the pg_am
table, which I assume needs to be present. I have restarted
postgres. Is there anything
korry <[EMAIL PROTECTED]> writes:
>> I see no good reason to tie
>> it to plpgsql; we'll just need another one for every other language.
>>
> Hmmm... but the plugins themselves would be language-specific.
You miss my point. The plugins will be language-specific but the
mechanism for selecting/lo
I'm unqualified to comment on the server side design, but I was
wondering if there was consensus on how the client interface to the
debugger would work. From previous threads I saw DBGP mentioned
(http://xdebug.org/docs-dbgp.php), but I don't recall seeing any final
commitment to it.
The patc
Hi Korry,
On Jul 21, 2006, at 12:51 PM, korry wrote:
Sorry to poke - but I'd like to get a patch submitted next week.
Any more comments? Thanks.
I'm unqualified to comment on the server side design, but I was
wondering if there was consensus on how the client interface to the
debugger
What you are asking is essentially the equivalent of asking "How long is
a piece of string?" The question is meaningless and so will be any
answer. The fact that there are web sites which are happy to supply you
with meaningless information doesn't mean we should follow suit.
And frankly, I
> [snip] Suppose that every
> body say me that POStgres is to slow for real time databases, then I will be
> very full trying to resolve this problems with postgres, don't think that?
I think you didn't understand correctly: postgres is not slow, it is
just not suitable for real RT applications be
Hello,
Thanks for your answer.
Maybe I asking a wrong question, but I just need some ideas like you say
that posgres can insert 100,000 rows per second, is a good approximation...
In other hand if you visit some links like
http://developer.db4o.com/forums/post/25599.aspx
You will find something li
Gavin, Peter,
> I would imagine that Peter intends to handle backward compatibility by
> processing values without explicit units in the units assumed pre <8.2.
Aha, I misunderstood.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)
Sorry to poke - but I'd like to get a patch submitted next week. Any
more comments? Thanks.
-- Korry
Thanks
for the quick feedback.
1) I think the most straightforward way to load an instrumentation
plugin is to define a new custom GUC variable (using the
custom_v
Robert Lor wrote:
> The user needs to have the flexibility to build a 32 bit PG binary
> even when he run the 64 bit kernel. If I understand you correctly,
> your suggestion will not allow a 32 bit binary to be built on a 64
> bit OS.
I'm not sure about the context. How do you control whether the
On Fri, Jul 14, 2006 at 08:08:11PM +0200, Stefan Kaltenbrunner wrote:
> Greg Sabino Mullane wrote:
> >
> Doesn't our inclusion of md5() pretty much blow that argument away?
> (Just asking).
> >>> I don't think so because md5 is just a one way hash function. There
> >>> is no method to de
We apologize for multiple receipts.
Eighth Real-Time Linux Workshop
October 12-15, 2006
Lanzhou University - SISE
korry wrote:
How about the obvious DTRACE( ) or some similar variant?
The idea is to keep the macro name generic since it can be mapped to
other tracing facility on other platforms.
Regards,
-Robert
---(end of broadcast)---
TIP 9: In ver
Tom Lane wrote:
Those numbers look a bit suspicious --- I'd expect to see some of the
LWLocks being taken in both shared and exclusive modes, but you don't
show any such cases. You sure your script is counting correctly?
I'll double check to make sure no stupid mistakes were made!
Also, it
Peter Eisentraut wrote:
I would prefer to drop the PG_ prefixes on PG_TRACE and pg_trace.h. We
know which software we're dealing with.
I also agree with Martin & Tom to keep the PG_ prefixes.
We should probably move the probes file to a subdirectory. Anyone know
a good place?
Also, a
korry <[EMAIL PROTECTED]> writes:
> How about the obvious DTRACE( ) or some similar variant?
Because it's supposed to be generic, ie, not strictly tied to DTrace.
(I'm not sure there is any realistic other alternative at the moment,
but that's the idea...)
regards, to
Hi,
Tom Lane schrieb:
> Robert Lor <[EMAIL PROTECTED]> writes:
>> I ran pgbench and fired up a DTrace script using the lwlock probes we've
>> added, and it looks like BufMappingLock is the most contended lock, but
>> CheckpointStartLocks are held for longer duration!
>
> Those numbers look a b
On Fri, Jul 21, 2006 at 01:42:26PM +0200, Peter Eisentraut wrote:
I would prefer to drop the PG_ prefixes on PG_TRACE and pg_trace.h. We
know which software we're dealing with.
I don't know. "trace" is a fairly generic word, how do you know
Martijn van Oosterhout writes:
> On Fri, Jul 21, 2006 at 01:42:26PM +0200, Peter Eisentraut wrote:
>> I would prefer to drop the PG_ prefixes on PG_TRACE and pg_trace.h. We
>> know which software we're dealing with.
> I don't know. "trace" is a fairly generic word, how do you know that
> none of
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 21 July 2006 15:20
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] BF Failure on Bandicoot
>
> "Dave Page" writes:
> > Bandicoot is currently failing on HEAD with the following
> erro
"Dave Page" writes:
> Bandicoot is currently failing on HEAD with the following error shown in
> a message box during make check:
> The procedure entry point ldap_start_tls_sA could not be located in the
> dynamic link library wldap32.dll.
Just guessing from the function name, but does this go
On Fri, Jul 21, 2006 at 09:38:41AM +0200, moises wrote:
> I want to know, in a hypothetical server, how many transaction postgres
> support for a first approximation.
>
> I found this data of MySQL and DB4o data bases but I can´t find any of
> Postgres.
I think you're asking the wrong question. I
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> No, this is 8.1.3, and it's a production machine so I'd prefer not to go
> about dropping indexes to get cost comparisons; unless there's some way
> to disable the use of an index in a given backend?
The traditional hack for that is
beg
On Thu, Jul 20, 2006 at 08:46:13PM -0400, Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > I'm liking this too. But when you say "jointree node", are you saying to
> > model the new node type after NestLoop/MergeJoin/HashJoin nodes? These
> > are referred to as "join nodes" in ExecIni
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> For clobbering xmin too early, we could make it so that only tuples
> older than some threashold would be subject to 'early freezing'.
OK, that might be acceptable.
> One
> possibility is that early freeze is at 1B transactions and we push
> forced-fre
On Fri, Jul 21, 2006 at 12:56:56AM -0700, Robert Lor wrote:
> I ran pgbench and fired up a DTrace script using the lwlock probes we've
> added, and it looks like BufMappingLock is the most contended lock, but
> CheckpointStartLocks are held for longer duration!
Not terribly surprising given th
Ühel kenal päeval, R, 2006-07-21 kell 08:29, kirjutas Jim C. Nasby:
> No, this is 8.1.3, and it's a production machine so I'd prefer not to go
> about dropping indexes to get cost comparisons; unless there's some way
> to disable the use of an index in a given backend?
Currently the closest thing
> Real time databases needs some other kinds of semantics and
> features that postgres don't have.
>
> Postgres don't supports real time constrains semantics in
> transactions. In other hands the concurrent transactions
> don't wok well based on priorities of task.
>
> The program scheduler o
Time units is easy:
1h = 60min = 3600s = 360ms
We don't need anything larger than seconds at the moment.
Except for log_rotation_age perhaps?
-- Korry
On Wed, Jul 19, 2006 at 07:45:24PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > ISTM that as soon as vacuum dirties a page, it might as well update all
> > tuples it can (any where Xmin < GetOldestXmin()), since that won't take
> > much time compared to the cost of writin
Robert Lor <[EMAIL PROTECTED]> writes:
> I ran pgbench and fired up a DTrace script using the lwlock probes we've
> added, and it looks like BufMappingLock is the most contended lock, but
> CheckpointStartLocks are held for longer duration!
Those numbers look a bit suspicious --- I'd expect to
Thanks for your answer,
I have experience with
postgres and I know perfectly that not a TOY.
But some concepts of real
time system don’t based only in speed.
Real time databases needs
some other kinds of semantics and features that postgres don’t have.
Postgres don’t supports re
On Wed, Jul 19, 2006 at 07:54:49PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Indeed, if I find a case where there's a large enough number of rows it
> > will choose the smaller index. But I'm wondering if it would be better
> > to always favor the smaller index, since
Ühel kenal päeval, R, 2006-07-21 kell 17:14, kirjutas Sandeep
Jakkaraju(Navolve):
> Hi All
>
>
> I am looking for a C/C++ library which can talk to postgresql/postgis
> other than libpqxx!!
Why ?
> thanx in advance
>
> sandeep
--
Hannu Krosing
Database Architect
Skype Techn
On Thu, Jul 13, 2006 at 07:17:31PM -0400, Tom Lane wrote:
> There has been talk of attaching a search_path setting to each function
> so that it's independent of the caller's search_path, but the
> performance hit seems a bit daunting. In any case it's not pg_dump's
> fault that this feature doesn
On Thu, 2006-07-20 at 15:41 -0400, Tom Lane wrote:
> Usage of a partitioned hash table would then be like
>
> compute hashtable lookup key;
> entryhashcode = calc_hash(lookup key);
> partitionnumber = entryhashcode % NumPartitions;
> LWLockAcquire(PartitionLock[partitionnu
On Jul 20, 2006, at 8:49 PM, Joshua D. Drake wrote:
It could be interesting to have something like this:
./configure --with-plruby
and it would actually fetch the latest plruby sources from the net
and build. Ala Ports.
Or if we didn't want to develop that infastructure of auto-fetchin
On Fri, Jul 21, 2006 at 01:42:26PM +0200, Peter Eisentraut wrote:
> Robert Lor wrote:
> > I've have attached a patch along with two new files.This patch should
> > reflect what we discussed at the Summit. Please let me know if I miss
> > anything.
>
> I would prefer to drop the PG_ prefixes on PG_
Hi All I am looking for a C/C++ library which can talk to postgresql/postgis other than libpqxx!!thanx in advancesandeep
Robert Lor wrote:
> I've have attached a patch along with two new files.This patch should
> reflect what we discussed at the Summit. Please let me know if I miss
> anything.
I would prefer to drop the PG_ prefixes on PG_TRACE and pg_trace.h. We
know which software we're dealing with.
> 1) The c
Bandicoot is currently failing on HEAD with the following error shown in
a message box during make check:
---
postgres.exe - Entry Point Not Found
---
The procedure entry point ldap_start_tls_sA could not be located in the
dynamic link library wldap3
Hi,
On Thu, Jul 20, 2006 at 02:36:53PM +0200, moises wrote:
> For example Inserts, Update, delete, etc.
If you need a storage for structured data, database servers are good to
go. If you need a very fast "flow" of not-so-needed and
okay-to-miss-we-can-regenerate type of data storage you can go wi
Tom Lane wrote:
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
18% in s_lock is definitely bad :-(. Were you able to determine which
LWLock(s) are accounting for the contention?
Sorry for the delay. Finally I got the oprofile data. It's
huge(34MB). If you are interested, I can put
61 matches
Mail list logo
