Hi,
I've project where I need to log information about database user, based
on hardware security tokens. These tokens are supported by OpenSSL.
So, I need two modification in the PostgreSQL core
1. Access to SSL certificate information on SQL level.
It seems that this can be done using INTERNA
Christopher Kings-Lynne wrote:
If you want to get users to swtich to your software from your
competitors, you have to eliminate barriers, and a big one for any
database is getting locked into a specific one. People aren't going
to take the time to try switching to postgresql if they can't easi
Michael Dean <[EMAIL PROTECTED]> writes:
> Greetings Guys
>
> As a newbie person moving away from my technical background to marketing, I
> think a refreshed course for pg is needed! So far I have read all 5000 or so
> of this month's emails and want to make a few remarks IMHO:
>
> 1. We shoul
Chris Browne wrote:
[EMAIL PROTECTED] ("Marc G. Fournier") writes:
To give someone a running chance at migrating it to PostgreSQL, a
'MySQL compatibility module' would allow them to just plug the
existing DB in, and then work at improving sections of the code over
time ...
Hell, if done well, t
On Thu, May 18, 2006 at 04:55:17PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Actually, I guess the amount of memory used for zlib's lookback buffer
> > (or whatever they call it) could be pretty substantial, and I'm not sure
> > if there would be a way to combine that
Those of you with long memories may recall a discussion back in January
about reference-counting TupleDescs retrieved by lookup_rowtype_tupdesc().
I didn't like the patch Neil Conway developed for this, so I'm on the
hook to find a better answer before 8.2 comes out. I haven't forgotten
... but I
Tom Lane wrote:
> Mark Dilger <[EMAIL PROTECTED]> writes:
>
>>The function
>> static int32 text_position(text *t1, text *t2, int matchnum)
>>defined in src/backend/utils/adt/varlena.c uses repeated calls to
>>strncmp (or pg_wchar_strncmp) to find the location of the pattern in
>>the text. The wo
Christopher Kings-Lynne wrote:
And MySQL is much closer to being a competitor now than they were in
4.1. And feature-wise they'll probably equal PostgreSQL in the next
release. Will the features be anywhere near as robust or well thought
out? No. But in a heck of a lot of companies that doesn't m
If you want to get users to swtich to your software from your competitors, you
have to eliminate barriers, and a big one for any database is getting locked
into a specific one. People aren't going to take the time to try switching
to postgresql if they can't easily make it back to thier former
We also need better support for non C locales in tsearch. As I was porting
mysql's sakila sample database I was reminded just how painful it is when you
initdb in a non-supported locale (which is probably the default on the
majority of distros out there)
In 8.2 tsearch2 supports utf8...
--
And MySQL is much closer to being a competitor now than they were in
4.1. And feature-wise they'll probably equal PostgreSQL in the next
release. Will the features be anywhere near as robust or well thought
out? No. But in a heck of a lot of companies that doesn't matter.
Don't forget that they
Mark Dilger <[EMAIL PROTECTED]> writes:
> The function
> static int32 text_position(text *t1, text *t2, int matchnum)
> defined in src/backend/utils/adt/varlena.c uses repeated calls to
> strncmp (or pg_wchar_strncmp) to find the location of the pattern in
> the text. The worst case runtime for
Douglas McNaught wrote:
> Mark Dilger <[EMAIL PROTECTED]> writes:
>
>
>>Tom Lane wrote:
>>
>>>No it isn't. The plpgsql scanner treats := and = as *the same token*.
>>>They can be interchanged freely. This has nothing to do with the case
>>>of modifying a loop variable in particular.
>>
>>I disa
Mark Dilger <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No it isn't. The plpgsql scanner treats := and = as *the same token*.
>> They can be interchanged freely. This has nothing to do with the case
>> of modifying a loop variable in particular.
>
> I disagree. If the scanner treated them
Veil http://pgfoundry.org/projects/veil is currently not a very good
Postgres citizen. It steals what little shared memory it needs from
postgres' shared memory using ShmemAlloc().
For Postgres 8.2 I would like Veil to be a better citizen and use only
what shared memory has been reserved for post
Mark Dilger schrob:
> Tom Lane wrote:
>> No it isn't. The plpgsql scanner treats := and = as *the same token*.
>> They can be interchanged freely. This has nothing to do with the case
>> of modifying a loop variable in particular.
>
> I disagree. If the scanner treated them the same, then
>
>
On Thursday 18 May 2006 12:38, Josh Berkus wrote:
> Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
> make *migration* easier for those who wake up and smell the BS, but
> migration can (and probably should) be one-way.
>
If you want to get users to swtich to your softwa
Tom Lane wrote:
> Josh Berkus writes:
>
>>>True, but there were clear benefits from doing so. Disallowing "="
>>>assignment in plpgsql wouldn't buy anything, just break programs.
>
>
>>But it's already disallowed in most places.
>
>
> No it isn't. The plpgsql scanner treats := and = as *the
The function
static int32 text_position(text *t1, text *t2, int matchnum)
defined in src/backend/utils/adt/varlena.c uses repeated calls to strncmp (or
pg_wchar_strncmp) to find the location of the pattern in the text. The worst
case runtime for such an approach is O(n*m) where n and m are the
On Thursday 18 May 2006 16:17, Philippe Schmid wrote:
> As a users of both Postgres and MySQL, I would also say, better add
> missing features to Postgres than chasing some specialties that are
> going to vanish anyway in MySQL.
> I miss :
> - a core full-text indexing engine. Tsearch2 is nice, but
On 5/18/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
>
> On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
>
> >What is the best way to go about creating a "plug and play,"
> >PostgreSQL
> >replacement for MySQL? I think the biggest probl
Tom Lane wrote:
> Bruce Momjian writes:
> > As far as testing, I think we are going to have to wait for someone who
> > cares about sparcv8 because none of our current Sparc guys are testing
> > on that.
>
> Yeah, I don't see anyone at all in the buildfarm testing Solaris-on-Sparc
> with the Sun
Bruce Momjian writes:
> As far as testing, I think we are going to have to wait for someone who
> cares about sparcv8 because none of our current Sparc guys are testing
> on that.
Yeah, I don't see anyone at all in the buildfarm testing Solaris-on-Sparc
with the Sun tools. So all these patches a
Lukas Smith wrote:
.. but spouting outdated FUD is really making you two look foolish.
Wow. On a scale from 1 to 10 measuring seriousness, I'd put my posting on -4. I'd advice you
to take a step back and get some distance if you consider it "outdated FUD".
Regards,
Thomas Hallgren
-
If we had infinite resources this might make sense. We don't, so it
doesn't. There is a real cost to producing a compatibility layer,
and the cost will be those spiffy new features.
Let's get recursive queries, MERGE, and a couple more things and
they will still be chasing our heels.
As
[EMAIL PROTECTED] ("Marc G. Fournier") writes:
> To give someone a running chance at migrating it to PostgreSQL, a
> 'MySQL compatibility module' would allow them to just plug the
> existing DB in, and then work at improving sections of the code over
> time ...
>
> Hell, if done well, the module sh
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Actually, I guess the amount of memory used for zlib's lookback buffer
> (or whatever they call it) could be pretty substantial, and I'm not sure
> if there would be a way to combine that across all tapes.
But there's only one active write tape at a tim
On Thu, May 18, 2006 at 01:32:51PM -0700, Michael Dean wrote:
> Greetings Guys
>
> As a newbie person moving away from my technical background to
> marketing, I think a refreshed course for pg is needed! So far I have
> read all 5000 or so of this month's emails and want to make a few
> remark
David Fetter wrote:
On Thu, May 18, 2006 at 09:58:21PM +0200, Lukas Smith wrote:
In what way is this outdated? Please provide a specific example.
see below ..
You have to understand that MySQL evolves just like PostgreSQL does.
If it were true, I would have to understand it, but the way
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Mark Woodward wrote:
>> Again, there is so much code for MySQL, a MySQL emulation layer, MEL for
>> short, could allow plug and play compatibility for open source, and closed
>> source, applications that otherwise would force a PostgreSQL user to hold
>>
Greetings Guys
As a newbie person moving away from my technical background to
marketing, I think a refreshed course for pg is needed! So far I have
read all 5000 or so of this month's emails and want to make a few
remarks IMHO:
1. We should treat all marketing efforts by hackers/programmer
On Thu, May 18, 2006 at 01:25:34PM -0700, Joshua D. Drake wrote:
>
> >I do agree that its probably not worth allocating core resources to
> >this, but spouting outdated FUD is really making you two look foolish.
>
> And which FUD would this be?
That Feb. 31st is a valid date in MySQL. You can n
You've made some sweeping allegations here and no specifics.
sweeping allegations?
http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html
SET [GLOBAL|SESSION] sql_mode='ALLOW_INVALID_DATES'
Which can be turned off or on by any mysql user. Not to mention the fact
that it is even an opt
I do agree that its probably not worth allocating core resources to
this, but spouting outdated FUD is really making you two look foolish.
And which FUD would this be?
You have to understand that MySQL evolves just like PostgreSQL does. So
you better focus on advertising where PostgreSQL s
On Thu, May 18, 2006 at 09:58:21PM +0200, Lukas Smith wrote:
> Joshua D. Drake wrote:
> >
> >No we can't, because then we are taking an invalid date, which is
> >potentially valid data (to the user) and modifying it to a valid
> >date that is indeed invalid data.
> >
> >One of the reasons that mysq
On Thu, May 18, 2006 at 08:32:10PM +0200, Martijn van Oosterhout wrote:
> On Thu, May 18, 2006 at 11:22:46AM -0500, Jim C. Nasby wrote:
> > AFAIK logtape currently reads in much less than 256k blocks. Of course
> > if you get lucky you'll read from one tape for some time before
> > switching to ano
Martijn van Oosterhout writes:
> Every cast costs space and lookup time.
Actually, we could probably have a net time savings here if the text
cast cases were hard-wired into parse_coerce.c. The reason is that
about 10% of the default entries in pg_cast are "retail" implementations
of text-to-or-
Joshua D. Drake wrote:
Thomas Hallgren wrote:
>
Couldn't we just install something that replaced invalid dates with a
randomly generated but otherwise correct dates? That way they would
become completely invisible. No one could even tell that the date was
invalid to start with.
No we can't,
Joshua D. Drake wrote:
Thomas Hallgren wrote:
John DeSoi wrote:
Right, you'll definitely need to hack the C source code to force
PostgreSQL to accept invalid dates ;)
http://sql-info.de/mysql/gotchas.html#1_14
Couldn't we just install something that replaced invalid dates with a
randomly
Thomas Hallgren wrote:
John DeSoi wrote:
Right, you'll definitely need to hack the C source code to force
PostgreSQL to accept invalid dates ;)
http://sql-info.de/mysql/gotchas.html#1_14
Couldn't we just install something that replaced invalid dates with a
randomly generated but otherwise
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote:
> > Jim C. Nasby wrote:
> >> On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
> >>> On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
> >>>
> What is the best way to go about creating a "plug and play,"
> PostgreSQL
Mark Woodward wrote:
Jim C. Nasby wrote:
Maybe a compatability layer isn't worth doing, but I certainly think
it's very much worthwhile for the community to do everything possible to
encourage migration from MySQL. We should be able to lay claim to most
advanced and most popular OSS databas
While I do agree with the ideal, the reality may not be good enough. Even
I, a PostgreSQL user for a decade, have to use MySQL right now because
that is what the client uses.
Then you aren't choosing your clients wisely. :)
I am not trying to be rude, but if you don't want to use MySQL, don't.
John DeSoi wrote:
Right, you'll definitely need to hack the C source code to force
PostgreSQL to accept invalid dates ;)
http://sql-info.de/mysql/gotchas.html#1_14
Couldn't we just install something that replaced invalid dates with a randomly generated but
otherwise correct dates? That way
> Jim C. Nasby wrote:
>> Maybe a compatability layer isn't worth doing, but I certainly think
>> it's very much worthwhile for the community to do everything possible to
>> encourage migration from MySQL. We should be able to lay claim to most
>> advanced and most popular OSS database.
>>
>
> We'll
> Jim C. Nasby wrote:
>> On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
>>> On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
>>>
What is the best way to go about creating a "plug and play,"
PostgreSQL
replacement for MySQL? I think the biggest problem getting PostgreSQL
Jim C. Nasby wrote:
Maybe a compatability layer isn't worth doing, but I certainly think
it's very much worthwhile for the community to do everything possible to
encourage migration from MySQL. We should be able to lay claim to most
advanced and most popular OSS database.
We'll do that by co
On Thu, May 18, 2006 at 01:22:55PM -0500, Jim C. Nasby wrote:
> On Thu, May 18, 2006 at 11:09:28AM -0700, David Fetter wrote:
> > postgres=# CREATE TABLE dual();
> > CREATE TABLE
>
> You forgot to populate it.
Oh, right. :)
postgres=# CREATE TABLE dual AS SELECT 1;
SELECT
Cheers,
D
--
David Fe
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> And to be frank, I don't think we should waste our time on MySQL. It
> isn't a competitor, it just thinks it is. We should focus on our real
> competition which is DB2, MSSQL, and Oracle.
One thing which would be kind of nice would be to have a mapp
On Thu, May 18, 2006 at 11:22:46AM -0500, Jim C. Nasby wrote:
> AFAIK logtape currently reads in much less than 256k blocks. Of course
> if you get lucky you'll read from one tape for some time before
> switching to another, which should have a sort-of similar effect if the
> drives aren't very bus
And MySQL is much closer to being a competitor now than they were in
4.1. And feature-wise they'll probably equal PostgreSQL in the next
release. Will the features be anywhere near as robust or well thought
out? No. But in a heck of a lot of companies that doesn't matter.
Your kidding right? H
On Thu, May 18, 2006 at 02:56:12PM -0300, Marc G. Fournier wrote:
> the point isn't whether or not MySQL is a competitor ... the point is that
> there are *alot* of MySQL based applications out there that are a major
> PITA to convert (or get converted) all at once ...
More importantly, there's
On Thu, May 18, 2006 at 11:09:28AM -0700, David Fetter wrote:
> postgres=# CREATE TABLE dual();
> CREATE TABLE
You forgot to populate it.
In reality I think you'd want dual to be a view on SELECT 1; or whatever
the appropriate value is.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PRO
On Thu, May 18, 2006 at 02:56:12PM -0300, Marc G. Fournier wrote:
> On Thu, 18 May 2006, Joshua D. Drake wrote:
>
> >I understand the idea but I personally don't like it. I am not really
> >interested in cross-database compatible code. 9 times out of 10 it is
> >hacky, slow and lacks a solid sup
On Thu, May 18, 2006 at 10:35:48AM -0700, Joshua D. Drake wrote:
> I understand the idea but I personally don't like it. I am not
> really interested in cross-database compatible code. 9 times out of
> 10 it is hacky, slow and lacks a solid supportable model because you
> are always taking into ac
Marc,
> To give someone a running chance at migrating it to PostgreSQL, a 'MySQL
> compatibility module' would allow them to just plug the existing DB in,
> and then work at improving sections of the code over time ...
Have you even looked at KL's mysqlcompat?
--
--Josh
Josh Berkus
PostgreSQL
On Thu, 18 May 2006, Joshua D. Drake wrote:
I understand the idea but I personally don't like it. I am not really
interested in cross-database compatible code. 9 times out of 10 it is
hacky, slow and lacks a solid supportable model because you are always
taking into account *the other* databas
Tom Lane wrote:
> Bruce Momjian writes:
> > Uh, TODO already has:
>
> > o %Add a GUC variable to control the tablespace for temporary
> > objects
> > and sort files
>
> > It could start with a random tablespace from a supplied list and
> > cycle through the
Bruce Momjian writes:
> Uh, TODO already has:
> o %Add a GUC variable to control the tablespace for temporary objects
> and sort files
> It could start with a random tablespace from a supplied list and
> cycle through the list.
> Do we need to add to this?
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I would have thought that casting into the
> string types was something that could be hardwired since the backing
> functions are mandatory.
This has been proposed before, and seems reasonable to me (as long as
the casts are explicit-only), and I thi
'k, so you want "pure PostgreSQL" ... but, shouldn't it be possible,
with all of our CREATE FUNCTION / RULES / etc features to create a
'translation layer' that could be loaded, like anything else in contrib?
Sure but that isn't what was suggested :)
Hell, even if it gave an initial "in" f
On Thu, 18 May 2006, Joshua D. Drake wrote:
Jim C. Nasby wrote:
On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
What is the best way to go about creating a "plug and play," PostgreSQL
replacement for MySQL? I think the biggest pr
Josh Berkus wrote:
> Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
> make *migration* easier for those who wake up and smell the BS, but migration
> can (and probably should) be one-way.
Yeah. Let's write a Transact-SQL PL handler.
--
Alvaro Herrera
Jim C. Nasby wrote:
On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
What is the best way to go about creating a "plug and play,"
PostgreSQL
replacement for MySQL? I think the biggest problem getting PostgreSQL
accepted is that so
On May 18, 2006, at 12:24 PM, Jim C. Nasby wrote:
Even better would be coming up with a compatability mode, a la what
EnterpriseDB has done for Oracle.
Right, you'll definitely need to hack the C source code to force
PostgreSQL to accept invalid dates ;)
http://sql-info.de/mysql/gotchas.h
All,
> > >What is the best way to go about creating a "plug and play,"
> > >PostgreSQL
> > >replacement for MySQL? I think the biggest problem getting PostgreSQL
> > >accepted is that so much code is available for MySQL.
> >
> > http://pgfoundry.org/projects/mysqlcompat/
>
> Even better would be c
On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
>
> On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
>
> >What is the best way to go about creating a "plug and play,"
> >PostgreSQL
> >replacement for MySQL? I think the biggest problem getting PostgreSQL
> >accepted is that so much
On Thu, May 18, 2006 at 10:57:16AM +0200, Zeugswetter Andreas DCP SD wrote:
>
> > 1) Use n sort areas for n tapes making everything purely sequential
> access.
>
> Some time ago testing I did has shown, that iff the IO block size is
> large enough
> (256k) it does not really matter that much if t
On Thu, May 18, 2006 at 11:34:51AM +0100, Simon Riggs wrote:
> On Tue, 2006-05-16 at 15:42 -0500, Jim C. Nasby wrote:
> > On Tue, May 16, 2006 at 12:31:07PM -0500, Jim C. Nasby wrote:
> > > In any case, my curiousity is aroused, so I'm currently benchmarking
> > > pgbench on both a compressed and u
Greg Stark wrote:
> Bruce Momjian writes:
>
> > Zeugswetter Andreas DCP SD wrote:
> >
> > > I thought the suggested procedure (see migration doc) was to use the
> > > new pg_dump to dump the older db version, so why backpatch ?
> >
> > Uh, you can suggest it, but I would guess < 50% do it, and
Uh, TODO already has:
o %Add a GUC variable to control the tablespace for temporary objects
and sort files
It could start with a random tablespace from a supplied list and
cycle through the list.
Do we need to add to this?
-
Martijn van Oosterhout wrote:
On Thu, May 18, 2006 at 05:41:14PM +0200, Thomas Hallgren wrote:
Just out of curiosity (and most likely, ignorance). Why can't I cast an
array of strings into a string? I.e.
thhal=# select ('{"a","b"}'::varchar[])::varchar;
ERROR: cannot cast type character
On Thursday 18 May 2006 10:39, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Thursday 18 May 2006 05:47, Simon Riggs wrote:
> >> I've just noticed that Google's Summer of Code projects are due to
> >> finish on August 21, 2006 at 08:00 Pacific Daylight Time.
> >>
> >> Which is t
On Thu, May 18, 2006 at 05:41:14PM +0200, Thomas Hallgren wrote:
> Just out of curiosity (and most likely, ignorance). Why can't I cast an
> array of strings into a string? I.e.
>
> thhal=# select ('{"a","b"}'::varchar[])::varchar;
> ERROR: cannot cast type character varying[] to character var
Just out of curiosity (and most likely, ignorance). Why can't I cast an
array of strings into a string? I.e.
thhal=# select ('{"a","b"}'::varchar[])::varchar;
ERROR: cannot cast type character varying[] to character varying
or a cstring into a varchar, i.e.
thhal=# select array_out('{"a","
On 5/18/06, Josh Berkus wrote:
The ones which are no-brainers, like ECPG cleanup,
can easily stray past Aug. 1st because they are
mostly bug-fixes. Hmmm ... actually, that may be the
only one like that.
Yeah, the rest appear to be either contrib modules, core changes, or
related to other Post
All,
> I'm not particularly eager to do this, especially not when we don't
> even have any committed SOC projects. There's always the next release.
Also, our previous project (Meredith's "Query by Example") isn't yet ready for
inclusion in the core code (nor have we had the discussion on whethe
Robert Treat <[EMAIL PROTECTED]> writes:
> On Thursday 18 May 2006 05:47, Simon Riggs wrote:
>> I've just noticed that Google's Summer of Code projects are due to
>> finish on August 21, 2006 at 08:00 Pacific Daylight Time.
>>
>> Which is three weeks past the beta freeze date of Aug 1st.
>>
>> An
Hannu Krosing wrote:
Can you do something like "A > (B := C)" or "IF (A:=B) THEN ..." in
ADA ?
Er, that's "Ada"; "ADA" is the American Dental Association among other
things.
And no you certainly can't do it. Assignment is a statement, not an
expression, and this family of languages dis
On Thursday 18 May 2006 05:47, Simon Riggs wrote:
> I've just noticed that Google's Summer of Code projects are due to
> finish on August 21, 2006 at 08:00 Pacific Daylight Time.
>
> Which is three weeks past the beta freeze date of Aug 1st.
>
> Anyone see any problems there?
None of these project
On Tue, 2006-05-16 at 15:42 -0500, Jim C. Nasby wrote:
> On Tue, May 16, 2006 at 12:31:07PM -0500, Jim C. Nasby wrote:
> > In any case, my curiousity is aroused, so I'm currently benchmarking
> > pgbench on both a compressed and uncompressed $PGDATA/base. I'll also do
> > some benchmarks with pg_tm
I've just noticed that Google's Summer of Code projects are due to
finish on August 21, 2006 at 08:00 Pacific Daylight Time.
Which is three weeks past the beta freeze date of Aug 1st.
Anyone see any problems there?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
--
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 18 May 2006 10:30
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Clarification required
>
> The server log file means the files that are in pg_xlog. or
> some more/some other
Ühel kenal päeval, N, 2006-05-18 kell 09:28, kirjutas Albe Laurenz:
> Josh Berkus wrote:
> >> If you only care about Oracle to PostgreSQL (and who wouldn't?), then
> >> it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
> >
> > I agree with David here. We care about the abilit
The server log file means the files that are in pg_xlog. or some
more/some other files?
The log files in pg_xlog dir are not human readable. How is it useful on
the client side?
Dave Page wrote:
could not understand the following TODO item.
Can anyone explain this.
Monitoring:
=
> 1) Use n sort areas for n tapes making everything purely sequential
access.
Some time ago testing I did has shown, that iff the IO block size is
large enough
(256k) it does not really matter that much if the blocks are at random
locations.
I think that is still true for current model disks.
So
* Jonah H. Harris:
> On 5/17/06, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>> Does ADA have both assignment and comparison as operators, or is
>> assignment a statement ?
>
> Yes. Assignment is := and comparison is =
And its name is spelled "Ada", not "ADA", even though the language
itself is cas
* Jim C. Nasby:
> The problem is that it seems like there's never enough ability to clue
> the OS in on what the application is trying to accomplish. For a long
> time we didn't have a background writer, because the OS should be able
> to flush things out on it's own before checkpoint. Now there's
* Mark Woodward:
> "On the other hand, you shouldn't use mysql_use_result() if you are doing
> a lot of processing for each row on the client side, or if the output is
> sent to a screen on which the user may type a ^S (stop scroll). This ties
> up the server and prevent other threads from updatin
1.451 ms = 1.451 milliseconds
1451.0 ms = 1.451 seconds ...
so 32.918 ms for a commit seems perhaps reasonable ?
Greg Williamson
DBA
GlobeXplorer LLC
-Original Message-
From: [EMAIL PROTECTED] on behalf of Zeugswetter Andreas DCP SD
Sent: Thu 5/11/2006 12:55 AM
To: Jim C. Nasby
On Wed, May 17, 2006 at 09:08:21PM -0700, Josh Berkus wrote:
> We could really use a couple more Mentors for Google Summer of Code Projects.
>
> Particularly, we've had some good proposals in these areas:
>
> ECPG Cleanup
I'd be interested in being a mentor for this proposal.
> If you are int
Josh Berkus wrote:
>> If you only care about Oracle to PostgreSQL (and who wouldn't?), then
>> it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
>
> I agree with David here. We care about the ability to migrate PL/SQL -->
> PL/pgSQL. We do *not* care about the ability to m
92 matches
Mail list logo
