What about just calling the new database postgres by default?
For true newbies, the first thing that happens if you try just
running psql with no arguments is that you discover there's no
database named postgres. For most first-time users, I suspect the
postgres user is the super-user and t
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
comments welcome (buildfarm exists to help people on this list - if you
want something speak up).
There are a number of buildfarm machines that don't seem to have *ever*
posted a successful run. In some cases this represent
Juan Pablo Espino wrote:
I want to register in an audit table the date and time of the
login/logout of a database user. I have been looking for some function
in the code but I didn't find something like that.
This is the kind of functionality I'd expect to go to the pg_system (or
however it i
Tom Lane wrote:
[ redirected back to hackers, since it seems this is far from a finished
discussion ]
Robert Treat <[EMAIL PROTECTED]> writes:
What is the purpose of this database? A generalized, shared resource for tool
makers and add-on packages to store information in PostgreSQL, or a wor
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Can you please look at
> http://www.openbsd.org/cgi-bin/man.cgi?query=malloc.conf&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
>
> and tell us which ones you would like turned on? Stefan suggests A F and
> G might be useful.
Not
Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
OpenBSD has some very useful features for configuration of malloc() -
and on this particular box it has:
G ``Guard''. Enable guard pages and chunk randomization. Each
page size or larger a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> comments welcome (buildfarm exists to help people on this list - if you
> want something speak up).
There are a number of buildfarm machines that don't seem to have *ever*
posted a successful run. In some cases this represents a genuine
portability is
[from 2pc post mortem thread on -patches]
Stefan Kaltenbrunner wrote:
Looks suspicious, doesn't it. How long since you last tested on that
machine?
*argl* - it's not 2PC ...
the machine had some issues a week ago or so - but it looks like the
problem occured first here:
http://www.pg
Josh Berkus writes:
> So this is obviously a major performance problem. It could be fixed by
> turning off checkpointing completely, but I don't think that's really
> feasable. Any clue on why clock-sweep should be so slammed by checkpoints?
Hm, notice that the processor utilization doesn't
In a moment of sheer brain fade I wrote:
> Log Message:
> ---
> Add a time-of-preparation column to the pg_prepared_xacts view, per an
> old suggestion by Oliver Jowett. Also, add a transaction column to the
> pg_locks view to show the xid of each transaction holding or awaiting
> locks; t
"Dave Page" writes:
> Keeping people out of template1 is my major concern, however it seemed like
> a good way to kill 2 birds with one stone and solve both problems at once.
FWIW here's a "me too" on keeping people out of template1 by default. I've
more than once accidentally created objects i
Hi, thanks for the response.
On 6/18/05, Rod Taylor <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-06-18 at 11:46 -0500, Juan Pablo Espino wrote:
> > Thanks for the quick response. Yes I want to retrieve the
> > login/logout info, but I want to insert this info in a table that I
> > use as an audit ta
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> dynahash.c thinks it should always copy 255 bytes of key, since that's
>> what it was told the key size was ... but in this case the supplied
>> search key has been allocated very close to the end of the process's
>> memory, and
Tom, folks,
I'm continuing to see a problem with checkpointing and clock-sweep.
Previously I thought that it was just the long checkpoint intervals on the
standard DBT2 test, but things get worse when you checkpoint more frequently:
60 minute checkpoint:
http://khack.osdl.org/stp/302458/result
Tom Lane wrote:
> dynahash.c thinks it should always copy 255 bytes of key, since that's
> what it was told the key size was ... but in this case the supplied
> search key has been allocated very close to the end of the process's
> memory, and there are not 255 bytes before the end of memory.
aaa
Oh-ho, I see it:
(gdb) bt
#0 0x4489fba4 in memcpy () from /usr/lib/libc.so.34.2
#1 0x00326f9c in hash_search (hashp=0xa6e030, keyPtr=0xa5ff90,
action=HASH_ENTER, foundPtr=0x0) at dynahash.c:653
#2 0x003434f0 in pg_tzset (name=0xa5ff90 "PST8PDT") at pgtz.c:1039
#3 0x
On Sat, 2005-06-18 at 11:46 -0500, Juan Pablo Espino wrote:
> Thanks for the quick response. Yes I want to retrieve the
> login/logout info, but I want to insert this info in a table that I
> use as an audit table. Regards
I suggest putting together a short script to scan the logs periodically
an
Tom Lane wrote:
> While cleaning out old mail about two-phase commit, I noticed this
> thought from Oliver:
>
> Oliver Jowett <[EMAIL PROTECTED]> writes:
> >>> Probably the next question is, do we want a database-side timeout on
> >>> how long prepared txns can stay alive before being summarily r
So, is there an effort to not require GNU make then ?
Neither using GNU make or gcc make to buld a binary make the resulting binary
bound by the GPL.
That is correct because all (well most) of the libraries used by GCC are
LGPL not GPL.
Sincerely,
Joshua D. Drake
-
Thanks for the quick response. Yes I want to retrieve the
login/logout info, but I want to insert this info in a table that I
use as an audit table. Regards
Juan P. Espino
On 6/18/05, Michael Fuhr <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 18, 2005 at 11:11:31AM -0500, Juan Pablo Espino wrote:
> >
On Sat, Jun 18, 2005 at 11:11:31AM -0500, Juan Pablo Espino wrote:
>
> I want to register in an audit table the date and time of the
> login/logout of a database user. I have been looking for some function
> in the code but I didn't find something like that.
Are you interested in logging to a tab
Hello all
I want to register in an audit table the date and time of the
login/logout of a database user. I have been looking for some function
in the code but I didn't find something like that.
Can you give me some ideas to implement it?. I'm ready to program if
it is necessary. Thanks in advanc
While cleaning out old mail about two-phase commit, I noticed this
thought from Oliver:
Oliver Jowett <[EMAIL PROTECTED]> writes:
>>> Probably the next question is, do we want a database-side timeout on
>>> how long prepared txns can stay alive before being summarily rolled back?
>>
>> That soun
Now that Heikki's two-phase-commit patch is in, we have a bit of a
problem in the pg_locks view: prepared transactions can hold locks,
but you can't tell which prepared transaction is holding which lock.
They all show with "pid 0". (This should probably come out as a NULL
instead of 0, but I didn'
Am Samstag, den 18.06.2005, 08:41 -0600 schrieb Michael Fuhr:
> I've moved this thread from pgsql-bugs to pgsql-hackers; here are
> the original messages:
>
> http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php
> http://archives.postgresql.org/pgsql-bugs/2005-06/msg00107.php
>
> As I m
Am Samstag, den 18.06.2005, 10:12 -0400 schrieb Tom Lane:
> [ redirected back to hackers, since it seems this is far from a finished
> discussion ]
>
...
> pg_addons or pg_tools or something like that seems like a fine name *for
> the purpose of a tools-only database* ... but that is only one of
I've moved this thread from pgsql-bugs to pgsql-hackers; here are
the original messages:
http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php
http://archives.postgresql.org/pgsql-bugs/2005-06/msg00107.php
As I mentioned in my followup to the bug report, a simple fix would
appear to be t
On Sat, Jun 18, 2005 at 08:43:01 +0100,
Peter Galbavy <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>
> >What is important is that it is possible, and useful, to build Postgres
> >in a completely non-GPL environment. If that were not so then I think
> >we'd have some license issues. But the fac
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Maybe one of the developers can comment on why your example calls
> the function only once and mine calls it multiple times per row,
> even though they look similar.
Look at the EXPLAIN results --- one case gets flattened into a single
plan node and the o
Robert Treat wrote:
> I think it is worth restating in stronger language, the potential overhead of
> raising notices or warning in such a large number of queries will be an
> upgrading show stopper for some people. (To the extent that for some, the
> release where this is a mandatory warning w
On Friday 17 June 2005 08:55, Bruce Momjian wrote:
> Michael Glaesemann wrote:
> > On Jun 17, 2005, at 4:34 PM, Greg Stark wrote:
> > > And for an app issuing
> > > hundreds or thousands of queries per minute (or even second) a
> > > warning could
> > > effectively be a showstopper. It could requi
[ redirected back to hackers, since it seems this is far from a finished
discussion ]
Robert Treat <[EMAIL PROTECTED]> writes:
> What is the purpose of this database? A generalized, shared resource for tool
> makers and add-on packages to store information in PostgreSQL, or a working
> database
"John Hansen" <[EMAIL PROTECTED]> writes:
>>> SELECT (a.b).* FROM (SELECT ('1:2:3:4:5'::text::my_type) AS
>>> b) AS a;
>>> Or am I missing something?
>>
>> Try it ;-)
> Yes, it worked for me,...
It depends on your test case, but in many situations the planner will
flatten that into the same r
Yes, it worked for me,...
But my point is the workaround shouldn't be nescessary
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Saturday, June 18, 2005 11:36 PM
> To: John Hansen
> Cc: Michael Fuhr; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Retu
"John Hansen" <[EMAIL PROTECTED]> writes:
> There is a workaround tho, so should be fixable:
> SELECT (a.b).* FROM (SELECT ('1:2:3:4:5'::text::my_type) AS b) AS a;
> Or am I missing something?
Try it ;-)
regards, tom lane
---(end of broadcast)-
On Sat, Jun 18, 2005 at 10:03:38PM +1000, John Hansen wrote:
>
> There is a workaround tho, so should be fixable:
>
> SELECT (a.b).* FROM (SELECT ('1:2:3:4:5'::text::my_type) AS b) AS a;
>
> Or am I missing something?
I don't know enough about PostgreSQL internals so I'll have to defer
to the d
Peter Galbavy <[EMAIL PROTECTED]> writes:
> So, is there an effort to not require GNU make then ?
No, that's not relevant. GNU make is a tool, not part of the end
result.
A more interesting question is Autoconf, which we also depend on
as a build tool, and which does copy parts of itself into th
On Fri, 17 Jun 2005, Andrew Dunstan wrote:
Thus, "sys_shared", "def_share", "user_commons" are all sorts of names
that suggest that this is some sort of default/shared area.
I like the first. The second and third seem less obvious to me.
'default_shared' should definitely get the point across,
Michael Fuhr [mailto:[EMAIL PROTECTED] Wrote:
> Sent: Saturday, June 18, 2005 9:56 PM
> To: John Hansen
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Returning Composite Types from C functions
>
> On Sat, Jun 18, 2005 at 09:18:34PM +1000, John Hansen wrote:
> >
> > SELECT ('1:2:3:4:
On Sat, Jun 18, 2005 at 09:18:34PM +1000, John Hansen wrote:
>
> SELECT ('1:2:3:4:5'::text::my_type).*;
>
> This results in the text_to_my_type(text) function being called no less
> than 5 times. Once for each element.
>
> Is this the desired behaviour, or a bug?
It's a known behavior with func
Hi all,
CREATE TYPE my_type AS (
a int,
b int,
c int,
d int,
e int
);
CREATE FUNCTION text_to_my_type(text)
RETURNS my_type
AS 'my_lib.so'
LANGUAGE 'C' IMMUTABLE STRICT;
CREATE CAST (text AS my_type) WITH FUNCTION text_to_my_type (text);
SELECT ('1:2:3:4
Magnus Hagander wrote:
I was gradually drifting toward this idea. Do we really need
the blessing of the postgresql core to make this happen? ISTM
we don't.
I think not, but I would perhaps make things easier ;-)
But what if we all just agreed that we would use a common
database called "
> I was gradually drifting toward this idea. Do we really need
> the blessing of the postgresql core to make this happen? ISTM
> we don't.
I think not, but I would perhaps make things easier ;-)
> But what if we all just agreed that we would use a common
> database called "pg_addons", and t
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Sat 6/18/2005 6:36 AM
To: Dave Page
Cc: Andreas Pflug; Christopher Kings-Lynne; Magnus Hagander; Josh Berkus;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Utility database (Was: RE: Autovacuum in the backend)
>
Tom Lane wrote:
What is important is that it is possible, and useful, to build Postgres
in a completely non-GPL environment. If that were not so then I think
we'd have some license issues. But the fact that building PG in a
GPL-ized environment creates a GPL-ized binary is not a problem from m
45 matches
Mail list logo
