On Wed, Apr 23, 2008 at 4:20 AM, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> 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 proces
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
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
-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.
I'
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?"
> Be
-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.
>
>
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/
PostgreS
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 j
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 pos
-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 e
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)
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
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 settin
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 abo
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
"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 (p
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.h
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 we
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 shoul
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
Tha
"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
--
On Mon, 21 Apr 2008 13:17:40 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
Hello,
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
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 Comp
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
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 postmaster,
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 gra
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 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
oth
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.
> > I
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:
http://arch
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 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
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 h
"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 r
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
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
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 som
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 someo
"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 re
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?
> >
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 go
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 we
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, perh
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 ins
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 wor
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
"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 reg
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
--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
defin
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 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
> c
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
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
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
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 SEQUEN
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...
Apparen
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/
> -I/opt/OXRS/
[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:
>
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 b
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-hacker
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
--
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 - \n"
> You can do most of this already.
It seems rather overd
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 overwritt
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.
>
>
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 dev
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 care
"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
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, a
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 cmp_numer
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 ar
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 do
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 w
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 imp
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 ins
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
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
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 usag
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 automatical
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.
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 - \n"
This is basically equivalent to
\echo Welcome to psql :VERSION blah.
You can do most of this already.
--
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.
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 interrupti
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.ph
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 prob
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
85 matches
Mail list logo
