Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I could write it to save the xid's in PGPROC in a first pass, then
> release the SInvalLock, then look at pg_subtrans. But I think doing it
> this way has a ("is a?") race condition.
The way that would be technically correct is to *first* look in
pg_su
Small patch that adds some documentation for the area() function.
Specifically, point out that intersecting points in a path will yield
(most likely), unexpected results. Visually these are identical paths,
but mathematically they're not the same. Ex:
area |
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> With this comment, I take it you'd disagree with my recoding of
> TransactionIdIsCurrentTransactionId().
> The current code has to scan only the xid's in each PGPROC struct.
> However I had to rewrite it to peek at pg_subtrans, and this is done
> while
On Fri, May 28, 2004 at 01:01:10AM -0400, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> You'd actually need to get a pid *reuse* during that short time.
>
> > That isn't so implausible on a system which assigns PIDs randomly.
> > Holding the SInvalLock
Neil Conway <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> You'd actually need to get a pid *reuse* during that short time.
> That isn't so implausible on a system which assigns PIDs randomly.
> Holding the SInvalLock doesn't remove the race condition, but it
> makes it less likely to o
Bruce Momjian wrote:
> Claudio Natoli wrote:
> >
> > Hi Tom,
> >
> > > other changes into an upcoming rewrite of the EXEC_BACKEND code.
> >
> > are you planning on doing this for 7.5? I was at some stage, as
promised,
> > but not for 7.5.
>
> I think Tom is doing it now. He has to merge the c
Claudio Natoli wrote:
>
> Hi Tom,
>
> > other changes into an upcoming rewrite of the EXEC_BACKEND code.
>
> are you planning on doing this for 7.5? I was at some stage, as promised,
> but not for 7.5.
I think Tom is doing it now. He has to merge the checkpointer into the
background writer, so
Attached is an updated patch, fixing a compile error which my compiler
didn't seem to detect/suffer from and incorporating fixes to problems
raised by Neil.
Thanks,
Gavin
tablespace-20.diff.gz
Description: GNU Zip compressed data
---(end of broadcast)---
Hi Tom,
> other changes into an upcoming rewrite of the EXEC_BACKEND code.
are you planning on doing this for 7.5? I was at some stage, as promised,
but not for 7.5.
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclai
>
> I am working on integrating this patch now.
>
> What is the logic if checkConfigDir(). It seems incompleted or wrong.
>
> Your code had:
>
> + if(S_ISREG(stat_buf.st_mode)) /* It's a regular file, so
> assume it's an explict */
> + {
> + return TRUE;
> +
I am working on integrating this patch now.
What is the logic if checkConfigDir(). It seems incompleted or wrong.
Your code had:
+ if(S_ISREG(stat_buf.st_mode)) /* It's a regular file, so assume it's
an explict */
+ {
+ return TRUE;
+ }
+ else i
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> The following patch fixes locale support under win32.
I've applied the change in pg_locale.c, and will fold the other changes
into an upcoming rewrite of the EXEC_BACKEND code.
regards, tom lane
---(e
Magnus Hagander wrote:
You'd actually need to get a pid *reuse* during that short time.
That isn't so implausible on a system which assigns PIDs randomly.
Holding the SInvalLock doesn't remove the race condition, but it
makes it less likely to occur for essentially very little cost.
Bottom line
>> >> Okay, here is an updated patch. now uses IsBackendPid(), which is
>> >> closely modeled (read cut-and-pasted) from
>> >> TransactionIdIsInProgress().
>
>I wonder what can happen if a backend passes the
>IsBackendPid() test and
>terminates just before the kill() signal? It should be pretty
On Thu, May 27, 2004 at 08:08:34PM +0200, Magnus Hagander wrote:
> >Magnus Hagander wrote:
> >> Okay, here is an updated patch. now uses IsBackendPid(), which is
> >> closely modeled (read cut-and-pasted) from
> >> TransactionIdIsInProgress().
I wonder what can happen if a backend passes the Is
Arrgh, when will I ever learn :-(
Attached.
//Magnus
>-Original Message-
>From: Bruce Momjian [mailto:[EMAIL PROTECTED]
>Sent: den 26 maj 2004 20:50
>To: Magnus Hagander
>Cc: Neil Conway; [EMAIL PROTECTED]
>Subject: Re: [PATCHES] Cancel/Kill backend functions
>
>
>
>Magnus, would you p
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I will make a Win32-specific patch. Do we want an evironment variable
> > for Unix?
>
> No, we do not. This entire thread has consisted of everyone but you
> objecting loudly to that idea.
They didn't sound very loud to me.
Why no
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I will make a Win32-specific patch. Do we want an evironment variable
> for Unix?
No, we do not. This entire thread has consisted of everyone but you
objecting loudly to that idea.
regards, tom lane
---
Magnus Hagander wrote:
> > > > > > As for how to do it - on Windows you *can* get the
> > path of the
> > > > > > DLL that is executing your code, using GetModuleFileName().
> > > > > > Hardly cross-platform, but can be done.
> > > > >
> > > > > That sounds pretty reasonable to me.
> > > >
> > >
Peter Eisentraut wrote:
> Am Donnerstag, 27. Mai 2004 15:03 schrieb Bruce Momjian:
> > I will make a Win32-specific patch. Do we want an evironment variable
> > for Unix? Seems folks do. I will work on that too.
>
> The gettext library already has an environment variable for that (NLSPATH I
>
> > > > > As for how to do it - on Windows you *can* get the
> path of the
> > > > > DLL that is executing your code, using GetModuleFileName().
> > > > > Hardly cross-platform, but can be done.
> > > >
> > > > That sounds pretty reasonable to me.
> > >
> > > True, and we already have our own fi
Am Donnerstag, 27. Mai 2004 15:03 schrieb Bruce Momjian:
> I will make a Win32-specific patch. Do we want an evironment variable
> for Unix? Seems folks do. I will work on that too.
The gettext library already has an environment variable for that (NLSPATH I
think). I don't know if we need a P
Magnus Hagander wrote:
> Seems it needs an implementation of the "pgwin32 special kill". Try
> stealing the one from backend/port/win32/signal.c (look for pqkill).
>
> Perhaps this function (not the rest of signal.c!) should be moved into
> port/, instead of backend/port. IIRC it depends on no ot
Peter Eisentraut wrote:
> Am Donnerstag, 27. Mai 2004 14:41 schrieb Bruce Momjian:
> > > > As for how to do it - on Windows you *can* get the path of the DLL that
> > > > is executing your code, using GetModuleFileName(). Hardly
> > > > cross-platform, but can be done.
> > >
> > > That sounds prett
Am Donnerstag, 27. Mai 2004 14:41 schrieb Bruce Momjian:
> > > As for how to do it - on Windows you *can* get the path of the DLL that
> > > is executing your code, using GetModuleFileName(). Hardly
> > > cross-platform, but can be done.
> >
> > That sounds pretty reasonable to me.
>
> True, and we
Peter Eisentraut wrote:
> Am Donnerstag, 27. Mai 2004 13:05 schrieb Magnus Hagander:
> > I don't beleive this is a windows-specific issue. It's a general issue
> > for all relocateable installs.
>
> Except that no one except Windows uses relocatable installs.
I don't think that is completely true
Am Donnerstag, 27. Mai 2004 07:31 schrieb Bruce Momjian:
> Sure, it is a hack, but what other option do we have? Do we somehow
> move the locale files into the library?
On Windows we use the feature that DLLs can locate themselves (described by
Magnus Hagander), and on Unix we forget about prete
Am Donnerstag, 27. Mai 2004 13:05 schrieb Magnus Hagander:
> I don't beleive this is a windows-specific issue. It's a general issue
> for all relocateable installs.
Except that no one except Windows uses relocatable installs.
> As for how to do it - on Windows you *can* get the path of the DLL th
> > You wouldn't expect the environment var to be set by an app
> in those
> > cases - it would be set by a sysadmin or an installer on a
> system-wide
> > basis when pg is installed in other than the hardcoded location. At
> > least, that's the way I understood Bruce's suggestion.
>
> Strang
Seems it needs an implementation of the "pgwin32 special kill". Try
stealing the one from backend/port/win32/signal.c (look for pqkill).
Perhaps this function (not the rest of signal.c!) should be moved into
port/, instead of backend/port. IIRC it depends on no other backend
code.
//Magnus
> --
Neither the version in CVS head nor the version you attached here links on
win32 (msys/mingw). I get the following:
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declaratio
ns pg_ctl.o
ec.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -lz -lreadli
ne -lwsock32 -lm
Gavin Sherry wrote:
Attached is my latest patch implementing tablespaces. This has all the
functionality I was planning for 7.5.
A few minor points I happened to notice while reading through the patch:
+ * To simply initialisation and XLog activity, have create and
maintain
+ * a symbolic link m
Compile error?
gmake[2]: Entering directory
`/space/1/home/chriskl/pgsql-server/src/timezone'
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../src/include -c -o pgtz.o pgtz.c -MMD
In file included from ../../src/include/storage/bufmgr.h:20,
Hi all,
Attached is my latest patch implementing tablespaces. This has all the
functionality I was planning for 7.5.
Most of the information about the patch is contained in the
patch/documentation, previous submissions and the archives.
Testing, review, comments would be greatly appreciated.
Ga
34 matches
Mail list logo
