Hello all,
I'm trying to modify the storage manager now.
I found a number of smgrs are stored separately in the storage manager
module (NSmgr in smgr.c and NStorageManagers in smgrtype.c),
and names of storage managers are stored in smgrtype.c.
Are there any reason for this?
I think they shold b
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
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.
---
Peter
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,
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 native
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
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 tablespa
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)
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'
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
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!
---
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
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
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
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 b
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 ava
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 --- t
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
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
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
>> 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 serv
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 Meno
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 broadcast)-
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
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
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
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 t
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 I
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 in
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.
-
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 cod
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"
> "
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 ALT
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 somewhe
--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
../../.
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
> 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.m
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, becaus
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.
--
Pete
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
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
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 allo
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
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 CREA
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 a
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
One
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 or is possibly non-
> deterministic if an SQL-implementation migh
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 broadcast)--
48 matches
Mail list logo
