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 materi
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 po
Hello!I have a problem with my postgresql. I install postgresql8.1 on windows
xp with sp2 and get the error"could 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 H
"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 c
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,
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
> >
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 g
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 t
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 hand
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 ME
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 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 in
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?
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
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 the
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
incom
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 commenta
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 wrap.
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
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 w
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
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 l
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 o
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 welcome
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 n
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? (wit
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
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 record
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 intr
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_me
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 ed
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 exa
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 Re
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
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
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
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.
W
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 fi
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
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
eyeb
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
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 C
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 so
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 200
[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:
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
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 ca
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
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 e
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.
> >
> > W
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
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
>
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
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 a
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.
>
>
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:
http://archives.postgresql.org/pgsql-ha
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
>
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
> http://wiki.postgresql.or
"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
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 w
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
Enterpri
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 m
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
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 mai
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 reposit
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 funct
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
> > wh
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 up
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 s
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
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 tra
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 loc
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
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 fee
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 mor
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 t
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
> > >
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
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 f
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 separ
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
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 fil
"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 l
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 fai
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)
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
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 200
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
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,
89 matches
Mail list logo
