James Mansion wrote:
Magnus Hagander wrote:
Yes. We used to use APCs, but touching anything remotely related to
Winsock from an APC is not supported... We had a lot of trouble
with it
By implication you'd be doing socket'y stuff from the signal handler
on UNIX? Scary.
Uh, sorry, got
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? ;-)
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
I compiled postgreSQL with 1kB block size and regresion test fails. Main problem
is that output is correct but in different order. See attachment.
I think affected test should contain order by keyword.
Any comments?
Zdenek
*** ./expected/join.out Wed Jan 9 21:42:28
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:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00901.php
Am Samstag, 19. April 2008 schrieb Alvaro Herrera:
The FAQs are another matter however. I suggested some time back moving
those to DocBook XML.
The question is whether we consider the FAQ to be a document tied to a
PostgreSQL release (e.g., there is a separate FAQ applying to each release)
On Mon, Apr 21, 2008 at 5:55 PM, Peter Eisentraut [EMAIL PROTECTED] wrote:
For previously established reasons, we don't want to add ORDER BY clauses to
every test that might fail under exceptional circumstances so we test all
plan types equally. I think very small block sizes are fairly
Tom Lane [EMAIL PROTECTED] writes:
The lack of regression tests covering this area is a bit annoying
at this point. However, it's hard to see how to test FOR UPDATE
until we get some concurrent-sessions support in psql.
Well, end-to-end testing would e better but we can test that the locks
Magnus Hagander wrote:
Hold on a minute. You're saying only the english version would be in
Docbook, and then you'd use .po files? So how do I as an end user
actually *read* the FAQ then? I need to both process .po and Docbook?
The xml2po tools allow the reconstruction of translated XML files
Alvaro Herrera wrote:
Magnus Hagander wrote:
Hold on a minute. You're saying only the english version would be in
Docbook, and then you'd use .po files? So how do I as an end user
actually *read* the FAQ then? I need to both process .po and
Docbook?
The xml2po tools allow the
Peter Eisentraut wrote:
Am Samstag, 19. April 2008 schrieb Alvaro Herrera:
The FAQs are another matter however. I suggested some time back
moving those to DocBook XML.
The question is whether we consider the FAQ to be a document tied to
a PostgreSQL release (e.g., there is a separate FAQ
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 a set returning
function? Is there some actual reason
mito escribió:
What information are currently strored in WAL sequence ?
Everything needed to replay each change, at the physical page level.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers
Magnus Hagander wrote:
Alvaro Herrera wrote:
Magnus Hagander wrote:
Hold on a minute. You're saying only the english version would be in
Docbook, and then you'd use .po files? So how do I as an end user
actually *read* the FAQ then? I need to both process .po and
Docbook?
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The lack of regression tests covering this area is a bit annoying
at this point. However, it's hard to see how to test FOR UPDATE
until we get some concurrent-sessions support in psql.
Well, end-to-end testing would
On Mon, Apr 21, 2008 at 11:54 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
I did notice that the section on vim settings doesn't mention anything
about the expandtab setting. Ideally this should be set to
noexpandtab (noet) to preserve tab spacing. I'll add it to the wiki
page, but feel
Alvaro Herrera wrote:
Actually not only I have to convince the translator -- I have to
convince Bruce *as a first step*. I have tried in the past and failed.
Now he is open to discuss changing the format of the FAQs, so I suggest
this idea again, and here I get a ton of negative responses from
Magnus Hagander wrote:
Alvaro Herrera wrote:
Magnus Hagander wrote:
I remain very unconvinced that making it that much more complex is
worth it.. But if someone sets up a complete system to test it, sure -
since I don't write *or* read any of the translated FAQs we should
obviously listen
Magnus Hagander wrote:
For reference, the developer FAQ (which really is a different thing,
given the audience) now lives on the wiki at
http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
people think about that one, and get a signoff on if this should be
the main location
Joshua D. Drake wrote:
Magnus Hagander wrote:
Alvaro Herrera wrote:
Magnus Hagander wrote:
I remain very unconvinced that making it that much more complex is
worth it.. But if someone sets up a complete system to test it,
sure - since I don't write *or* read any of the translated FAQs
On Mon, Apr 21, 2008 at 11:20 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
For reference, the developer FAQ (which really is a different thing,
given the audience) now lives on the wiki at
http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
people think about that one, and
Magnus Hagander [EMAIL PROTECTED] writes:
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 a set
Magnus Hagander wrote:
Joshua D. Drake wrote:
And we've certainly had our share of people not working on the docs
because it's too hard. (I know I used to have to submit all docs
patches untested because it took me a year or so to get the build
process working on win32. Now I've given that
Brendan Jurd wrote:
On Mon, Apr 21, 2008 at 11:20 PM, Magnus Hagander
[EMAIL PROTECTED] wrote:
For reference, the developer FAQ (which really is a different
thing, given the audience) now lives on the wiki at
http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear
what people
Am Montag, 21. April 2008 schrieb Magnus Hagander:
Agreed. I don't think we *ever* backpatch FAQ stuff, which is a clear
indicator it's the later.
Another thought: Would be still ship the FAQ in the release tarball? That
might be a bit weird if it is not maintained in the source code
Peter Eisentraut wrote:
Am Montag, 21. April 2008 schrieb Magnus Hagander:
Agreed. I don't think we *ever* backpatch FAQ stuff, which is a
clear indicator it's the later.
Another thought: Would be still ship the FAQ in the release tarball?
That might be a bit weird if it is not maintained
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
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,
Peter Eisentraut wrote:
Am Montag, 21. April 2008 schrieb Magnus Hagander:
Agreed. I don't think we *ever* backpatch FAQ stuff, which is a clear
indicator it's the later.
Another thought: Would be still ship the FAQ in the release tarball? That
might be a bit weird if it is not
Alvaro Herrera wrote:
... and no response from Bruce, either.
Oh, I am trying not to read community email during weekends, especially
Sundays, so that is why you didn't get a reply earlier. I find it quite
liberating.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
Joshua D. Drake wrote:
Magnus Hagander wrote:
I remain very unconvinced that making it that much more complex is
worth it.. But if someone sets up a complete system to test it, sure -
since I don't write *or* read any of the translated FAQs we should
obviously listen more to those who do.
Pavan Deolasee [EMAIL PROTECTED] writes:
Now that we have autovacuum on by default, we might get into random
failures because of re-ordering. Though I don't seem to recall anybody
complaining yet, it could just be that we are lucky or our regression
suite don't have long enough running tests
Alvaro Herrera wrote:
Magnus Hagander wrote:
Alvaro Herrera wrote:
Magnus Hagander wrote:
Hold on a minute. You're saying only the english version would be in
Docbook, and then you'd use .po files? So how do I as an end user
actually *read* the FAQ then? I need to both
On Sun, Apr 20, 2008 at 1:45 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
I am impressed at the state of the May wiki patch queue:
http://wiki.postgresql.org/wiki/CommitFest:May
It is even tracking the psql wrap patch I am working on now.
Thanks. We've
Brendan Jurd wrote:
On Mon, Apr 21, 2008 at 11:20 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
For reference, the developer FAQ (which really is a different thing,
given the audience) now lives on the wiki at
http://wiki.postgresql.org/wiki/Developer_FAQ. I'd like to hear what
people
Magnus Hagander wrote:
I'm sure we can find a way to do that. We do a lot of fairly ugly work
to mirror from the cvs tree to the website today...
For reference, the developer FAQ (which really is a different thing,
given the audience) now lives on the wiki at
Peter Eisentraut napsal(a):
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:
Brendan Jurd escribió:
I wonder if we should namespace the CommitFest pages by year as well
as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
even after we've had a CommitFest:May in 2009/2010/etc., the history
of the May 2008 CommitFest will still be easily viewable as a
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
I'm only testing behavior with different block size and I think it is not
good idea to support only 8kB for regtest. When 4kB is used then PG fails
in Join regresion test and with 16kB, 32kB it fails because:
*** ./expected/bitmapops.out
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Magnus Hagander wrote:
I remain very unconvinced that making it that much more complex is
worth it.. But if someone sets up a complete system to test it, sure -
since I don't write *or* read any of the translated FAQs we should
obviously
Bruce Momjian wrote:
Alvaro Herrera wrote:
As far as I know, what the doc translators do is translate the SGML
files directly, which is as difficult and cumbersome as you can possibly
get. I am in no way suggesting we do that for the FAQ.
What can we do to help people translate the
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
As far as I know, what the doc translators do is translate the SGML
files directly, which is as difficult and cumbersome as you can possibly
get. I am in no way suggesting we do that for the FAQ.
What can we do to
On Mon, Apr 21, 2008 at 02:25:31PM +0200, Peter Eisentraut wrote:
I think affected test should contain order by keyword.
For previously established reasons, we don't want to add ORDER BY clauses to
every test that might fail under exceptional circumstances so we test all
plan types
Bruce Momjian wrote:
Alvaro Herrera wrote:
I suggest we start an experiment with the FAQ in XML Docbook, which is
amenable to automatic processing, and move from there.
That makes sense. We have many translations of the main FAQ so it would
be a good test for the main docs. But how do
Bruce Momjian a écrit :
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
As far as I know, what the doc translators do is translate the SGML
files directly, which is as difficult and cumbersome as you can possibly
get. I am in no way suggesting we do that for the FAQ.
What
On Mon, 21 Apr 2008 12:22:45 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
I suggest we start an experiment with the FAQ in XML Docbook,
which is amenable to automatic processing, and move from there.
That makes sense. We have many
[EMAIL PROTECTED] (Bruce Momjian) writes:
I am impressed at the state of the May wiki patch queue:
http://wiki.postgresql.org/wiki/CommitFest:May
It is even tracking the psql wrap patch I am working on now.
Aside: I have made a few little changes that oughtn't be too
controversial:
1.
On Tue, Apr 22, 2008 at 1:38 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Brendan Jurd escribió:
I wonder if we should namespace the CommitFest pages by year as well
as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
even after we've had a CommitFest:May in
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 automatically, without having to
eyeball the output.
That
Brendan Jurd wrote:
On Tue, Apr 22, 2008 at 1:38 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Brendan Jurd escribió:
I wonder if we should namespace the CommitFest pages by year as well
as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
even after we've had a
Am Montag, 21. April 2008 schrieb Alvaro Herrera:
Yes, basically my answer is we don't. Currently there's no such thing
as easy editing, and while I agree it would be good to have it, I don't
have a solution for it.
I think easy editing and easy translating are sort of mutually exclusive with
On Tue, Apr 22, 2008 at 2:44 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Why not use a form for posting new patches that would automatically put it
on the right page? (I have no idea if you can do that sort of thing using
mediawiki - it's just what I would do if I were designing a patch
On Tue, 22 Apr 2008, Brendan Jurd wrote:
I wonder if we should namespace the CommitFest pages by year as well
as month (i.e., move CommitFest:May to CommitFest:May2008).
This already came up on pgsql-www and as I just replied to over there, the
current structure has some things I'd like to
On Tue, 22 Apr 2008 02:54:16 +1000
Brendan Jurd [EMAIL PROTECTED] wrote:
Being able to submit patches via a web form is one of the more obvious
benefits of a real patch tracker. I'm not aware of any way to
accomplish this in mediawiki without resorting to some nasty script
hackery.
We could
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 automatically, without having to
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
As far as I know, what the doc translators do is translate the SGML
files directly, which is as difficult and cumbersome as you can possibly
get. I am in no way suggesting we do that for the FAQ.
What can we do to help people
Peter Eisentraut [EMAIL PROTECTED] writes:
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 automatically,
Tino Wildenhain wrote:
Well... or reStructuredText which has the advantage of beeing human
editable? (without specialized editor that is)
Hmm, that sounds like an useful idea, I'll do some research.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
On Mon, Apr 21, 2008 at 8:20 PM, Tom Lane [EMAIL PROTECTED] wrote:
No, the reason you don't see that is that plain VACUUM doesn't move
tuples around.
I know. But plain VACUUM can free up dead space which can be used for
subsequent updates/inserts and that can cause reordering. For example:
On Mon, 21 Apr 2008 19:06:53 +0200
Tino Wildenhain [EMAIL PROTECTED] wrote:
Well... or reStructuredText which has the advantage of beeing human
editable? (without specialized editor that is)
Huh? How is XML not human editable... didn't you ever create webpages
in vi? :)
Joshua D. Drake
--
On Mon, 21 Apr 2008, Tino Wildenhain wrote:
Alvaro Herrera wrote:
I suggest we start an experiment with the FAQ in XML Docbook, which is
amenable to automatic processing, and move from there.
Well... or reStructuredText which has the advantage of beeing human
editable? (without specialized
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
set work_mem = 64;
+ ERROR: 64 is outside the valid range for parameter work_mem (256 ..
2097151) -- Test bitmap-and.
This should probably be fixed by using a unit specification on work_mem. Do
Am Montag, 21. April 2008 schrieb Tino Wildenhain:
Well... or reStructuredText which has the advantage of beeing human
editable? (without specialized editor that is)
Well, there is also asciidoc, markdown, and various other wiki-like minimal
markup formats. All fine ideas, if we want to
On Mon, Apr 21, 2008 at 10:54 PM, Pavan Deolasee
[EMAIL PROTECTED] wrote:
Case 1.
Insert 100 records --- goes into block 1 .. 10
Delete 100 records
Insert 100 more records --- goes into 11 .. 20
Case 2.
Insert 100 records --- goes into block 1 .. 10
Delete 100 records
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.
Well, we wouldn't treat
Greg Smith wrote:
On Mon, 21 Apr 2008, Tino Wildenhain wrote:
Alvaro Herrera wrote:
I suggest we start an experiment with the FAQ in XML Docbook, which is
amenable to automatic processing, and move from there.
Well... or reStructuredText which has the advantage of beeing human
editable?
Andrew Dunstan wrote:
So I continue to think the best way to generate a list will be to
consolidate lists generated from the buildfarm which represents a wide
variety of build scenarios.
Is anyone else looking at GNU indent to see if it has improved enough to
meet our needs?
I am not
This idea may be taking it to the extreme but I thought I'd throw it out
there anyway as everyone seems to want something different. (well there
seems to be three variants that if all were available would keep most
people happy) This may be one way to please everyone.
What if the actual
Bruce Momjian wrote:
Andrew Dunstan wrote:
So I continue to think the best way to generate a list will be to
consolidate lists generated from the buildfarm which represents a wide
variety of build scenarios.
Is anyone else looking at GNU indent to see if it has improved enough to
meet
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 thread-safe/reentrant versions of
Brendan Jurd wrote:
I wonder if we should namespace the CommitFest pages by year as well
as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
even after we've had a CommitFest:May in 2009/2010/etc., the history
of the May 2008 CommitFest will still be easily viewable as a
Bruce Momjian escribió:
Brendan Jurd wrote:
I wonder if we should namespace the CommitFest pages by year as well
as month (i.e., move CommitFest:May to CommitFest:May2008). This way,
even after we've had a CommitFest:May in 2009/2010/etc., the history
of the May 2008 CommitFest will
The following two files specify the behaviour of the MERGE statement and
how it will work in the world of PostgreSQL. In places, this supercedes
my recent commentary on MERGE, particularly with regard to triggers.
Neither of these files is intended for CVS.
The HTML file was generated from SGML
Hello,
Attached is a patch for the default message from psql. Couple of things
of note:
1. I removed the force wrapping, instead allowing the terminal to do
it. This seems to work in X and well as on the console. I am not sure
if I like this or not and am not opposed to changing to a forced
Hello Simon,
would you support RETURNING clause?
Regards
Pavel Stehule
On 21/04/2008, Simon Riggs [EMAIL PROTECTED] wrote:
The following two files specify the behaviour of the MERGE statement and
how it will work in the world of PostgreSQL. In places, this supercedes
my recent commentary
On Mon, 2008-04-21 at 22:18 +0200, Pavel Stehule wrote:
would you support RETURNING clause?
I wouldn't rule it out completely, but not in the first implementation
because
- its more work
- its not in the SQL Standard
- neither Oracle nor DB2 support it either, so its only going to provide
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust
There's a new #include file that it turns out we need for Slony-I to
reference, namely include/server/utils/snapmgr.h
I tried adding an autoconf rule to Slony-I to check for its existence
(goal then is to do a suitable #define so that we can #ifdef the
#include, so that we #include this only with
Joshua D. Drake wrote:
On Mon, 21 Apr 2008 19:06:53 +0200
Tino Wildenhain [EMAIL PROTECTED] wrote:
Well... or reStructuredText which has the advantage of beeing human
editable? (without specialized editor that is)
Huh? How is XML not human editable... didn't you ever create webpages
in vi?
On Apr 21, 2008, at 4:08 PM, Simon Riggs wrote:
The following two files specify the behaviour of the MERGE statement
and
how it will work in the world of PostgreSQL. In places, this
supercedes
my recent commentary on MERGE, particularly with regard to triggers.
Neither of these files is
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 PROTECTED]:~/Slony-I/CMD/slony1-HEAD gcc
On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
MERGE will not invoke Rules. Does this imply that MERGE cannot be
used on views or that the resulting INSERTs or UPDATEs do not work on
views?
Yes, that's right. Just like COPY. That seems fine to me because you're
likely to be doing a MERGE
Chris Browne [EMAIL PROTECTED] writes:
I tried adding an autoconf rule to Slony-I to check for its existence
(goal then is to do a suitable #define so that we can #ifdef the
#include, so that we #include this only with versions of PostgreSQL
that have the file).
The customary way of handling
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
MERGE will not invoke Rules. Does this imply that MERGE cannot be
used on views or that the resulting INSERTs or UPDATEs do not work on
views?
Yes, that's right. Just like COPY.
I find this to be pretty
On Mon, 2008-04-21 at 20:28 -0400, Tom Lane wrote:
In fact, I don't even want to think
about what kind of crock you're going to need in order to get it through
the planner without also going through the rewriter.
Hmmm, I hadn't thought I might be adding work rather than avoiding it.
I'll
On Mon, 2008-04-21 at 20:28 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
MERGE will not invoke Rules. Does this imply that MERGE cannot be
used on views or that the resulting INSERTs or UPDATEs do not work on
views?
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
concurrently.
But that's how the committee designed it,
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 cause problems if used
concurrently.
If there are race
Hello!I have a problem with my postgresql. I install postgresql8.1 on windows
xp with sp2 and get the errorcould not connect to server: Connection refused
(0x274D/10061)Is the server running on host ??? and accepting TCP/IP
connections on port 5432?.I have stopped the windows firewall How
87 matches
Mail list logo
