"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Alternatively, we can just acquire AccessExclusiveLock on the main relation
> before proceeding with the recursive deletion. That would solve this case,
> but may be there are other similar deadlocks waiting to happen.
Surely we should be locking th
On Fri, May 16, 2008 at 1:17 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
>
> Surely we should be locking the relation before even doing the dependency scan
> or else someone else can come along and add more dependencies after we've
> started the scan?
>
Yeah, that's indeed possible. I could mak
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
If we're going to check for file length, we should definitely check the
file length when we write it, so that we fail at PREPARE time, and not
at COMMIT time.
I think this is mere self-delusion, unfortunately. You can never be
Hi Xiao Meng,
I am glad that you are making some progress. I have added a
couple of comments below. Your phased approach is a good way
to get it in a position for testing. I had a very basic test
for creation time, query time for a simple lookup, and index
size that I would like to re-run when you
Pavan Deolasee escribió:
> >> Also I am not sure if the issue is big enough to demand the change.
> >
> > I think it is, effectively what we have now is "your DDL could fail randomly
> > for reasons that are out of your control" :(
>
> Yeah. I think we better fix this, especially given the above
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It might be worth checking at prepare that the file size doesn't exceed
>> MaxAllocSize, but any smaller limit strikes me as (a) unnecessarily
>> restrictive and (b) not actually creating any useful guarantee.
> Patch attached.
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
>> Alternatively, we can just acquire AccessExclusiveLock on the main relation
>> before proceeding with the recursive deletion. That would solve this case,
>> but may be there are other similar deadlocks waiti
Am Samstag, 10. Mai 2008 schrieb Euler Taveira de Oliveira:
> This is a second try. Fix some issues pointed by Peter. It's a little
> fatter 'cause I worked on almost all of the strings. I attempted to
> mimic the postgresql style but I think that those strings need more work
> on as I pointed out
Am Sonntag, 11. Mai 2008 schrieb Euler Taveira de Oliveira:
> I forgot to say that this patch doesn't include nls support to ecpg
> files automagically. If you guys think that it's is a Good Thing to do,
> we need to hack the preproc.y to hardcode the locale stuff; if you
> decide that it isn't nec
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
It might be worth checking at prepare that the file size doesn't exceed
MaxAllocSize, but any smaller limit strikes me as (a) unnecessarily
restrictive and (b) not actually creating any useful guarantee.
Patch at
Peter Eisentraut wrote:
I forgot to say that this patch doesn't include nls support to ecpg
files automagically. If you guys think that it's is a Good Thing to do,
we need to hack the preproc.y to hardcode the locale stuff; if you
decide that it isn't necessary, we need to document that the nls
Xiao,
> Phase 1 seems extremely easy. I'm trying to do it first.
> Additionally, I need a benchmark to test the performance. It seems
> there's some tools list in
> http://wiki.postgresql.org/wiki/Performances_QA_testing . Any advice?
For a simple test, pgbench is actually going to be pretty good
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
second pass. There are 130 files in this list. Offhand I'd say the vast
majority should have markers.
Yeah, that list looks reasonably sane. The main thing I was worried
about was not plastering PostgreSQL markers on files t
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
>> Attached patch implements the extension found in the current SQL200n draft,
>> implementing stored start value and supporting ALTER SEQUENCE seq RESTART;
> Updated patch implements TRUNCATE ... RESTART IDENTITY
> which restarts all owned sequences
I wrote:
> One interesting point here is that the patch as submitted allowed
> ALTER SEQUENCE MINVALUE/MAXVALUE to be used to set a sequence range
> that the original START value was outside of. This would result in
> a failure at ALTER SEQUENCE RESTART. Since, as stated above, we
> really don't
On Fri, 2008-05-16 at 19:41 -0400, Tom Lane wrote:
> Applied with corrections. Most notably, since ALTER SEQUENCE RESTART
> is nontransactional like most other ALTER SEQUENCE operations, I
> rearranged things to try to ensure that foreseeable failures like
> deadlock and lack of permissions would
Neil Conway <[EMAIL PROTECTED]> writes:
> Ugh. The fact that the RESTART IDENTITY part of TRUNCATE is
> non-transactional is a pretty unsightly wort.
Actually, I agree. Shall we just revert that feature? The ALTER
SEQUENCE part of this patch is clean and useful, but I'm less than
enamored of the
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, that list looks reasonably sane. The main thing I was worried
>> about was not plastering PostgreSQL markers on files that are simply
>> imported from an upstream source, like the zic database and the
>> libstemmer files.
> The
Since ecpg localization was added today, I am unable to compile
src/interfaces/ecpg. I get:
$ gmake -w clean
gmake: Entering directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/ecpg'
rm -f
usage: rm [-dfiPRrW] file ...
gmake: *** [clean-po
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Since ecpg localization was added today, I am unable to compile
> src/interfaces/ecpg. I get:
> $ gmake -w clean
> gmake: Entering directory
> `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/ecpg'
> rm -f
> usage: rm
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Since ecpg localization was added today, I am unable to compile
> > src/interfaces/ecpg. I get:
>
> > $ gmake -w clean
> > gmake: Entering directory
> > `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/ecpg'
> >
Tom Lane wrote:
Huh, seems you have a remarkably picky version of "rm". None of the
machines I use seem to have a problem with an empty file list.
Don't see this problem here too.
Of course the underlying issue is that ecpg hasn't actually got any
translations yet --- but that's unlikely to
22 matches
Mail list logo
