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 the
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 make that
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
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 mentioned
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. I can't
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 waiting to
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 in
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
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
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
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 for the
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 want
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 be
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
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'
rm -f
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
18 matches
Mail list logo
