I've got the CREATE TABLE AS restructuring almost finished, but came
across something that I could use some advice on. The current code
stores the into relation (and whether or not that relation has OIDs)
in the Query struct. This is ugly[1], but I'm not sure how to fix it.
The main reason Query
Hi everyone,
I think I'll be taking some time off from the PostgreSQL project, to
work on other stuff that has my interest more at the moment :)
I'll still be lurking around, but I won't really have much time to do
actual coding.
Cheers,
Chris
---(end of
On Sun, 17 Oct 2004 19:36:16 -0400, Tom Lane wrote:
Well, the spec is somewhat self-contradictory on the point, but I think
their intention is to model it after their notion of a deterministic
query:
A query expression or query specification is possibly non-
deterministic
One additional idea for this item is to use CREATE to first create the
object, then move it using ALTER, and the ALTER might fail if the
tablespace doesn't exist. The only problem with that is this TODO item:
o Allow databases and schemas to be moved to different tablespaces
On Sun, Oct 17, 2004 at 01:50:46PM -0400, Tom Lane wrote:
-Wdeclaration-after-statement (Recent versions of GCC allow declarations
and statements to be intermixed in C; enabling this flag would enforce
the current convention of avoiding this style.)
Ick. If the default is to allow
Dear Tom,
o remove non-portable TABLESPACE clause from CREATE TABLE and
use a new default_tablespace SET variable
I'm coming around to the conclusion that this is simply a bad idea.
I agree that the set approach is error prone.
Another idea was to issue an ALTER after the CREATE.
I just posted this idea with a new heading. ALTER seems like the right
approach, but notice we need to complete another TODO item to allow
tablespace movement of databases and schemas.
---
Fabien COELHO wrote:
Dear Tom,
At 2004-10-16 18:41:05 -0400, [EMAIL PROTECTED] wrote:
I think the cleanest solution is probably to add a state flag indicating
whether ParseComplete should generate a PGresult or not.
Like the appended (incremental) patch?
(I didn't think this would work, because I thought libpq would allow
The attached log from make on tsearch2 for windows demonstrates a
failure at the dllwrap stage, presumably as a result of changes just
made to handle the relative path thing discussed yesterday. It also
illustrates some other make and compile warnings I am seeing quite
frequently, and to which
As has previously been pointed out, the strings marked up for gettext
translation in the pgport library don't work and need to be moved back
to where they once came from, unless someone wants to add gettext and
locale setup in pgport. (That might be silly, because in theory locale
and gettext
Jeroen T. Vermeulen wrote:
IIRC it's a new feature in C99. If that is the case, you may want to
tell gcc simply to compile an older C dialect and get errors for all
such newfangled code.
We make occasional, optional use of C99 features, so we don't want to
turn it off completely.
--
Peter
Peter Eisentraut wrote:
As has previously been pointed out, the strings marked up for gettext
translation in the pgport library don't work and need to be moved back
to where they once came from, unless someone wants to add gettext and
locale setup in pgport. (That might be silly, because
Got this after a fresh cvs update -d -P:
../../../../src/include/storage/s_lock.h: In function `tas':
../../../../src/include/storage/s_lock.h:124: warning: read-write
constraint does not allow a register
../../../../src/include/storage/s_lock.h:124: warning: read-write
constraint does not allow
--On Montag, Oktober 18, 2004 17:23:47 +0200 Bernd Helmle
[EMAIL PROTECTED] wrote:
Got this after a fresh cvs update -d -P:
../../../../src/include/storage/s_lock.h: In function `tas':
../../../../src/include/storage/s_lock.h:124: warning: read-write
constraint does not allow a register
Hallo!
I have a big problem, could you please help me?
I am developing a DB System accociated with a File
server. The DB Server schould manage directories which
coulkd be, I thought, created through fired Triggers.
I wrote a C function and compiled as -shared. But its
not working. Is there
Bruce Momjian [EMAIL PROTECTED] writes:
One additional idea for this item is to use CREATE to first create the
object, then move it using ALTER, and the ALTER might fail if the
tablespace doesn't exist.
This seems fairly impractical, at least for indexes where there is no
way to do the ALTER
On Sun, Oct 17, 2004 at 11:16:50PM +1000, Neil Conway wrote:
Currently, the assembly for TAS() on x86 does a non-locking test before
using an atomic operation to attempt to acquire the spinlock:
__asm__ __volatile__(
cmpb$0,%1 \n
jne
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Do we want to backport tighter security for plperl? In particular,
insisting on Safe.pm = 2.09 and removing the :base_io set of ops?
I'd vote not: 7.4.5 = 7.4.6 is not an update that people would expect
to break their plperl code
Oliver Jowett [EMAIL PROTECTED] writes:
What appears to be happening is that the backend goes into error
recovery as soon as the allocation fails (just after reading the message
length), and never does the read() of the body of the Bind message. So
it falls out of sync, and tries to
On Oct 14, 2004, at 6:50 PM, Abhijit Menon-Sen wrote:
I thought about that for a while, but I couldn't find anything that is
actually broken or confused by the patch. I could be missing something
obvious, though, so I'd appreciate another set of eyes looking at it.
Does anyone have any ideas?
Not
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
One additional idea for this item is to use CREATE to first create the
object, then move it using ALTER, and the ALTER might fail if the
tablespace doesn't exist.
This seems fairly impractical, at least for indexes where there is no
Andrew Dunstan [EMAIL PROTECTED] writes:
../../src/Makefile.shlib:327: warning: overriding commands for target `libtsearch2.a'
../../src/Makefile.shlib:262: warning: ignoring old commands for target
`libtsearch2.a'
Broken coding in the WIN32 parts of Makefile.shlib? I don't see this
here.
Bruce Momjian [EMAIL PROTECTED] writes:
Error codes seem like a lot more work than it is worth. I vote for
adding gettext support to /port. Also adding error codes duplicates all
the error strings in the call sites.
Added to open items list:
* Add gettext support to src/port
He who
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Error codes seem like a lot more work than it is worth. I vote for
adding gettext support to /port. Also adding error codes duplicates all
the error strings in the call sites.
Added to open items list:
* Add gettext
When I run pg_ctl -w start I often see this on the log, which is less
than clear, if not downright confusing:
LOG: database system is ready
FATAL: the database system is starting up
Any ideas on how to improve this?
cheers
andrew
---(end of
Here is a mega-patch that merges in your four previous patches. Is this
ready to be applied? Making libpq changes during beta is risky so we
had better be careful.
I have also attached your pgtest.c file.
---
Abhijit
Bruce Momjian [EMAIL PROTECTED] writes:
Here is a mega-patch that merges in your four previous patches. Is this
ready to be applied? Making libpq changes during beta is risky so we
had better be careful.
I was planning to review the updated patch and apply if there was
nothing else major
Tom Lane wrote:
Somebody just yesterday stuck an
fprintf(stderr,...); exit(1) into one of the pgport routines. This
sucks, but there is not a lot else that can be done if the code needs
to exist in both backend and clients. It'd be better to propagate the
error condition back to the caller.
An
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Somebody just yesterday stuck an
fprintf(stderr,...); exit(1) into one of the pgport routines. This
sucks, but there is not a lot else that can be done if the code needs
to exist in both backend and clients. It'd be better to
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
At 2004-10-16 18:41:05 -0400, [EMAIL PROTECTED] wrote:
I think the cleanest solution is probably to add a state flag indicating
whether ParseComplete should generate a PGresult or not.
Like the appended (incremental) patch?
Not exactly --- the way
It was just added to CVS!
---
David Wheeler wrote:
On Oct 14, 2004, at 6:50 PM, Abhijit Menon-Sen wrote:
I thought about that for a while, but I couldn't find anything that is
actually broken or confused by the
On Oct 18, 2004, at 3:12 PM, Bruce Momjian wrote:
It was just added to CVS!
Awesome!
Abhijit++
Bruce++
Tom++
Regards,
David
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Mon, Oct 18, 2004 at 06:12:29PM -0400, Bruce Momjian wrote:
It was just added to CVS!
Woohooo!
Big, BIG kudos to all involved :) :)
Cheers,
D(BD::Pg)
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
I wrote:
Yeah. The intent of the protocol design was that the recipient could
skip over the correct number of bytes even if it didn't have room to
buffer them, but the memory allocation mechanism in the backend makes
it difficult to actually do that. Now that we have PG_TRY, though,
it
Neil Conway [EMAIL PROTECTED] writes:
I've got the CREATE TABLE AS restructuring almost finished, but came
across something that I could use some advice on. The current code
stores the into relation (and whether or not that relation has OIDs)
in the Query struct. This is ugly[1], but I'm not
On Mon, 18 Oct 2004, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
I've got the CREATE TABLE AS restructuring almost finished, but came
across something that I could use some advice on. The current code
stores the into relation (and whether or not that relation has OIDs)
in the
At 03:15 AM 19/10/2004, Bruce Momjian wrote:
The only downside is that it prevents SQL-compliant CREATE syntax in
dumps.
One idea that may be worth considering: we currently dump a complete SQL
statement including a TABLESPACE clause, which makes it hard to allow
pg_restore to have a 'no
Tom,
This would be of some value if the optimizer's cost estimates were
highly reliable, but unfortunately they are far from being so :-(
Without the ability to measure *actual* as opposed to estimated
costs, I'm not sure you can really do much.
In fact, any index selection tool that
Hi,
There are certainly cygwin-users trying out PostgreSQL on cygwin on WinXX. If the
newest cygwin-version will suddenly stop working under WinXX, they will not be happy.
I've given consideration to the argument that you can no longer take data-directories
from the cygwin-version to the
Dear Sirs,
I would like to know if there are any discussions about
creating an embedded version on postgresql. My thoughts
go towards building/porting a sqlite equivalent of pg.
Regards,
GB.
---(end of broadcast)---
TIP 8: explain analyze is your
Hi Bruce,
That would work!
Thanks
Peter
Bruce Momjian wrote:
One idea would be to use malloc() to allocate storage for the
thread-safe buffers when compiled with thread-safety, rather than using
the stack.
---
On Mon, 2004-10-18 at 11:53, Tom Lane wrote:
Only once we've begun to spin. The first time through, it's not at all
clear whether the extra test is worthwhile --- it's certainly a win if
the lock is always already held, and certainly a loss if the lock is
always free
Granted, but I think
Trying to think a little out of the box, how common is it in modern
operating systems to be able to swap out shared memory?
Maybe we're not using the ARC algorithm correctly after all. The ARC
algorithm does not consider the second level OS buffer cache in it's
design. Maybe the total size of
On 10/17/2004 3:40 PM, [EMAIL PROTECTED] wrote:
Seeing as I've missed the last N messages... I'll just reply to this
one, rather than each of them in turn...
Tom Lane [EMAIL PROTECTED] wrote on 16.10.2004, 18:54:17:
I wrote:
Josh Berkus writes:
First off, two test runs with OProfile are
Jan Wieck [EMAIL PROTECTED] writes:
I realized that StrategyDirtyBufferList currently wasts a lot of time by
first scanning over all the buffers that haven't even been hit since
it's last call and neither have been dirty last time (and thus, are at
the beginning of the list and can't be
o fix shared memory on Win2k terminal server
We might be able to just mark this as not supported.
I have attached a patch that I think fixes this. The problem I saw
and fixed is, that the shmem created in a terminal services client is not
visible to the console (or
Agreed on the memory name change and I will do it when I apply the
patch.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
o fix shared memory on Win2k terminal server
We might be able to just mark this as not supported.
I have attached a patch that I think fixes this. The problem I saw
and fixed is, that the shmem created in a terminal services
client is not
visible to the console (or services.msc).
48 matches
Mail list logo