> > > Earlier, Vadim was talking about arranging to share fsyncs of the WAL
> > > log file across transactions (after writing your commit record to the
> > > log, sleep a few milliseconds to see if anyone else fsyncs before you
> > > do; if not, issue the fsync yourself). That would offer less-th
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I think that int32 etc are better choices at the C level because of
> >> the well-established precedent for naming integer types after numbers
> >> of bits in C code. I don't feel any strong urge to go around and
> >> change the existing misusages,
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I think that int32 etc are better choices at the C level because of
>> the well-established precedent for naming integer types after numbers
>> of bits in C code. I don't feel any strong urge to go around and
>> change the existing misusages, but if yo
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Which one of these should we use?
> > int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
> > DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
> > PG_GETARG_INT32 et al. Inconsistency everywhere.
>
> The origin
Can someone tell me where we are on this? Tatsuo, I think you said you
wanted to apply this fix.
> [Cced to hackers list]
>
> > > BTW I have found another bug with EUC_TW support. line 917 in conv.c:
> > >
> > > *p++ = c1 - LC_CNS11643_3 + 0xa3;
> > >
> > > this should
Applied.
> Here is one with a stray character removed.
>
>
> Index: src/backend/utils/misc/guc-file.l
> ===
> RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
> retrieving revision 1.4
> diff -c -r
Sorry, this was not applied. Seems it is already fixed.
> * Peter Eisentraut <[EMAIL PROTECTED]> [001113 23:52]:
> > Okay, but you can't make these options PGC_SIGHUP unless you make sure to
> > close and re-open the syslog channel whenever these options
> > change. Probably ought to be PGC_P
Applied.
> * Peter Eisentraut <[EMAIL PROTECTED]> [001113 23:52]:
> > Okay, but you can't make these options PGC_SIGHUP unless you make sure to
> > close and re-open the syslog channel whenever these options
> > change. Probably ought to be PGC_POSTMASTER.
> Here is a patch to change to PGC_POS
[ Charset ISO-8859-1 unsupported, converting... ]
> > Earlier, Vadim was talking about arranging to share fsyncs of the WAL
> > log file across transactions (after writing your commit record to the
> > log, sleep a few milliseconds to see if anyone else fsyncs before you
> > do; if not, issue the
> * Peter Eisentraut <[EMAIL PROTECTED]> [001115 08:15] wrote:
> >
> > I couldn't say I like these options, because they seem arbitrary, but
> > given that it only affects the 0 univel users and the 3 bsdi users left
> > (freebsd will be fixed), I wouldn't make a fuzz.
>
> BSDi still has a marke
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> and make "/tmp" the default in guc.c.
> >>
> >> No, because this has to work on the client side too. The default path
> >> *must* be determined at compile time, or clients and servers will be
> >> unable to find each othe
At 23:42 15/11/00 -0500, Bruce Momjian wrote:
>> To answer another misconception that I saw in this thread:
>>
>> : The old language names "internal" and "C" will continue to refer to
>> : functions with the old calling convention. We should deprecate
>> : old-style functions because of their po
> 4. SearchSysCacheTupleCopy() goes away, since we may as well use
>SearchSysCacheTuple() and ReleaseSysCache() instead of
>SearchSysCacheTupleCopy() and heap_freetuple().
Agreed. The rest sounds good too.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PR
> To answer another misconception that I saw in this thread:
>
> : The old language names "internal" and "C" will continue to refer to
> : functions with the old calling convention. We should deprecate
> : old-style functions because of their portability problems, but the
> : support for them wi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Which one of these should we use?
> int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
> DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
> PG_GETARG_INT32 et al. Inconsistency everywhere.
The original convention
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> To start with, what do we need libtermcap and libcurses for? Readline
> requires one or the other, but not both. Anything else?
I think that psql once required these. It probably does not anymore
(except indirectly via readline). There's certainl
One question:
will Postgres 7.1 be able to do offline backups?
--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-
Martín Marqués email: [EMAIL PROTECTED]
Santa Fe - Argentinah
Here is one with a stray character removed.
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.4
diff -c -r1.4 guc-file.l
*** src/back
* Peter Eisentraut <[EMAIL PROTECTED]> [001115 13:11]:
> Larry Rosenman writes:
>
> > > syntax is lexically compatible with the syntax of the SET command.
> > > Therefore you can't have "funny" characters in 'value' unless
> > > single-quoted.
> > I added period(.), hyphen(-), and underscore(_)
Which one of these should we use?
int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
PG_GETARG_INT32 et al. Inconsistency everywhere.
The C standard has things like int32_t, but technically there's no
guarantee
So Sun has pulled another one on us. Not sure which versions of Solaris
this affects, but some have libncurses and libtermcap with overlapping
symbols of different sizes. This leads to a bunch of complaints every
time 'ld' is run; perhaps it could also lead to busted executables.
(Via a complex
> > I am just suggesting that instead of flushing the log on every
> > transaction end, just do it every X seconds.
>
> Or maybe more practical is, when the log buffer fills.
> And of course during checkpoints.
Also before backend's going to write dirty buffer from pool
to system cache - change
markw <[EMAIL PROTECTED]> writes:
> Just a question, however, what is the feeling about the way statistics are
> currently being calculated?
They suck, no question about it ;-)
> My feeling is that some sort of windowing
> algorithm be used to normalize the statistics to the majority of the entr
At 01:53 PM 11/15/00 -0500, markw wrote:
>I'd rather not pollute the application's SQL with postgres-isms. Not that I
>don't love postgres, but there are always critics looking for a reason to use
>Oracle or (gasp) MS-SQL.
Define some global variable with the name of the database being run (curr
> Earlier, Vadim was talking about arranging to share fsyncs of the WAL
> log file across transactions (after writing your commit record to the
> log, sleep a few milliseconds to see if anyone else fsyncs before you
> do; if not, issue the fsync yourself). That would offer less-than-
> one-fsync-
Andrew McMillan wrote:
> mlw wrote:
> >
> > My music database has 50,000 arises and 210,000 albums. Many artists
> > have only one or 2 entries in the albums table (for the youngsters, CD
> > table ;-). About 34,000 have the integer key for "Various Artists" as
> > their artist entry, and another
At 09:27 AM 11/15/00 -0800, Tom Samplonius wrote:
> AOLServer isn't the only system that can pool database connections, so
>can servlets/JSP, ColdFusion, ASP, etc. No doubt AOLServer would be more
>widely accepted if it used something other than TCL.
There are two separate modules that support
* Peter Eisentraut <[EMAIL PROTECTED]> [001115 10:26]:
> Larry Rosenman writes:
>
> > Ok, so what I think(?) needs to happen is the FIXME: tag needs to be
> > handled. We need to code a version of src/backend/parser/scansup.c
> > that doesn't use palloc, and also strips the apostrophes from the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> distclean does not remove gram.c because we include gram.c in the
>> distribution. Perhaps there should be another target that gets rid
>> of *all* the derived files (maintainer-clean might be the GNU-approved
>> name for that, no
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
and make "/tmp" the default in guc.c.
>>
>> No, because this has to work on the client side too. The default path
>> *must* be determined at compile time, or clients and servers will be
>> unable to find each other.
> The only
On Wed, 15 Nov 2000, carl garland wrote:
> >perhaps why, even at 5 clients, the page views he shows never went
> >significantly above 10/sec?
>
> I think alot of it has to do with the web server/db setup not pg. They are
> using Apache/PHP and looking at their code every page has the additio
Andrew Snow <[EMAIL PROTECTED]> writes:
> Here's a simpler script which reproduces the bug:
Well, after looking at this some more, I'm not convinced it's a bug;
or at least, if it's a bug it's one that can't be fixed without a
fundamental redefinition of rules/views. Boiled down, here's what
you
On Wed, 15 Nov 2000, carl garland wrote:
# >perhaps why, even at 5 clients, the page views he shows never went
# >significantly above 10/sec?
#
# I think alot of it has to do with the web server/db setup not pg. They are
# using Apache/PHP and looking at their code every page has the additio
* Peter Eisentraut <[EMAIL PROTECTED]> [001115 08:15] wrote:
>
> I couldn't say I like these options, because they seem arbitrary, but
> given that it only affects the 0 univel users and the 3 bsdi users left
> (freebsd will be fixed), I wouldn't make a fuzz.
BSDi still has a market niche, and t
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> #define UNIXSOCK_PATH(sun,port,defpath) \
> snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
> (defpath), (port))
> and make "/tmp" the default in guc.c.
No, because this has to work on the client side too. The
mlw <[EMAIL PROTECTED]> writes:
> I'm not sure what "NewC" is, nor do I understand what problem it is
> attempting to fix.
I haven't gotten around to updating the main documentation yet (my bad)
but the design document about the fmgr rewrite is in current sources
as src/backend/utils/fmgr/README
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Should the parameter determine the directory or the full file name? I'd
> go for the former, but it's not a strong case.
> >>
> >> Directory was what I had in mind too, but I'm not sure what
'Marko Kreen' wrote:
>
> On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote:
> >
> > > > We need the 7.0 style for compatibility with other DB's. Postgres was
> > > > "the" pioneer in this area, but similar functionality is now available in
>other DB's.
> > >
> > > Could you
carl garland wrote:
>
> >perhaps why, even at 5 clients, the page views he shows never went
> >significantly above 10/sec?
>
> I think alot of it has to do with the web server/db setup not pg. They are
> using Apache/PHP and looking at their code every page has the additional
> overhead of maki
On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote:
>
> > > We need the 7.0 style for compatibility with other DB's. Postgres was
> > > "the" pioneer in this area, but similar functionality is now available in other
>DB's.
> >
> > Could you explain? PostgreSQL cant be comp
> > We need the 7.0 style for compatibility with other DB's. Postgres was
> > "the" pioneer in this area, but similar functionality is now available in other
>DB's.
>
> Could you explain? PostgreSQL cant be compatible in C level, why
> the SQL compatibility? (I mean the LANGUAGE 'C' specific
>perhaps why, even at 5 clients, the page views he shows never went
>significantly above 10/sec?
I think alot of it has to do with the web server/db setup not pg. They are
using Apache/PHP and looking at their code every page has the additional
overhead of making the db connection. Now if th
On Mon, Nov 13, 2000 at 09:58:30AM +0100, Zeugswetter Andreas SB wrote:
>
> > > because as said, it can be any other language besides C and also
> > > the 'AS file' is weird.
> >
> > This is interesting. It allows us to control the default behavour of
> > "C". I would vote to default to 7.0-sty
On Lun 13 Nov 2000 13:22, Robert D. Nelson wrote:
>
> Still...Regardless of what database they're running, either their
> abstraction layer is shit or their queries really need optimized. Is that
> perhaps why, even at 5 clients, the page views he shows never went
> significantly above 10/sec?
In
44 matches
Mail list logo
