Is there any chance we could have initdb show the version of postgresql
it is running as when initdb is run?
If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the version number? In any
case, you can run initdb --version first if
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 TL
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 syst
Christopher Kings-Lynne writes:
> Is there any chance we could have initdb show the version of postgresql
> it is running as when initdb is run?
If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the version number? In any
case, y
> Another option would be to create thread local hashtable or other lookup
> structure to which you would register a structure for a particular .c
> file or group of files.
>
> You could then define the structures you need locally without
> affecting other parts of the codebase.
>
>
>
> Myr
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Sun, Sep 21, 2003 at 05:37:59PM +0200, Peter Eisentraut wrote:
> #: rewrite/rewriteDefine.c:274
> msgid "rules on SELECT rule must have action INSTEAD SELECT"
> Is this really the intended wording?
Seems like a typo to me too. Maybe "rules ON SELEC
Tom Lane wrote:
I assume you mean static as in not-auto, rather than static as in
not-global. Otherwise we have a problem here.
[...]
Surely the addresses can be assumed constant within a thread. Otherwise
we have a problem here too.
[...]
Taking addresses of TLS variables should be considered il
Hey guys,
Is there any chance we could have initdb show the version of postgresql
it is running as when initdb is run?
On my dev machine, i have all sorts of different versions in different
paths and sometimes you run initdb but it doesn't run the version I
think I'm running.
Outputting versi
On Sun, Sep 21, 2003 at 05:37:59PM +0200, Peter Eisentraut wrote:
> I've looked through the messages in the backend and identified some areas
> that still deserve some cleanup. Below I list some issues that deserve
> some discussion or that deserve being remembered by other developers.
Regarding
Check contrib/rtreegist
Chris
Zhen Yang wrote:
Thanks. Currently I am also referring to different implementations
of an index to see the most suitable to implement. For an R+ tree
( a variant of R tree ), I have found an example implementation in
C. Does anyone know of an R+ tree implementation
Hi guys,
I thought I'd pass this around as an interested reference page. Gives
us an idea of how far we need to go to compete with Oracle for data
analysis...
http://www.akadia.com/services/ora_analytic_functions.html
Interesting stuff:
* Accessing rows around your current row
* Lag, lead
* T
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Why is the subselect never executed for the inner select?
Fixed. I'm kinda surprised that code ever worked; it was trying to run
a sub-plan before the rest of the executor was set up.
regards, tom lane
-
On Fri, 26 Sep 2003 01:18 am, Greg Stark wrote:
> Well if you're only going to do one threading API you may as well pick the
> POSIX standard. Windows threading is only useful for windows, POSIX
> threading would work on every other OS, Solaris, Linux, BSD, etc.
>
> Is there a POSIX threads wrapper
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
Why is the subselect never executed for the inner select?
pgrocks=> SELECT VERSION() UNION ALL SELECT oid::text FROM pg_class WHERE ctid =
(SELECT ctid FROM pg_class LIMIT 1);
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> All TLS variables *must* be static (or implicitly static
> through extern, i.e. no 'auto' variables)
I assume you mean static as in not-auto, rather than static as in
not-global. Otherwise we have a problem here.
> and their addresses can not be
> a
On Thursday, September 25, 2003, at 10:03 AM, Tom Lane wrote:
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
One thing that can be done is to arrange all globals/statics in a
structure and make that structure thread local.
That's about as far from "non-invasive" as I can imagine :-(
I really, re
On Thu, 2003-09-25 at 13:26, Bruce Momjian wrote:
> scott.marlowe wrote:
> > On 25 Sep 2003, Robert Treat wrote:
> >
> > > oh.. and i'm not forgetting plphp, but it has both licensing issues and
> > > isn't ready for prime time.
> >
> > I thought there weren't any license issues, except mayhaps w
Hello,
Yes plPHP is under the BSD style PHP license. We are going to dual
license on next release which is REAL soon
now.
Sincerley,
Joshua Drake
Bruce Momjian wrote:
scott.marlowe wrote:
On 25 Sep 2003, Robert Treat wrote:
oh.. and i'm not forgetting plphp, but it has both licensin
Actually you can use a DLL with LoadLibrary as long as you do the following.
When a process uses load-time linking with this DLL, the entry-point
function is sufficient to manage the thread local storage. Problems can
occur with a process that uses run-time linking because the entry-point
function
On Thursday 25 September 2003 07:36, 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 s
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> On Wed, Sep 24, 2003 at 20:21:20 -0300,
> Maurício Paiva <[EMAIL PROTECTED]> wrote:
>> What we are trying to figure out is if postgresql supports
>> returning multiple result sets from a stored procedure (psql
>> function?)
> No, Postgres can't do
Both Microsoft and windows compilers support thread local storage. *If*
you guys go with the threading model and *if* it does not introduce any
serious portability issues with gcc (big ifs, and I'm not familiar with
gcc), than IMO TLS is really the way to go. I don't think any
reorganization of p
Hello,
Naturally, as I found this problem in a production database running 7.3.4, a
back-patch to 7.3 would be desireable. Even if just a patch was available
and was not commited to -STABLE, this would do. I would also then be able to
test such a critter on our development server for a futur
On Thu, 25 Sep 2003, Bruno Wolff III wrote:
> On Wed, Sep 24, 2003 at 20:21:20 -0300,
> Maurício Paiva <[EMAIL PROTECTED]> wrote:
> > What we are trying to figure out is if postgresql supports
> > returning multiple result sets from a stored procedure (psql
> > function?)
>
> No, Postgres c
I do not know for sure to what extent GCC supports TLS on Windows. There are
compiler extensions that can be used under Windows, like __declspec(thread)
which automagically handles the declaration and initialization of the TLS
variable rather than dynamically calling the TlsAlloc, TlsFree, TlsSetVa
I said:
> Okay, I'll work out some extension of the APIs to let us propagate the
> snapshot request down through SPI and into the Executor, rather than
> using a global variable for it. (Unless someone has a better idea...)
I've committed the attached patch into CVS HEAD. I am now wondering
whet
Zhen Yang <[EMAIL PROTECTED]> writes:
> Does anyone know of an R+ tree implementation done with GIST
> (generalized search tree)?
contrib/rtree_gist/ ought to be a starting point.
regards, tom lane
---(end of broadcast)---
T
On 25 Sep, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> I take it PQexec() should wait until the COMMIT finishes?
>
> Yeah, it does. Where is the next iteration of the transaction coming
> from?
>
> Another thought occurred to me --- you said you have many parallel
> instances of this transact
On Wed, Sep 24, 2003 at 20:21:20 -0300,
Maurício Paiva <[EMAIL PROTECTED]> wrote:
> What we are trying to figure out is if postgresql supports
> returning multiple result sets from a stored procedure (psql
> function?)
No, Postgres can't do that.
---(end of broadcast
scott.marlowe wrote:
> On 25 Sep 2003, Robert Treat wrote:
>
> > oh.. and i'm not forgetting plphp, but it has both licensing issues and
> > isn't ready for prime time.
>
> I thought there weren't any license issues, except mayhaps with the name.
>
> http://www.php.net/license/3_0.txt
That is w
On 25 Sep 2003, Robert Treat wrote:
> oh.. and i'm not forgetting plphp, but it has both licensing issues and
> isn't ready for prime time.
I thought there weren't any license issues, except mayhaps with the name.
http://www.php.net/license/3_0.txt
---(end of broadcast)
[EMAIL PROTECTED] wrote:
Hi All,
I'm attempting to build from CVS so I can get into a bit of PG dev work.
Are there any special tricks with the CVS build or is this a common error?
bison -y -d preproc.y
preproc.y:5276: warning: previous rule lacks an ending `;'
preproc.y:6294: fatal error: maxi
On Wednesday, Sep 24, 2003, at 19:10 Atlantic/Reykjavik, Bruce Momjian
wrote:
Philip Yarra wrote:
It's funny timing - I had to prepare a comparison between PostgreSQL
and
MySQL recently, explaining why we would prefer PostgreSQL. I know some
people here have issues with the MySQL crashme test res
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 system for 5-6 years
or so
What we are trying to figure out is if postgresql
supports returning multiple result sets from a stored
procedure (psql function?) For
example in MSSQL's Northwind database you can create the
following stored procedure:
CREATE PROCEDURE
"test" AS SELECT * FROM
Orders SELECT * FROM
Andrew Dunstan wrote:
Tom Lane wrote:
BTW, I've been wondering lately if we'd not be better off to look at
using threading in the Windows port, if it'd help us get around the
fork/exec data transfer problem. I'm not sure that it would, mind you,
but if it would give an answer it might be a lot l
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> One thing that can be done is to arrange all globals/statics in a
> structure and make that structure thread local.
That's about as far from "non-invasive" as I can imagine :-(
I really, really want to avoid doing anything like the above, because
On 25 Sep, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> I've been observing a interesting behavior with our DBT-2 workload.
>
> AFAICS the only possible explanation for this is that you aren't
> actually waiting for the first transaction to commit before you start
> the second one. What is the
[EMAIL PROTECTED] writes:
> I take it PQexec() should wait until the COMMIT finishes?
Yeah, it does. Where is the next iteration of the transaction coming
from?
Another thought occurred to me --- you said you have many parallel
instances of this transaction, but they affect different rows becaus
On 25 Sep, Gaetano Mendola wrote:
> [EMAIL PROTECTED] wrote:
>
>> 2. SELECT d_next_o_id
>>INTO current_o_id
>>FROM district
>>WHERE d_w_id = 1
>>AND d_id = 8
>>
>> 3. UPDATE district
>>SET d_next_o_id = d_next_o_id + 1
>>WHERE d_w_id = 1
>>AND d_id = 8
>
> I don't kn
Keith Bottner wrote:
> Typically variables that you want to be per-thread are stored in what
> Microsoft calls Thread Local Storage (TLS). Variables that you want shared
> you can just treat as globals and statics with the appropriate threading
> synchronization primitives. With Windows 2000 and la
Thanks. Currently I am also referring to different implementations
of an index to see the most suitable to implement. For an R+ tree
( a variant of R tree ), I have found an example implementation in
C. Does anyone know of an R+ tree implementation done with GIST
(generalized search tree)? Since a
Typically variables that you want to be per-thread are stored in what
Microsoft calls Thread Local Storage (TLS). Variables that you want shared
you can just treat as globals and statics with the appropriate threading
synchronization primitives. With Windows 2000 and later you have up to 1088
TLS l
On 25 Sep, Zeugswetter Andreas SB SD wrote:
>
>> > >> > Are those response times in the right unit? 7-10s?
>> >
>> > No problem: http://developer.osdl.org/markw/misc/plana.out
>>
>> Ok, I guess I misunderstood you. These queries are taking 0.5ms - 300ms except
>> for the last aggregate query whic
Tom Lane wrote:
Claudio Natoli <[EMAIL PROTECTED]> writes:
How are you dealing with the issue of wanting some static variables to
be per-thread and others not?
To be perfectly honest, I'm still trying to familiarize myself with the code
sufficiently well so that I can tell which varia
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 which for su
On Thu, 2003-09-25 at 07:12, Peter Eisentraut wrote:
> mlg3 writes:
> > Now, how do I include my PL into the build list?
> > What files must I provide? (preferrably, by borrowing
> > them from another PL, e.g. PLPERL or TCL])
>
> There is currently some disagreement about whether every now procedu
Tom Lane wrote:
Claudio Natoli <[EMAIL PROTECTED]> writes:
How are you dealing with the issue of wanting some static variables to
be per-thread and others not?
To be perfectly honest, I'm still trying to familiarize myself with the code
sufficiently well so that I can tell which variables need
Tom Lane <[EMAIL PROTECTED]> writes:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > Considering this could be a configure time option, you mean to say
> > that even on Unix we could get threaded postgresql which would not
> > require any shared buffers but instead operate upon local shared
Claudio Natoli <[EMAIL PROTECTED]> writes:
>> How are you dealing with the issue of wanting some static variables to
>> be per-thread and others not?
> To be perfectly honest, I'm still trying to familiarize myself with the code
> sufficiently well so that I can tell which variables need to be per
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > FWIW, I've got a threaded version of the WIN32_DEV branch more or less
> > "running" (it is a terrible hack job, so NO, no patches... yet :-), as a
> > proof of concept. Still a work in progress (ok, I've qualified it
enough),
> > but it is showing
[EMAIL PROTECTED] writes:
> I've been observing a interesting behavior with our DBT-2 workload.
AFAICS the only possible explanation for this is that you aren't
actually waiting for the first transaction to commit before you start
the second one. What is the client doing exactly to issue these
qu
Claudio Natoli <[EMAIL PROTECTED]> writes:
> FWIW, I've got a threaded version of the WIN32_DEV branch more or less
> "running" (it is a terrible hack job, so NO, no patches... yet :-), as a
> proof of concept. Still a work in progress (ok, I've qualified it enough),
> but it is showing enough prom
Tom Lane writes:
> BTW, I've been wondering lately if we'd not be better off to look at
> using threading in the Windows port, if it'd help us get around the
> fork/exec data transfer problem. I'm not sure that it would,
> mind you, but if it would give an answer it might be a lot less painful
t
Tom Lane wrote:
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
Considering this could be a configure time option, you mean to say
that even on Unix we could get threaded postgresql which would not
require any shared buffers but instead operate upon local shared
buffers only?
Only if we were pr
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> BTW, I've been wondering lately if we'd not be better off to look at
>> using threading in the Windows port, if it'd help us get around the
>> fork/exec data transfer problem.
> When talking about threading in pgsql to Bruce on Linuxta
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> Considering this could be a configure time option, you mean to say
> that even on Unix we could get threaded postgresql which would not
> require any shared buffers but instead operate upon local shared
> buffers only?
Only if we were prepared to s
Tom Lane wrote:
BTW, I've been wondering lately if we'd not be better off to look at
using threading in the Windows port, if it'd help us get around the
fork/exec data transfer problem. I'm not sure that it would, mind you,
but if it would give an answer it might be a lot less painful than
solvin
Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
On Wed, 2003-09-24 at 13:11, Bruce Momjian wrote:
SRA's Windows port is up to 7.3.4, and I think they just released
version 1.1, so that is going fine --- and I have the source code to
use in our native Win32 port, just not the threa
Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
On Wed, 2003-09-24 at 13:11, Bruce Momjian wrote:
SRA's Windows port is up to 7.3.4, and I think they just released
version 1.1, so that is going fine --- and I have the source code to
use in our native Win32 port, just not the threading s
Robert Treat <[EMAIL PROTECTED]> writes:
> On Wed, 2003-09-24 at 13:11, Bruce Momjian wrote:
>> SRA's Windows port is up to 7.3.4, and I think they just released
>> version 1.1, so that is going fine --- and I have the source code to
>> use in our native Win32 port, just not the threading stuff.
>
mlg3 writes:
> I understand that pgsql uses autoconf but not other autotools.
> The best location for such contribution is in
> src/pl/pl
>
> Now, how do I include my PL into the build list?
> What files must I provide? (preferrably, by borrowing
> them from another PL, e.g. PLPERL or TCL])
There
> > >> > Are those response times in the right unit? 7-10s?
> >
> > No problem: http://developer.osdl.org/markw/misc/plana.out
>
> Ok, I guess I misunderstood you. These queries are taking 0.5ms - 300ms except
> for the last aggregate query which takes just over 1s.
Yes, but because this is a be
I want to make a contribution.
It is a new (to pgsql) procedural language.
Currently it already works (but debugging output
is not disabled yet).
I've got some questions and considerations, please, correct me
if I am wrong:
I understand that pgsql uses autoconf but not other autotools.
The best
64 matches
Mail list logo
