I just saw this in my logs:
2002-09-18 12:13:10 ERROR: cannot open segment 1 of relation users_sessions
(target block 1342198864): No such file or directory
This query caused it:
DELETE FROM users_sessions WHERE changed ('now'::timestamp - '1440
minutes'::interval) AND name = 'fhnid';
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Note that if you write, say,
set numericcol = numericcol * 3.14159;
my proposal would do the right thing since the constant would be typed
as numeric to start with and would stay that way. To do what you want
with a float variable,
PS: pg snapshot 09/11 does not compile on AIX (large files (don't want
_LARGE_FILES),
Please provide details.
On AIX we would only want to make the large file api visible (_LARGE_FILE_API)
which automatically gets defined when xlc is used with -qlonglong.
#ifdef _LARGE_FILE_API
extern
Hello,
I am trying to debug a problem involving DBD::PgSPI that crashes the
backend. It used to work fine util we installed perl-5.8. How can I get
a core file of a crashed backend on a debian-linux (unstable) machine?
My /etc/security/limits.conf is empty. When I login as root ulimit -c
shows
On Thu, 2002-09-19 at 11:18, Louis-David Mitterrand wrote:
Hello,
I am trying to debug a problem involving DBD::PgSPI that crashes the
backend. It used to work fine util we installed perl-5.8. How can I get
a core file of a crashed backend on a debian-linux (unstable) machine?
My
On Thu, Sep 19, 2002 at 12:17:15PM +0100, Oliver Elphick wrote:
On Thu, 2002-09-19 at 11:18, Louis-David Mitterrand wrote:
I am trying to debug a problem involving DBD::PgSPI that crashes the
backend. It used to work fine util we installed perl-5.8. How can I get
a core file of a
On Thu, 19 Sep 2002, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Thu, 19 Sep 2002, Bruce Momjian wrote:
It is an open issue. It has to be resolved. When it is, I will remove
it. I added a question mark to it but it needs to be tracked. I keep
having to add and remove it
Bruce Momjian [EMAIL PROTECTED] writes:
Looking at the open item list, I see:
fix up function return types on lang/type/trigger creation or
loosen opaque restrictions
Seems that should be fixed before beta2 because it does effect people
loading data.
Yeah, we should do
On Wed, 2002-09-18 at 22:24, Marc G. Fournier wrote:
On Wed, 18 Sep 2002, Bruce Momjian wrote:
Sorry, I don't see the logic here. Using postgresql.conf, you set it
once and it remains set until you change it again. With -X, you have to
use it every time. I think that's where the votes
Marc G. Fournier [EMAIL PROTECTED] writes:
Who implemented SIMILAR TO in the first place?
Thomas. He put in the syntax, but as it stands it's simply syntactic
sugar for ~ --- that is, our Posix-compatible regex match operator.
Since the spec demands very non-Posix behavior, this is wrong.
Marc G. Fournier [EMAIL PROTECTED] writes:
Right, so you have two telling you to remove it, one telling you to add
it, and two that are discussion why/if it *should* be added ... Tom feels
it should be added, and I'm clarifing the why of it ... don't re-add it
until we've determined *if* it
I think Marc made a pretty good case about the use of command line
arguments but I think I have to vote with Tom. Many of the command line
arguments you seem to be using do sorta make sense to have for easy
reference or to help validate your runtime environment for each
instance. The other side
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Yes, that is the case where the new behavior would imho not be good (but you
say spec compliant). I loose precision even though there is room to hold it.
Lose what precision? It seems silly to imagine that the product of
Have you seen
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I just saw this in my logs:
2002-09-18 12:13:10 ERROR: cannot open segment 1 of relation users_sessions
(target block 1342198864): No such file or directory
This query caused it:
DELETE FROM users_sessions WHERE changed ('now'::timestamp
Yes, that is the case where the new behavior would imho not be good (but you
say spec compliant). I loose precision even though there is room to hold it.
Lose what precision? It seems silly to imagine that the product of
Have you seen my example ? If calculated in float4 the
On Thu, Sep 19, 2002 at 04:57:30PM +0200, Zeugswetter Andreas SB SD wrote:
Have you seen my example ? If calculated in float4 the result of
1.01*1000.0-1000.0 would be 0.0, no ?
So? If you are storing one input as float4, then you cannot rationally
say that you
On Thu, Sep 19, 2002 at 10:30:51AM -0500, Ross J. Reedstrom wrote:
Ah, sorry to drag this on, then. But this is one of those clear cases
were we must fo the right thing, not follow the crowd. PostgreSQL gets
do
used by a lot of scientific projects (Have you noticed all the big
Have you seen my example ? If calculated in float4 the result of
1.01*1000.0-1000.0 would be 0.0, no ?
So? If you are storing one input as float4, then you cannot rationally
say that you know the result to better than 6 digits, because you don't
know the input
On Thu, Sep 19, 2002 at 06:00:37PM +0200, Zeugswetter Andreas SB SD wrote:
What if he must display 9 digits and says the result is approximately 2.45678932
would that be worse than 2.4600 ?
Yup. Trailing zeros are not significant. That's why scientific notation is nice:
you don't fill
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
For above calculation pg will in the future return 0. as an
answer to 1.01*1000.0-1000.0 when used in my example context, while
it currently returns 0.0010 ...
You both are saying, that
On 19 Sep 2002 at 11:19, Johnson, Shaunn wrote:
--howdy:
--not that the process is doing a lot or taking up
--a lot of resources, it's just something
--that i allow the users to kill and then
--it get's passed to me for correction if the
--simple 'kill pid' thing doesn't work.
--what
Tom Lane wrote:
AFAICS, getting SIMILAR TO to operate per spec would require adding some
sort of translation function that converts the spec-style pattern into
a Posix pattern that our regex match engine would handle. This would at
least require adding ^ and $ around the pattern, converting
Shridhar Daithankar [EMAIL PROTECTED] writes:
I guess a backend should terminate as if connection is closed. What say?
No.
It will terminate when it tries to read the next query from the client.
regards, tom lane
---(end of
On 19 Sep 2002 at 11:49, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
I guess a backend should terminate as if connection is closed. What say?
No.
It will terminate when it tries to read the next query from the client.
OK. But what if it never reads anything? I mean
Johnson, Shaunn [EMAIL PROTECTED] writes:
--okay, but the client has since terminated
--it's session (if i understand you correctly).
--is this just something that will just have to
--hang around until i shutdown the database / boot
--the machine?
I dunno. Are you sure this is a backend
Ian Harding [EMAIL PROTECTED] writes:
It is pltcl [not plpgsql]
Ah. I don't think we've done much of any work on plugging leaks in
pltcl :-(.
It hurts when I do this:
drop function memleak();
create function memleak() returns int as '
for {set counter 1} {$counter 10} {incr counter}
On Thu, 19 Sep 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Who implemented SIMILAR TO in the first place?
Thomas. He put in the syntax, but as it stands it's simply syntactic
sugar for ~ --- that is, our Posix-compatible regex match operator.
Since the spec demands
On Thu, 19 Sep 2002, Robert Treat wrote:
I don't know if I agree with that. Most servers (apache for instance) have
configuration variables on where files are going to live, not command line
options.
Not where it involves *critical* files:
OPTIONS
-R libexecdir
I said:
Yeah, I see very quick memory exhaustion also :-(. Looks like the
spi_exec call is the culprit, but I'm not sure exactly why ...
anyone have time to look at this?
On looking a little more closely, it's clear that pltcl_SPI_exec()
should be, and is not, calling SPI_freetuptable() once
Tom Lane wrote:
I said:
Yeah, I see very quick memory exhaustion also :-(. Looks like the
spi_exec call is the culprit, but I'm not sure exactly why ...
anyone have time to look at this?
On looking a little more closely, it's clear that pltcl_SPI_exec()
should be, and is not, calling
[EMAIL PROTECTED] writes:
Not to_ascii, since there are so many extended UNICODE characters that
doesn't have any accent and should not be converted to an ASCII character.
Really, the accent conversion should be part of the character set
conversion routines. At least my local iconv does
Tatsuo Ishii writes:
The conversion named SJIS is different from IANA's shift_jis. It
actually matches Windows-31J in IANA, which is too ugly to being
emploied as our conversion name, IMO.
OK
I agree with win1250 - windows_1250, win1251 - windows_1251, but do
not agree with renaming
Hi everyone,
Am trying my hand at a bit of C code again. Specifically am trying to
get Tatsuo's pgbench code to loop around more than once, but it keeps
on hanging forever at this line:
if ((nsocks = select(maxsock + 1, input_mask, (fd_set *) NULL,
(fd_set *) NULL, (struct timeval *)
Hi,
is a pl/pgSQL function completely parsed once? Or is only the next
statement parsed as with many interpreters? If it's the latter it would
mean one has to run each branch just to see if the syntax is correct. Is
that true?
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein
Michael Meskes wrote:
Hi,
is a pl/pgSQL function completely parsed once? Or is only the next
statement parsed as with many interpreters? If it's the latter it would
mean one has to run each branch just to see if the syntax is correct. Is
that true?
Michael
If the docs are true, than
Michael Paesold wrote:
Michael Meskes wrote:
Hi,
is a pl/pgSQL function completely parsed once? Or is only the next
statement parsed as with many interpreters? If it's the latter it would
mean one has to run each branch just to see if the syntax is correct. Is
that true?
I've definitely seen errors from including vacuum and/or analyze
statements in functions, I think I've seen crashes too. If you check the
docs I'm pretty sure they mention the specifics of not being able to use
such statements.
Robert Treat
On Wed, 2002-09-18 at 04:09, Michael Paesold wrote:
[ back to thinking about this patch ]
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane dijo:
One corner case is that I think we currently allow
create table p (f1 int);
create table c (f1 int) inherits(p);
In this case, c.f1.attisinherited count is 2; thus when I drop f1 from
p, it is
On Thu, 19 September 2002, Marc G. Fournier wrote:
On Thu, 19 Sep 2002, Robert Treat wrote:
gt; Well, as with most (all?) GUC variables, wouldn't you have the option of
gt; doing postmaster -o quot;pgxlog=/dev/nullquot; and have the same
functionality
gt; as -X ?
True, but then that
On Thu, 19 Sep 2002, Peter Eisentraut wrote:
Tatsuo Ishii writes:
The conversion named SJIS is different from IANA's shift_jis. It
actually matches Windows-31J in IANA, which is too ugly to being
emploied as our conversion name, IMO.
OK
I agree with win1250 - windows_1250, win1251 -
It seems all of this discussion misses the point. Either it has a large
amount of impact and the idea gets rejected because of implementation
issues, or it has little impact but it's nothing the core group wants to
implement. If the problem is finding someone to implement it, it sounds
like
Mike Mascari wrote:
Bruce Momjian wrote:
I am working with several groups getting the Win32 port ready for 7.4
and I have a few questions:
What is the standard workaround for the fact that rename() isn't atomic
on Win32? Do we need to create our own locking around the
Robert Treat wrote:
It seems all of this discussion misses the point. Either it has a large
amount of impact and the idea gets rejected because of implementation
issues, or it has little impact but it's nothing the core group wants to
implement. If the problem is finding someone to implement
Ian Harding [EMAIL PROTECTED] writes:
It is pltcl [not plpgsql]
Quick, minor point, in the manner of a question:
Why is the pltcl directory called tcl where all the other pls are pllanguage?
That's in src/pl of course. Also in my anoncvs fetch which is a few weeks old
now being from the
Nigel J. Andrews wrote:
Ian Harding [EMAIL PROTECTED] writes:
It is pltcl [not plpgsql]
Quick, minor point, in the manner of a question:
Why is the pltcl directory called tcl where all the other pls are pllanguage?
I asked the same question a while ago. I asked about changing it
Nigel J. Andrews [EMAIL PROTECTED] writes:
Why is the pltcl directory called tcl where all the other pls are pllanguage?
Consistency? We don't need no steenking consistency!
Personally I'd prefer to remove the pl prefix from the other
subdirectories of src/pl/ ... it seems redundantly wasted
Tom Lane writes:
Yeah, we should do something with that. Are people okay with the idea
of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE
to the correct thing?
Seems like an appropriate time to throw a notice, though.
--
Peter Eisentraut [EMAIL PROTECTED]
Marc G. Fournier writes:
My point is, the functionality is there, and should be documented properly
... encourage ppl to use the GUC setting in postmaster.conf, but just
because you can't grasp that some of us *like* to use command line args,
don't remove such functionality ...
Top secret
Zeugswetter Andreas SB SD writes:
configure somehow thinks it needs to #define _LARGE_FILES though, which
then clashes with pg_config.h's _LARGE_FILES. I think the test needs to
#include unistd.h .
_LARGE_FILES is defined because it's necessary to make off_t 64 bits. If
you disagree, please
While adding schema support to the JDBC Driver, I came across a query
which occasionally generates some spectacularly bad plans. I have
attached the query and explain analyze outputs against today's cvs head
for queries that take between 9 and 845941 msec. In the JDBC Driver I
will specify
Kris Jurka [EMAIL PROTECTED] writes:
While adding schema support to the JDBC Driver, I came across a query
which occasionally generates some spectacularly bad plans.
Hm, does an ANALYZE help?
regards, tom lane
---(end of
Kris Jurka [EMAIL PROTECTED] writes:
While adding schema support to the JDBC Driver, I came across a
query which occasionally generates some spectacularly bad plans.
Interesting. The inconsistency you're seeing is a result of GEQO. I
would have hoped that it would have produced a better
On Thu, 19 Sep 2002, Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
While adding schema support to the JDBC Driver, I came across a query
which occasionally generates some spectacularly bad plans.
Hm, does an ANALYZE help?
Yes, it does, but I don't understand why. The query is
Neil Conway [EMAIL PROTECTED] writes:
Interesting. The inconsistency you're seeing is a result of GEQO. I
would have hoped that it would have produced a better quality plan
more often, but apparently not. On my system, the regular query
optimizer handily beats GEQO for this query: it produces
Will the new casting stuff address this kind of annoyance?
usa=# select average(octet_length(val)) from users_sessions;
ERROR: Function 'average(int4)' does not exist
Unable to identify a function that satisfies the given argument
types
You may need to add explicit typecasts
DELETE FROM users_sessions WHERE changed ('now'::timestamp - '1440
minutes'::interval) AND name = 'fhnid';
What does EXPLAIN show as the plan for that query? I'm guessing an
indexscan, and that the error was caused by reading a broken item
pointer from the index. (1342198864 = hex
That seems right, but the problem I have with it is that the resulting
state of c.f1 is attisinherited = 1. This means that you cannot drop
c.f1. It seems to me that we should have this behavior:
Has anyone given much thought as to perhaps we could just drop multiple
inheritance from
Christopher Kings-Lynne wrote:
That seems right, but the problem I have with it is that the resulting
state of c.f1 is attisinherited = 1. This means that you cannot drop
c.f1. It seems to me that we should have this behavior:
Has anyone given much thought as to perhaps we could just
Doh - I'm stupid. Ignore my question :)
Helps if you spell 'average' as 'avg' :)
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Christopher
Kings-Lynne
Sent: Friday, 20 September 2002 10:03 AM
To: Tom Lane; Zeugswetter Andreas SB SD
Cc:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Will the new casting stuff address this kind of annoyance?
usa=# select average(octet_length(val)) from users_sessions;
ERROR: Function 'average(int4)' does not exist
regression=# select * from pg_proc where proname = 'average';
proname |
Bruce Momjian wrote:
Second, when you unlink() a file on Win32, do applications continue
accessing the old file contents if they had the file open before the
unlink?
unlink() just calls DeleteFile() which will error if:
1. The target file is in use
CreateFile() has the
Bruce Momjian [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
Has anyone given much thought as to perhaps we could just drop multiple
inheritance from Postgres?
I am for it. Multiple inheritance is more of a mess than a help.
I'm not agin it ... but if that's the lay of the land
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
Has anyone given much thought as to perhaps we could just drop multiple
inheritance from Postgres?
I am for it. Multiple inheritance is more of a mess than a help.
I'm not agin it ... but if
I am for it. Multiple inheritance is more of a mess than a help.
I'm not agin it ... but if that's the lay of the land then we have
no need to apply a last-minute catalog reformatting to fix a
multiple-inheritance bug. This patch is off the must fix for 7.3
list, no?
Multiple
Can I buy an extra day or two? I'm in DC till Saturday then there's the
trip home. How 'bout a wednesday beta release?
On Thu, 19 Sep 2002, Marc G. Fournier wrote:
On Wed, 18 Sep 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
... I'm going to do up a beta2 on Friday
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not agin it ... but if that's the lay of the land then we have
no need to apply a last-minute catalog reformatting to fix a
multiple-inheritance bug. This patch is off the must fix for 7.3
list, no?
I don't think a few days
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not agin it ... but if that's the lay of the land then we have
no need to apply a last-minute catalog reformatting to fix a
multiple-inheritance bug. This patch is off the must fix for 7.3
list, no?
I
The decision at hand is whether to apply a patch. You cannot say we're
not deciding now, because that is a decision...
Yes. I am saying we should not assume we are going to remove multiple
inheritance. We should apply the patch and make things a good as they
can be for 7.3.
I think
Tom Lane [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
Has anyone given much thought as to perhaps we could just drop
multiple inheritance from Postgres?
I am for it. Multiple inheritance is more of a mess than a help.
I'm not agin
On Fri, 20 Sep 2002, Christopher Kings-Lynne wrote:
DELETE FROM users_sessions WHERE changed ('now'::timestamp - '1440
minutes'::interval) AND name = 'fhnid';
What does EXPLAIN show as the plan for that query? I'm guessing an
indexscan, and that the error was caused by reading a
Christopher Kings-Lynne writes:
Is there some reason why we didn't call text 'clob' and bytea 'blob'?
At the time our types were created there was no standard defining the
other types.
or at least add aliases?
Mapping clob to text might be OK, but blob and bytea have totally
different input
Christopher Kings-Lynne writes:
Should someone just go though contrib/ and add GRANT EXECUTE on everything?
Seems pointless doing it ad hoc by the maintainer as it is at the moment...?
Please.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
On Thu, 19 Sep 2002, Joe Conway wrote:
Tom Lane wrote:
I said:
Yeah, I see very quick memory exhaustion also :-(. Looks like the
spi_exec call is the culprit, but I'm not sure exactly why ...
anyone have time to look at this?
On looking a little more closely, it's clear that
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Yeah, we should do something with that. Are people okay with the idea
of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE
to the correct thing?
Seems like an appropriate time to throw a notice, though.
Of
Nigel J. Andrews wrote:
On Thu, 19 Sep 2002, Joe Conway wrote:
I can give it a shot, but probably not until the weekend.
I haven't really followed this thread closely, and don't know tcl very well,
so it would help if someone can send me a minimal tcl function which triggers
the problem.
I
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Yeah, we should do something with that. Are people okay with the idea
of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE
to the correct thing?
Seems like an appropriate time to throw a
Christopher Kings-Lynne wrote:
Hi,
Should someone just go though contrib/ and add GRANT EXECUTE on everything?
Seems pointless doing it ad hoc by the maintainer as it is at the moment...?
Added to open item list:
Add GRANT EXECUTE to all /contrib functions
--
Bruce Momjian
Congratulations. That is the largest plan I have ever seen. ;-)
---
Kris Jurka wrote:
While adding schema support to the JDBC Driver, I came across a query
which occasionally generates some spectacularly bad plans. I
Index Scan using users_sessions_cha_name_idx on users_sessions
(cost=0.00..12738.07 rows=1275 width=6) (actual
time=231.74..239.39 rows=2
loops=1)
Total runtime: 239.81 msec
EXPLAIN
The size of the table:
canaveral# ls -al 44632
-rw--- 1 pgsql pgsql 357130240 Sep 19
Bruce Momjian wrote:
Mike Mascari wrote:
I will do some testing with concurrency and let you know. But
don't get your hopes up. This is one of the many advantages that
TABLESPACEs have when more than one relation is stored in a
single DATAFILE. There was Oracle for MS-DOS, after all..
Mike Mascari wrote:
Bruce Momjian wrote:
Mike Mascari wrote:
I will do some testing with concurrency and let you know. But don't
get your hopes up. This is one of the many advantages that
TABLESPACEs have when more than one relation is stored in a single
DATAFILE. There was Oracle for
Mike Mascari wrote:
Actually, looking at the pg_pwd code, you want to determine a
way for:
1. Process 1 opens foo
2. Process 2 opens foo
3. Process 1 creates bar
4. Process 1 renames bar to foo
5. Process 2 can continue to read data from the open file handle
and get the original foo
Bruce Momjian wrote:
Mike Mascari wrote:
Actually, looking at the pg_pwd code, you want to determine a
way for:
1. Process 1 opens foo
2. Process 2 opens foo
3. Process 1 creates bar
4. Process 1 renames bar to foo
5. Process 2 can continue to read data from the open file handle
and get the
On Fri, 20 Sep 2002, Mike Mascari wrote:
Bruce Momjian wrote:
Mike Mascari wrote:
Actually, looking at the pg_pwd code, you want to determine a
way for:
1. Process 1 opens foo
2. Process 2 opens foo
3. Process 1 creates bar
4. Process 1 renames bar to foo
5. Process 2 can continue
Stephan Szabo wrote:
On Fri, 20 Sep 2002, Mike Mascari wrote:
Bruce Momjian wrote:
Mike Mascari wrote:
Actually, looking at the pg_pwd code, you want to determine a
way for:
1. Process 1 opens foo
2. Process 2 opens foo
3. Process 1 creates bar
4. Process 1 renames bar to foo
5. Process 2 can
On Fri, 20 Sep 2002, Mike Mascari wrote:
Stephan Szabo wrote:
On Fri, 20 Sep 2002, Mike Mascari wrote:
So far, MoveFileEx(foo, bar, MOVEFILE_REPLACE_EXISTING)
returns Access Denied when Process 1 attempts the rename. But
I'm continuing to investigate the possibilities...
Does a
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Yeah, we should do something with that. Are people okay with the idea
of CREATE LANGUAGE, etc, retroactively changing prorettype from OPAQUE
to the correct thing?
Seems
Well I was really hoping pg_constraint would solve all my problems, but
since contrib/array is not installed by default the conkeys and confkeys
columns aren't terribly useful because they can't be joined to
pg_attribute.
Also there is not a column to tell you the unique constraint that
Maybe not nice, but there's only 32 (64 now?) of them...
JOIN pg_attribute WHERE attnum IN (conkeys[1], conkeys[2], conkeys[3],
..., conkeys[32])
Great fun...
On Thu, 2002-09-19 at 18:31, Kris Jurka wrote:
Well I was really hoping pg_constraint would solve all my problems, but
since
Patch applied. Thanks.
---
Oleg Bartunov wrote:
Tiny patch fixing small documentation typo.
Regards,
Oleg
_
Oleg Bartunov,
Bruce Momjian wrote:
Bruce Momjian wrote:
unlink() just calls DeleteFile() which will error if:
1. The target file is in use
CreateFile() has the option:
FILE_FLAG_DELETE_ON_CLOSE
which might be able to be used to simulate traditional unlink()
behavior.
No, that flag isn't going to help
Mike Mascari wrote:
I read the article and did not come away with that conclusion.
The article describes using the MOVEFILE_DELAY_UNTIL_REBOOT
flag, which was created for the express purpose of allowing a
SETUP.EXE to remove itself, or rather tell Windows to remove it
on the next reboot.
92 matches
Mail list logo
