Tom Lane wrote:
In service of the refactoring of error handling that I was talking about
a few days ago, I'm finding that there are several places that really
ought to catch longjmps and clean up after themselves, instead of
expecting that whatever mess they've made will be cleaned up for them
when
When I run through the acl changing all references from the old owner to
the new owner, should I combine the resulting acls if possible? Because
if the new owner already has some acls on that item, they will end up
with two acls.
If possible ... how painful would it be to do?
I'm pretty close t
> Does anyone have a problem with this macro syntax? The try/catch names
> are stolen from Java, so I'm figuring they won't terribly surprise any
> modern programmer, but I'm open to different names if anyone has a
> better idea.
I have done such a macro hiding of setjmp/longjmp for a math libra
I am download the 7.5 devel installer version, when I try install in win2000,
I encountered a error, the below is the log:
=
The files belonging to this database system will be owned by user "postgres".This user must also own the server process.
The
On Wed, Jul 28, 2004 at 08:19:17PM -0400, Tom Lane wrote:
Very cool and interesting idea.
> Does anyone have a problem with this macro syntax? The try/catch names
> are stolen from Java, so I'm figuring they won't terribly surprise any
> modern programmer, but I'm open to different names if anyo
On Wed, 28 Jul 2004, Tom Lane wrote:
> In service of the refactoring of error handling that I was talking about
> a few days ago, I'm finding that there are several places that really
> ought to catch longjmps and clean up after themselves, instead of
> expecting that whatever mess they've made wi
In service of the refactoring of error handling that I was talking about
a few days ago, I'm finding that there are several places that really
ought to catch longjmps and clean up after themselves, instead of
expecting that whatever mess they've made will be cleaned up for them
when control gets ba
[ Sorry, sent to hackers now.]
Here is another open PITR issue that I think will have to be addressed
in 7.6. If you do a critical transaction, but do nothing else for eight
hours, that critical transaction hasn't been archived yet. It is still
sitting in pg_xlog until the WAL file fills.
I th
Oh, here is something else we need to add --- a GUC to control whether
pg_xlog is clean on recovery start.
---
Tom Lane wrote:
> Bruce and I had another phone chat about the problems that can ensue
> if you restore a tar bac
We need someone to code two backend functions to complete PITR. The
function would be called at start/stop of backup of the data directory.
The functions would be checked during restore to make sure the requested
xid is not between the start/stop xids of the backup. They would also
contain times
Andrew Dunstan wrote:
> >I wanted to keep a solution that was as native to the OS as possible,
> >but because we can't do that on Win32 and few people like the unix
> >system call to 'rm', it is time to clean it up.
> >
> >One question --- why is there a sleep loop needed for unlink in your
> >patc
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The small wrinkle here is that rmtree needs to make a copy of the file
> names before it starts removing things. In the backend case that means
> calling palloc() and friends - am I correct in assuming it is reasonable
> to do this in whatever context
Bruce Momjian wrote:
Dave, now that we are nearing beta, I think we need to correct the
initdb problem with removing the directory on Win32. Would you code
this up as something that sits in /port/dirmod.c and have both initdb
and DROP DATABASE call the C routine rather than call rm -r/rmdir? (I
[ cc'ing pghackers in case anyone wants to object ]
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Right now I think the sanest behavior would be to throw an error on
>> non-rectangular input. Once we have support for null elements in
>> arrays, however, it would arguably be reasonab
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 28 July 2004 09:29
To: Dave Page
Cc: Tom Lane; PostgreSQL-development; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Cannot initdb in cvs tip
Dave, now that we are nearing beta, I think we need to
cor
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 28 July 2004 09:29
> To: Dave Page
> Cc: Tom Lane; PostgreSQL-development; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Cannot initdb in cvs tip
>
>
> Dave, now that we are nearing beta, I think we need to
> c
Dave, now that we are nearing beta, I think we need to correct the
initdb problem with removing the directory on Win32. Would you code
this up as something that sits in /port/dirmod.c and have both initdb
and DROP DATABASE call the C routine rather than call rm -r/rmdir? (I
think those are the o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marc G. Fournier wrote:
|
| all fixed ... had a kernel panic this morning, and fsck took a while to
| run ...
Also news.fr.postgresql.org it seems down since yesterday.
Regards
Gaeatano Mendola
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Min
18 matches
Mail list logo
