longlong wrote:
hi all,
msiexec /i D:\usr\local\postgre\postgresql-8.2-int.msi /qb INTERNALLAUNCH=1
ADDLOCAL=server,psql,docs SERVICEDOMAIN="%COMPUTERNAME%" CREATESERICEUSER=1
BASEDIR="d:\usr\local\postgres" SERVICEACCOUNT="postgres"
SERVICEPASSWORD="postgres" SUPERPASSWORD="11" PERMITREMOTE
Manish Jain wrote:
I have bytea column in one table and using C language, I am trying to
insert a binary data (having NULLs)
into bytea column, but it just inserts/updates till NULL reached.
Please let know whether I am missing something.
Probably, but you'll need to explain how you're doin
Manish Jain wrote:
> I have bytea column in one table and using C language, I am
> trying to insert a binary data (having NULLs)
>
> into bytea column, but it just inserts/updates till NULL reached.
>
> Please let know whether I am missing something.
I guess that when you say NULL you don't me
Thank you Tom,
> That sounds like your unspecified "remote client" has got some issues,
> but you've not provided any details that would let anyone else figure
> it out.
The referred client is a Windows psql 8.2.4 utility. This client is running
as part of a Windows PostgreSQL 8.2.4 server where w
Hi Erik,
> Are all of these remote connections from the same machine? Did you
> upgrade your client postgres libraries on your remote machine(s) as
> well?
No, the problem happens with many machines where our Visual Basic
applications is running. After debuging the application we discovered that
Hi all,
we use XMIN in our application (http://wiki.gnumed.de) as a
lightweight database-provided "data-changed" marker in a
cross-transaction optimistic locking scheme. The one
characteristic of XMIN we rely on in this scheme is that
"XMIN changes when a (writing) transaction commits
successfully
Hi there,
I need to calculate per Capita data on-the-fly. My table for a given
variable looks like this:
year|value |id_country
---
2001| 123 | 1
2002| 125 | 1
2003| 128 |
Karsten Hilbert <[EMAIL PROTECTED]> writes:
> How likely is XMIN (or equivalent) to become invisible to
> SQL level user space ?
No one has suggested this. I suppose the argument could be made that
the system columns are an unwarranted intrusion on users' column
namespace, but we'd probably h
From 8.3 beta release notes:
- ORDER BY ... NULLS FIRST/LAST
I think this is what you want right?
Yes, indeed. Sounds great. unfortunately I am on 8.1. And
wouldn't really want to migrate to 8.3 and beta for the moment
Thanks anyway!
Stef
---(end of broadca
On Thu, Oct 11, 2007 at 10:44:17AM -0400, Tom Lane wrote:
> The only argument you cited that seems impressive to me is the one
> about it being a Postgres-ism. Are you willing to have GNUmed tied
> tightly to Postgres?
Personally, yes, no problem and thanks for it :-))
Karsten
--
GPG key ID E4
It appears that the ORDER BY rank operation is the slowing factor.
If I remove it then the query is pretty fast. Is there another way
to perform ORDER BY such that it does not do a sort?
Benjamin
On Oct 5, 2007, at 3:57 PM, Benjamin Arai wrote:
On Oct 5, 2007, at 8:32 AM, Oleg Bartunov
On Thu, Oct 11, 2007 at 04:18:30PM +0100, Filip Rembiałkowski wrote:
> Subject: Re: [GENERAL] XMIN semantic at peril ?
>
> 2007/10/11, Tom Lane <[EMAIL PROTECTED]>:
> > The only argument you cited that seems impressive to me is the one
> > about it being a Postgres-ism. Are you willing to have GN
On Thu, Oct 11, 2007 at 10:44:17AM -0400, Tom Lane wrote:
> > How likely is XMIN (or equivalent) to NOT change on each
> > successful (write) transaction commit anymore ?
>
> No chance of that, unless we abandon MVCC for something else, which
> again seems highly unlikely.
I figured as much b
2007/10/11, Tom Lane <[EMAIL PROTECTED]>:
> The only argument you cited that seems impressive to me is the one
> about it being a Postgres-ism. Are you willing to have GNUmed tied
> tightly to Postgres?
Well, at least not in all aspects, if I may cut in.
(from http://www.gnumed.org/)
error
ins
Hi,
I've read through the relevant documentation on distributed transactions
for PostgreSQL 8.2.5 but it leaves me with more questions than answers.
It is unclear to me how SQL statements can be executed at remote nodes
from a single coordinator and then use distributed two-phase commit (via
'pre
Brian Oki (boki) wrote:
My question is this: How does PostgreSQL 8.2.5 execute DML statements
(insert, update, delete, select) on remote nodes as part of the same
transaction? Where is the syntax specified? Or, is there a different
model supported? It's sort of like the synchronous multi-master
r
Benjamin Arai <[EMAIL PROTECTED]> writes:
> It appears that the ORDER BY rank operation is the slowing factor.
> If I remove it then the query is pretty fast. Is there another way
> to perform ORDER BY such that it does not do a sort?
I think you misunderstood: it's not the sort that's slow,
Stefan Schwarzer skrev:
> Hi there,
>
> I need to calculate per Capita data on-the-fly. My table for a given
> variable looks like this:
>
> year|value |id_country
> ---
> 2001| 123 | 1
> 2002| 125 |
Karsten Hilbert <[EMAIL PROTECTED]> writes:
> On Thu, Oct 11, 2007 at 10:44:17AM -0400, Tom Lane wrote:
>> One question I'd have though is whether "freezing" of old tuples is
>> likely to confuse your app.
> Well, what we do is this:
> - read row including XMIN
> - do some UI stuff without open t
On Oct 11, 2007, at 11:03 AM, Tom Lane wrote:
Karsten Hilbert <[EMAIL PROTECTED]> writes:
On Thu, Oct 11, 2007 at 10:44:17AM -0400, Tom Lane wrote:
One question I'd have though is whether "freezing" of old tuples is
likely to confuse your app.
Well, what we do is this:
- read row includi
Oh, I see. I didn't look carefully at the EXPLAIN ANALYZE I posted.
So, is there a solution to the rank problem?
Benjamin
On Oct 11, 2007, at 8:53 AM, Tom Lane wrote:
Benjamin Arai <[EMAIL PROTECTED]> writes:
It appears that the ORDER BY rank operation is the slowing factor.
If I remove i
On 10/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > I'm curious what's considered the best way to invoke PG_GETARG_BYTEA_P
> > in an SPI routine and properly check for null input in non 'strict'
> > routines. Right now, I'm looking at PG_GETARG_POINT
Erik Jones <[EMAIL PROTECTED]> writes:
> If the query is always based on a primary key + XMIN, and since
> vacuum is the only thing that sets FrozenTransactionId, would it be
> unsane to change the update to
> - update row with "... where pk=... and XMIN IN (old_xmin_from_read,
> FrozenTransac
On Thu, Oct 11, 2007 at 01:48:10PM -0400, Tom Lane wrote:
> > If the query is always based on a primary key + XMIN,
It is.
> > and since
> > vacuum is the only thing that sets FrozenTransactionId, would it be
> > unsane to change the update to
>
> > - update row with "... where pk=... and XM
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> well, there aren't all that many examples in contrib, and some of the
> ones that are there look like this (edited) from tsearch2:
> Datum
> rewrite_accum(PG_FUNCTION_ARGS)
> {
> QUERYTYPE *acc = (QUERYTYPE *) PG_GETARG_POINTER(0);
> Arra
Hi all;
I decided that I wanted to bring this up here before I decide whether to
submit a proposal to -hackers. After all, this would reach a larger
section of users than would -hackers.
Basically, I think it would be very nice to be able to use client
vertificates to actually authenticate
On Thursday 11 October 2007 11:50, Richard Huxton wrote:
> Brian Oki (boki) wrote:
> > My question is this: How does PostgreSQL 8.2.5 execute DML statements
> > (insert, update, delete, select) on remote nodes as part of the same
> > transaction? Where is the syntax specified? Or, is there a differ
Randall Lucas <[EMAIL PROTECTED]> writes:
> Is there a way I can convince my custom composite data type (point_pk)
> to use the row-wise comparison functions, so that I don't have to
> hackishly rewrite the comparison algorithm for each composite type?
Well, you can do this ...
regression=# creat
Hi everyone,
I am trying to get the postgresql 8.2.5 version working on my opensolaris nv
73 server.
The configuration information is as follows:
SunOS db03nge0 5.11 snv_73 i86pc i386 i86pc
$ isainfo -v
64-bit amd64 applications
ahf sse3 sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmo
Hi Erik,
Thanks for the response. Your're the man!!! :) removal of -KPIC fixed it.
This is Solaris x86 AMD64. The system has 2 gb of RAM. I have not configured
any resource controls. I was thinking that the default should be fine for
the initial installation/compilation.
I was unable to build
The version sent yesterday was creating a LOT of unnecessary objects when
running queries with large result sets. I tweaked the postpres-pr classes (via
Ruby's very nice open class mechanism). The updated version is below...it took
queries running 10+ minutes down to around 20 seconds.
Thanks,
On Oct 11, 2007, at 2:30 PM, Dot Yet wrote:
Hi everyone,
I am trying to get the postgresql 8.2.5 version working on my
opensolaris nv 73 server.
The configuration information is as follows:
SunOS db03nge0 5.11 snv_73 i86pc i386 i86pc
$ isainfo -v
64-bit amd64 applications
ahf sse3
Some new data about this issue:
SELECT * or naming all the columns locks the client application. Yesterday
I´ve wrongly said that when naming all the columns instead of using the *
the applications did not lock.
I can not reproduce the problem in others 8.2.4 servers. I´ve others 8.2.4
servers a
On Thursday 11 October 2007, "Carlos H. Reimer"
<[EMAIL PROTECTED]> wrote:
> Don´t know but apparently the problem is not an issue in the client, as
> I´m able to connect and do the select * in other 8.2.4 servers.
>
> Don´t know what kind of tests I should do to help fixing this problem.
>
> Any
The documentation states that PostgreSQL does not support updating data via a
cursor.
Has that changed in the last little while.
Bob Pawley
Bob Pawley escribió:
The documentation states that PostgreSQL does not support updating
data via a cursor.
Has that changed in the last little while.
Bob Pawley
I think that is in 8.3 beta, take a look to release notes
smime.p7s
Description: S/MIME Cryptographic Signature
"Carlos H. Reimer" <[EMAIL PROTECTED]> writes:
> SELECT * or naming all the columns locks the client application. Yesterday
> I´ve wrongly said that when naming all the columns instead of using the *
> the applications did not lock.
Hm, are you sure it's not one specific column that's causing the
On Thu, Oct 11, 2007 at 02:52:08PM -0400, Tom Lane wrote:
> Randall Lucas <[EMAIL PROTECTED]> writes:
> > Is there a way I can convince my custom composite data type (point_pk)
> > to use the row-wise comparison functions, so that I don't have to
> > hackishly rewrite the comparison algorithm for e
Randall Lucas <[EMAIL PROTECTED]> writes:
> Still, this would fail in a nested situation because it wouldn't
> recurse (if col1 of the compound type were another compound type,
> ferinstance), as would your suggestion above. It might be worthwhile
> to allow choosing to use the default ROW compari
> "Carlos H. Reimer" <[EMAIL PROTECTED]> writes:
> > SELECT * or naming all the columns locks the client
> application. Yesterday
> > I´ve wrongly said that when naming all the columns instead of
> using the *
> > the applications did not lock.
>
> Hm, are you sure it's not one specific column that
On 10/11/07, Carlos H. Reimer <[EMAIL PROTECTED]> wrote:
> > "Carlos H. Reimer" <[EMAIL PROTECTED]> writes:
> > > SELECT * or naming all the columns locks the client
> > application. Yesterday
> > > I´ve wrongly said that when naming all the columns instead of
> > using the *
> > > the applications
> On 10/11/07, Carlos H. Reimer <[EMAIL PROTECTED]> wrote:
> > > "Carlos H. Reimer" <[EMAIL PROTECTED]> writes:
> > > > SELECT * or naming all the columns locks the client
> > > application. Yesterday
> > > > I´ve wrongly said that when naming all the columns instead of
> > > using the *
> > > > th
On 10/11/07, Carlos H. Reimer <[EMAIL PROTECTED]> wrote:
> > On 10/11/07, Carlos H. Reimer <[EMAIL PROTECTED]> wrote:
> > > > "Carlos H. Reimer" <[EMAIL PROTECTED]> writes:
> > > > > SELECT * or naming all the columns locks the client
> > > > application. Yesterday
> > > > > I´ve wrongly said that
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> On 10/11/07, Carlos H. Reimer <[EMAIL PROTECTED]> wrote:
>> It=B4s "" but the "query_start" column is refreshed.
> Then the query runs and finishes and the problem is something to do
> with the delivery of the data. Not sure after that...
That seems
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
> > On 10/11/07, Carlos H. Reimer <[EMAIL PROTECTED]> wrote:
> >> It=B4s "" but the "query_start" column is refreshed.
>
> > Then the query runs and finishes and the problem is something to do
> > with the delivery of the data. Not sure after that...
>
"Carlos H. Reimer" <[EMAIL PROTECTED]> writes:
>> BTW, have you looked into the theory that it's triggered by total
>> data volume rather than number of columns? That is, try selecting
>> all the columns but use LIMIT to reduce the number of rows fetched?
> The where clause limits the number of r
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> To: Greg Wickham
> > However from within plpgsql the 'superuser' attribute isn't honored
> > when trying to change roles
>
> IIRC we deliberately restrict inheritance of superuser
> status. If you want to argue there's
Hi,
In my site when am update the edit user info page its
prperly works in firefox .But not works in IE...But
the updation takes place in the database but the page
is not displayed...Wats the reason?
Now you can chat without downloading messenger. Go to
http://in.messenger.yahoo.com/webm
On Oct 11, 2007, at 9:06 PM, manju arumugam wrote:
In my site when am update the edit user info page its
prperly works in firefox .But not works in IE...But
the updation takes place in the database but the page
is not displayed...Wats the reason?
If the update takes place in the database, what
am Fri, dem 12.10.2007, um 5:06:38 +0100 mailte manju arumugam folgendes:
> Hi,
>
>
> In my site when am update the edit user info page its
> prperly works in firefox .But not works in IE...But
> the updation takes place in the database but the page
> is not displayed...Wats the reason?
IE is
"Tom Lane" <[EMAIL PROTECTED]> writes:
> BTW, have you looked into the theory that it's triggered by total
> data volume rather than number of columns? That is, try selecting
> all the columns but use LIMIT to reduce the number of rows fetched?
Or conversely select the first or second half of th
Please remember to cc: the list.
longlong wrote:
i have done what you said before,there always are people asking and no
answer.
spelling error can be the reason or not?
Try using http://www.google.com/
Search for "postgresql silent install error 2711" - the top result seems
relevant.
In p
52 matches
Mail list logo
