Hello,
I don't have experience with windows installation, but try to look on
pg_hba.conf setup. Else 8.1 is not recommended for windows. Please, use 8.3. And
last comment is use pgsql-general for this kind of question.
Zdenek
王佳伟 napsal(a):
Hello!I have a problem with my
Magnus Hagander wrote:
The problem is when winsock operations are interrupted by APCs.
See:
http://archives.postgresql.org/pgsql-hackers-win32/2004-04/msg00013.php
Whoa! Indeed, that's a bit sucky because they really aren't documented
as interruptible.
In this case though I see not
On Mon, 2008-04-21 at 21:57 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
Unrelated to rule processing, you did read the bit about MERGE and race
conditions? ISTM that MERGE as it stands isn't very useful for anything
other than large data loads since its going to cause problems if used
On Mon, Apr 21, 2008 at 09:47:02AM +0200, Magnus Hagander wrote:
Uh, sorry, got that explained backwards.
The problem is when winsock operations are interrupted by APCs.
See:
http://archives.postgresql.org/pgsql-hackers-win32/2004-04/msg00013.php
WRT this bit:
(1) carries a big problem -
Martijn van Oosterhout wrote:
On Mon, Apr 21, 2008 at 09:47:02AM +0200, Magnus Hagander wrote:
Uh, sorry, got that explained backwards.
The problem is when winsock operations are interrupted by APCs.
See:
http://archives.postgresql.org/pgsql-hackers-win32/2004-04/msg00013.php
WRT
James Mansion wrote:
Magnus Hagander wrote:
The problem is when winsock operations are interrupted by APCs.
See:
http://archives.postgresql.org/pgsql-hackers-win32/2004-04/msg00013.php
Whoa! Indeed, that's a bit sucky because they really aren't
documented as interruptible.
In
On Tue, Apr 22, 2008 at 08:24:58AM +0100, Simon Riggs wrote:
The way MERGE works we first test to see if it matches or not, then if
not matched we would activate the NOT MATCHED action, which standard
says must be an insert. The gap between the two actions allows a race
condition to exist.
Am Montag, 21. April 2008 schrieb Shane Ambler:
What if the actual welcome message can be defined in the .psqlrc ?
Something along the lines of -
WELCOME_MESSAGE=Welcome to VERS_PSQL - VERS_SERVER\nSSL_INFO
This is basically equivalent to
\echo Welcome to psql :VERSION blah.
You can do most
Peter Eisentraut napsal(a):
Am Montag, 21. April 2008 schrieb Tom Lane:
That sounds like a pretty bad idea, since it would treat ordering
differences as insignificant even when they aren't --- for example,
an ordering difference in the output of a query that *has* an
ORDER BY is usually a bug.
Andrew Dunstan napsal(a):
Peter Eisentraut wrote:
Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
I wonder if it would be feasable to, whenever a regression test fails
to sort both files and compare again. This should tell you if the
difference are *only* rearrangement
Tom Lane napsal(a):
Another possible answer is to change the minimum to be just 64K always.
I'm not certain that it's really sensible to tie the minimum work_mem to
BLCKSZ --- I don't think we do anything where work_mem is controlling a
pool of page buffers, do we?
Yeah, I try to find all
It started with this query :
EXPLAIN ANALYZE SELECT * FROM relations r JOIN nodes n ON
(n.id=r.child_id) WHERE r.parent_id=16330;
QUERY PLAN
On Tue, Apr 22, 2008 at 10:31:53AM +0200, Zdenek Kotala wrote:
When you are able detect ordering difference you are able also check if it
is important for the test or not without any extra effort. Only what we
need is put some flag to test that order is not important.
Not true. Sorting the
On Tue, 2008-04-22 at 10:02 +0200, Martijn van Oosterhout wrote:
On Tue, Apr 22, 2008 at 08:24:58AM +0100, Simon Riggs wrote:
The way MERGE works we first test to see if it matches or not, then if
not matched we would activate the NOT MATCHED action, which standard
says must be an insert.
Martijn van Oosterhout napsal(a):
On Tue, Apr 22, 2008 at 10:31:53AM +0200, Zdenek Kotala wrote:
When you are able detect ordering difference you are able also check if it
is important for the test or not without any extra effort. Only what we
need is put some flag to test that order is not
On Tue, Apr 22, 2008 at 4:25 PM, Martijn van Oosterhout [EMAIL PROTECTED]
wrote:
On Tue, Apr 22, 2008 at 10:31:53AM +0200, Zdenek Kotala wrote:
When you are able detect ordering difference you are able also check if
it
is important for the test or not without any extra effort. Only what we
I was wandering if there where any intentions of moving some of the currently
internal numeric function prototypes to the Numeric header file. I believe
such functions like cmp_numerics, add_var, etc would come in handy when writing
user defined C code.
Would there be many ill effects by
Bruce Momjian wrote:
Magnus Hagander wrote:
port/thread.c includes the pthreads header files, and contains a
bunch of comments about pthreads - but there seems to be no code
related to pthreads at all in the file. Am I missing something
completely here? ;-)
Uh, those files are
Aaron Spiteri wrote:
I was wandering if there where any intentions of moving some of
the currently internal numeric function prototypes to the Numeric
header file. I believe such functions like
Hi all,
The first version of prefix code is now released at pgfoundry, last bug
squashed by Jordan, who did his own prefix gist opclass implementation before
I did, but didn't publish at this time. The plan is to integrate is work into
the prefix solution, as his lookups are faster than mine,
Aaron Spiteri [EMAIL PROTECTED] writes:
I was wandering if there where any intentions of moving some of the
currently internal numeric function prototypes to the Numeric header file. I
believe such functions like cmp_numerics, add_var, etc would come in handy
when writing user defined C code.
It seems changes to the commit fest wiki pages are going to be overwritten
accidently when editing the page concurrently. At least, this occured to me
as i accidently removed entries done by Laurenz Albe and my changes were
overwritten by Alvaro Herrera again.
So developers need to be
Bernd Helmle wrote:
It seems changes to the commit fest wiki pages are going to be
overwritten accidently when editing the page concurrently. At least,
this occured to me as i accidently removed entries done by Laurenz
Albe and my changes were overwritten by Alvaro Herrera again.
So
Bernd Helmle wrote:
It seems changes to the commit fest wiki pages are going to be
overwritten accidently when editing the page concurrently. At least, this
occured to me as i accidently removed entries done by Laurenz Albe and my
changes were overwritten by Alvaro Herrera again.
So
Andrew Dunstan wrote:
Bernd Helmle wrote:
It seems changes to the commit fest wiki pages are going to be
overwritten accidently when editing the page concurrently. At least,
this occured to me as i accidently removed entries done by Laurenz
Albe and my changes were overwritten by
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 21. April 2008 schrieb Shane Ambler:
What if the actual welcome message can be defined in the .psqlrc ?
Something along the lines of -
WELCOME_MESSAGE=Welcome to VERS_PSQL - VERS_SERVER\nSSL_INFO
You can do most of this already.
It
Zdenek Kotala [EMAIL PROTECTED] writes:
Regression test MUST BE bulletproof.
I'm sorry, but this is not, never has been, and never will be an
iron-clad project rule. When you get a failure you are supposed
to inspect it to see if it's a problem.
regards, tom lane
--
Zdenek Kotala [EMAIL PROTECTED] writes:
By the way is any reason to have work_mem * 1024 everywhere when we have
unit
support in GUC?
Well, would you like to be able to set work_mem higher than 4GB on large
machines?
regards, tom lane
--
Sent via pgsql-hackers
Hi,
Zoltan Boszormenyi írta:
Updated patch implements TRUNCATE ... RESTART IDENTITY
which restarts all owned sequences for the truncated table(s).
Regression tests updated, documentation added. pg_dump was
also extended to output original[1] START value for creating SEQUENCEs.
[1] For 8.3 and
[EMAIL PROTECTED] (Alvaro Herrera) writes:
Chris Browne wrote:
If I use:
AC_CHECK_HEADER(utils/snapmgr.h, HAVE_SNAPMGR=1)
this turns out to fail. Apparently autoconf wants to compile the
#include file to validate that it's an OK #include file.
GCC barfs on it, thus:
[EMAIL
Chris Browne wrote:
And I was trying to build against CVS HEAD (for both projects ;-)) and
observed it:
[EMAIL PROTECTED]:CMD/slony1-HEAD/src/backend make
gcc -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../.. -fpic
-I/opt/OXRS/dbs/pgsql84-beta/include/
Magnus Hagander wrote:
Bruce Momjian wrote:
Uh, those files are thread-safe/reentrant versions of libc
functions. I don't think they need the pthread.h includes. You want
to try removing those includes and see how the buildfarm behaves?
Done, let's see what happens...
Apparently the
Zoltan Boszormenyi wrote:
I just saw this on the CommitFest:May page:
alvherre says: I'm not sure if this is the same patch in the previous
entry, or a different feature
I wanted to clarify, the second patch contains two features.
1. stored start value for sequences, ALTER SEQUENCE ...
Alvaro Herrera [EMAIL PROTECTED] writes:
Bernd Helmle wrote:
It seems changes to the commit fest wiki pages are going to be
overwritten accidently when editing the page concurrently. At least, this
occured to me as i accidently removed entries done by Laurenz Albe and my
changes were
On Wed, Apr 23, 2008 at 2:40 AM, Tom Lane [EMAIL PROTECTED] wrote:
Bernd Helmle wrote:
It seems changes to the commit fest wiki pages are going to be
overwritten accidently when editing the page concurrently. At least, this
occured to me as i accidently removed entries done by Laurenz
On Wed, 23 Apr 2008 02:59:43 +1000
Brendan Jurd [EMAIL PROTECTED] wrote:
According to the information at the above link, the wiki should let
you know about concurrent edit conflicts and give you an opportunity
to resolve them before attempting to commit your changes again.
Not sure how the
On Wed, Apr 23, 2008 at 12:16 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Perhaps what's going on is that the software does not check that the
version I read is the most recent one :-( so if two of us edit the page
at the same time, the one committing last is going to stomp on the
changes
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Regression test MUST BE bulletproof.
I'm sorry, but this is not, never has been, and never will be an
iron-clad project rule. When you get a failure you are supposed
to inspect it to see if it's a problem.
Yes, but when you find
--On Mittwoch, April 23, 2008 03:17:54 +1000 Brendan Jurd
[EMAIL PROTECTED] wrote:
I had a look into the history on the CommitFest page. It looks like
Alvaro unintentionally clobbered the previous five edits, which went
back about four hours. I've restored those changes now, but it is
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
By the way is any reason to have work_mem * 1024 everywhere when we have unit
support in GUC?
Well, would you like to be able to set work_mem higher than 4GB on large
machines?
I see, another int64 issues.
Thanks Zdenek
Brendan Jurd [EMAIL PROTECTED] writes:
I had a look into the history on the CommitFest page. It looks like
Alvaro unintentionally clobbered the previous five edits, which went
back about four hours. I've restored those changes now, but it is
definitely worrying that such a drastic regression
Brendan Jurd escribió:
On Wed, Apr 23, 2008 at 12:16 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Perhaps what's going on is that the software does not check that the
version I read is the most recent one :-( so if two of us edit the page
at the same time, the one committing last is
Tom Lane escribió:
Brendan Jurd [EMAIL PROTECTED] writes:
I had a look into the history on the CommitFest page. It looks like
Alvaro unintentionally clobbered the previous five edits, which went
back about four hours. I've restored those changes now, but it is
definitely worrying that
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Regression test MUST BE bulletproof.
I'm sorry, but this is not, never has been, and never will be an
iron-clad project rule. When you get a failure you are supposed
to inspect it to see if
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
We saw this type of thing happen more than once on the CommitFest:March
page, if memory serves. Apparently there is something very broken about
the copy of mediawiki we are using --- would someone look into that?
Hmm, perhaps it is
On Tue, 22 Apr 2008 13:35:41 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Tom Lane escribió:
Brendan Jurd [EMAIL PROTECTED] writes:
I had a look into the history on the CommitFest page. It looks
like Alvaro unintentionally clobbered the previous five edits,
which went back about
On Mon, 2008-04-21 at 22:27 -0400, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Unrelated to rule processing, you did read the bit about MERGE and race
conditions? ISTM that MERGE as it stands isn't very useful for anything
other than large data loads since its going to
Alvaro Herrera wrote:
Magnus Hagander wrote:
Bruce Momjian wrote:
Uh, those files are thread-safe/reentrant versions of libc
functions. I don't think they need the pthread.h includes. You
want to try removing those includes and see how the buildfarm
behaves?
Done, let's see
Brendan Jurd [EMAIL PROTECTED] writes:
I had a look into the history on the CommitFest page. It looks like
Alvaro unintentionally clobbered the previous five edits, which went
back about four hours. I've restored those changes now, but it is
definitely worrying that such a drastic
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
We saw this type of thing happen more than once on the
CommitFest:March page, if memory serves. Apparently there is
something very broken about the copy of mediawiki we are using ---
would someone look into
Magnus Hagander wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
We saw this type of thing happen more than once on the
CommitFest:March page, if memory serves. Apparently there is
something very broken about the copy of mediawiki we are using ---
would
On Tue, 22 Apr 2008 19:52:02 +0200
Magnus Hagander [EMAIL PROTECTED] wrote:
That's easy enough: http://wiki.postgresql.org/wiki/Special:Version
So we're on 1.12alpha (r31813)
Now what that actually *means* is a whole different question :-) I
don't know mediawiki nearly well enough to
On Apr 21, 2008, at 8:34 AM, Magnus Hagander wrote:
While looking over the statistics-for-functions patch
(http://archives.postgresql.org/pgsql-patches/2008-03/msg00300.php), I
came back to a thought I've had before - why do we keep one function
per column for pgstat functions, instead of using
Simon Riggs [EMAIL PROTECTED] writes:
As I've said elsewhere, we could have it lock each row, its just more
overhead if we do and not necessary at all for bulk data merging.
I'll presume we want locking as an option, unless people say otherwise.
It's not so simple. If you look for a row to
Magnus Hagander wrote:
Alvaro Herrera wrote:
Magnus Hagander wrote:
Bruce Momjian wrote:
Uh, those files are thread-safe/reentrant versions of libc
functions. I don't think they need the pthread.h includes. You
want to try removing those includes and see how the buildfarm
On Apr 22, 2008, at 1:47 PM, Simon Riggs wrote:
On Mon, 2008-04-21 at 22:27 -0400, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Unrelated to rule processing, you did read the bit about MERGE and
race
conditions? ISTM that MERGE as it stands isn't very useful for
anything
On Apr 22, 2008, at 5:13 AM, PFC wrote:
In order to have it use the fast plan I must set random_page_cost
to 1 which I absolutely don't want to do.
Setting effective_cache_size to huge values has no effect.
If I select a value of parent_id that has much less children, the
index will be used,
On Apr 21, 2008, at 7:25 AM, Peter Eisentraut wrote:
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
I compiled postgreSQL with 1kB block size and regresion test
fails. Main
problem is that output is correct but in different order. See
attachment.
This was previously reported:
On Wed, Apr 23, 2008 at 12:11 AM, Decibel! [EMAIL PROTECTED] wrote:
On Apr 22, 2008, at 5:13 AM, PFC wrote:
In order to have it use the fast plan I must set random_page_cost to 1
which I absolutely don't want to do.
Setting effective_cache_size to huge values has no effect.
If I select
On Apr 22, 2008, at 1:17 PM, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
As I've said elsewhere, we could have it lock each row, its just more
overhead if we do and not necessary at all for bulk data merging.
I'll presume we want locking as an option, unless people say
RECORD.* doesn't work in plpgsql, but NEW.* and OLD.* do in trigger
functions created in plpgsql.
The example function process_emp_audit() on page
http://www.postgresql.org/docs/8.3/interactive/plpgsql-trigger.html , shows
that we can use OLD.* and NEW.* as:
INSERT INTO emp_audit SELECT 'D',
On Tue, Apr 22, 2008 at 02:19:24PM -0500, Decibel! wrote:
But no matter how this is done, I think we need to handle the race
conditions, and handle them by default. If people *really* know what
they're doing, they can disable the row locking (perhaps one way to
do this would be to grab
Magnus Hagander wrote:
You interested in trying to code up a patch to verify that? ;)
Practical reality says that I won't get to this before the next version
of Windows is released.
I don't want to promise something I can't deliver.
If there were any desire to provide a MT-aware
On 4/22/08, Alvaro Herrera [EMAIL PROTECTED] wrote:
Chris Browne wrote:
And I was trying to build against CVS HEAD (for both projects ;-)) and
observed it:
[EMAIL PROTECTED]:CMD/slony1-HEAD/src/backend make
gcc -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../.. -fpic
Marko Kreen escribió:
You probably simply need to use ActiveSnapshot there.
Heh, ActiveSnapshot as a symbol is also gone in the new code ;-) I
changed txid.c to use GetActiveSnapshot() instead.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL
Gurjeet Singh [EMAIL PROTECTED] writes:
RECORD.* doesn't work in plpgsql, but NEW.* and OLD.* do in trigger
functions created in plpgsql.
NEW and OLD have predetermined column sets (within any one trigger function).
A RECORD variable doesn't.
regards, tom lane
--
Sent
Joshua D. Drake wrote:
Attached is v2 of this patch. The following changes have been made:
* If there is not a version mismatch, psql tells you nothing but ask
for help if you need it.
* If there is a version mismatch it tells you and still tells you to
type help if you need it
Thanks.
On Tue, 22 Apr 2008 17:56:49 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
! puts(_(\tTo view the copyright type
\\c . \n));
The copyright is show with \copyright, not \c.
Doh! I knew that. I will fix after the below discussion :)
I think the warning should be two
Joshua D. Drake wrote:
On Tue, 22 Apr 2008 17:56:49 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
I think the warning should be two lines:
WARNING: Server is version %d.%d, %s is version %d.%d.
Some backslash commands may not work.
I tried that, I thought it looked weird. The
On Tue, Apr 22, 2008 at 4:10 PM, Gurjeet Singh [EMAIL PROTECTED] wrote:
RECORD.* doesn't work in plpgsql, but NEW.* and OLD.* do in trigger
functions created in plpgsql.
The example function process_emp_audit() on page
http://www.postgresql.org/docs/8.3/interactive/plpgsql-trigger.html ,
Joshua D. Drake [EMAIL PROTECTED] writes:
* If there is not a version mismatch, psql tells you nothing but ask
for help if you need it.
That was NOT part of the agreement. The version line should stay.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Tue, 22 Apr 2008 19:13:54 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
* If there is not a version mismatch, psql tells you nothing but
ask for help if you need it.
That was NOT part of the agreement. The version line should stay.
Why do we care,
On Tue, 22 Apr 2008 16:28:20 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
Why do we care, if the version matches? Not that I am feeling like
fighting about it but it seems just a waste of bytes. It makes sense
if the version doesn't match.
Joshua D. Drake
Actually in thinking about this,
Decibel! [EMAIL PROTECTED] writes:
cache priority to me sounds like we're trying to influence caching
behavior, which isn't what's happening. I do agree that we need a
better way to tell the planner what tables are in memory.
What's been discussed in the past is per-tablespace settings for
Joshua D. Drake wrote:
On Tue, 22 Apr 2008 19:13:54 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
* If there is not a version mismatch, psql tells you nothing but
ask for help if you need it.
That was NOT part of the agreement. The
On Tue, 22 Apr 2008 19:56:53 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
You might care if you are working with more than one version at once,
even if the psql you're using matches the server it's talking to.
(That's kinda why I suggested the version as a possible prompt escape)
O.k.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 23, 2008 at 9:28 AM, Joshua D. Drake wrote:
Why do we care, if the version matches? Not that I am feeling like
fighting about it but it seems just a waste of bytes. It makes sense if
the version doesn't match.
To take a field
Joshua D. Drake wrote:
On Tue, 22 Apr 2008 19:56:53 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
You might care if you are working with more than one version at once,
even if the psql you're using matches the server it's talking to.
(That's kinda why I suggested the version as a
On Wed, 23 Apr 2008 10:07:46 +1000
Brendan Jurd [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 23, 2008 at 9:28 AM, Joshua D. Drake wrote:
Why do we care, if the version matches? Not that I am feeling like
fighting about it but it seems just a waste
On Tue, 22 Apr 2008 20:09:44 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
No, I mean you could put it in your psql prompt.
8.3 dbname
Oh that's interesting. Let me see how it looks.
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 23, 2008 at 10:11 AM, Joshua D. Drake wrote:
On Wed, 23 Apr 2008 10:07:46 +1000
Brendan Jurd wrote:
In such an environment, it's *very* useful to have instant feedback on
which server I've just connected to with psql.
The
On Wed, 23 Apr 2008 10:25:19 +1000
Brendan Jurd [EMAIL PROTECTED] wrote:
With your proposal, when the banner goes silent about the version, I
need to think Oh yeah, that means that the server version is the same
as the psql version. Umm, what version of psql did I execute again?
Bearing in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 23, 2008 at 10:37 AM, Joshua D. Drake wrote:
Sure. What did you think about Andrew's suggestion?
I think it's cool; allowing the version to be added to a custom psql
prompt is a nice feature, regardless of how we go with the banner.
On Wed, 23 Apr 2008 10:47:32 +1000
Brendan Jurd [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 23, 2008 at 10:37 AM, Joshua D. Drake wrote:
Sure. What did you think about Andrew's suggestion?
I think it's cool; allowing the version to be added to a
On Tue, 22 Apr 2008, PFC wrote:
Example : let's imagine a cache priority setting.
Which we can presume the DBA will set incorrectly because the tools needed
to set that right aren't easy to use.
An alternative would be for the background writer to keep some stats and do
the thing for us :
85 matches
Mail list logo
