-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Feb 19, 2008 at 04:38:16PM +0100, Csaba Nagy wrote:
Are you suggesting we keep appending? So if I set the same parameter 100
times, it would show up on 100 rows?
What about not touching the config file at all, but write to a separate
On Tue, Feb 19, 2008 at 02:59:44PM -0800, Josh Berkus wrote:
Magnus,
That's basically include but with a different name, no?
Yes. FWIW, I seem to be lagged about 3 hours on -hackers.
Why do you need to split it in two columns, and what would go in what
column?
Current data:
On Tue, Feb 19, 2008 at 11:27:47PM -0500, Robert Treat wrote:
On Tuesday 19 February 2008 20:08, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
On Tuesday 19 February 2008 15:05, Bruce Momjian wrote:
One idea would be to remove duplicate postgresql.conf appended entries
on
On Feb 19, 2008 10:31 PM, Josh Berkus [EMAIL PROTECTED] wrote:
Magnus, All,
This is something I've been thinking about too, just because my efforts to
write auto-config scripts have gotten bogged down in the need to parse and
write .conf files in a paltform-agnostic way and preserve comments.
Тюрин Дмитрий wrote:
Hi list,
Hi Dmitry, nice to have you back again.
I see the following business opportunity for Postgres:
I) Simple man can't program middleware to connect XML-client and
Postgres.
Aha! still trying to push an XML command system and http server into the
backend.
II)
Hello
Anybody got any ideas/experiences/links for 'longest prefix match'
solution in PostgreSQL ?
Basically,put some telephone prefices in some kind of trie,and be able
to perform fast lookups ?
Sincerely
Dragan Zubac
---(end of broadcast)---
Hi,
Le mercredi 20 février 2008, Dragan Zubac a écrit :
Anybody got any ideas/experiences/links for 'longest prefix match'
solution in PostgreSQL ?
Basically,put some telephone prefices in some kind of trie,and be able
to perform fast lookups ?
Glad you ask!
I've been taught there are
Hello -hackers,
In the process of converting a multi-Tb datadabe from 8.2 to 8.3, Postgres
8.3 died at the failed assertion:
TRAP: FailedAssertion(!(((toast_pointer).va_extsize (toast_pointer).va_rawsize - ((int32)
sizeof(int32, File: tuptoaster.c, Line: 1134)
LOG: server process (PID
Le mardi 19 février 2008, Gregory Stark a écrit :
Magnus Hagander [EMAIL PROTECTED] writes:
Yeah, that may actually be a very good way to implement it. I don't like
the idea of continously appending to an existing file, but if we did have
a separate file with a tightly controlled format
Sergey E. Koposov [EMAIL PROTECTED] writes:
In the process of converting a multi-Tb datadabe from 8.2 to 8.3, Postgres 8.3
died at the failed assertion:
TRAP: FailedAssertion(!(((toast_pointer).va_extsize
(toast_pointer).va_rawsize - ((int32) sizeof(int32, File:
tuptoaster.c, Line:
Does anyone have ideas what could be the reason for the bug ?
Compression of varlena's header, introduced in 8.3.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
Sergey E. Koposov [EMAIL PROTECTED] writes:
Hello -hackers,
In the process of converting a multi-Tb datadabe from 8.2 to 8.3, Postgres 8.3
died at the failed assertion:
TRAP: FailedAssertion(!(((toast_pointer).va_extsize
(toast_pointer).va_rawsize - ((int32) sizeof(int32, File:
On Wed, Feb 20, 2008 at 11:20:29AM +0100, Dimitri Fontaine wrote:
Le mardi 19 février 2008, Gregory Stark a écrit :
Magnus Hagander [EMAIL PROTECTED] writes:
Yeah, that may actually be a very good way to implement it. I don't like
the idea of continously appending to an existing file, but
Gregory Stark [EMAIL PROTECTED] writes:
CREATE TYPE image (
INPUT = image_in,
OUTPUT = image_out,
INTERNALLENGTH = -1,
STORAGE = external
);
ALTER column SET STORAGE EXTERNAL
Hum. I just noticed that you had set STORAGE = external in your type
On Wed, 20 Feb 2008, Gregory Stark wrote:
You aren't doing anything funny in the image_in function to generate
compressed varlenas manually are you?
No, I don't. The only thing I do there is
unsigned char *in = PG_GETARG_CSTRING(0);//AABBCCDDEE1122;//
and return the pointer to the
In trying to generate random incompressible data I ran into this. I thought we
said char()/ascii() would be allowed to generate either unicode code points if
your encoding was unicode or 8-bit ascii if it's SQL_ASCII.
Is there any way to generate random 8-bit characters in SQL_ASCII encoding
Also, I thought we said this would be an error:
postgres=# select length(char(0));
length
0
(1 row)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL
training!
Richard,
I see the following business opportunity for Postgres:
I) Simple man can't program middleware to connect XML-client and
Postgres.
RH Aha! still trying to push an XML command system and http server into the
RH backend.
Yes.
II) Request into several databases does not exist.
RH what
Dawid Kuroczko escribió:
1) changes that cannot be done to live server:
SET PERMANENT shared_buffers = '1GB';
Now, this is a setting that cannot be changed live, but it should be
changeable. And we need a command to query what's permanent
and what's current.
IMO restart-only settings
On Wed, 20 Feb 2008, Gregory Stark wrote:
Could you send
select *
from pg_attribute
where attrelid = 'sdssdr5.frame'::regclass
and attname = 'img';
cas=# select *
from pg_attribute
where attrelid = 'sdssdr5.frame'::regclass
and attname = 'img';
attrelid | attname | atttypid |
Sergey E. Koposov [EMAIL PROTECTED] writes:
typedef struct
{
int4 length;
unsigned char data[1];
} image;
image *im = (image *) palloc(VARHDRSZ + out_len);
memset(im, 0, VARHDRSZ + out_len);
im-length = out_len + VARHDRSZ;
Ah, that's not going to
Gregory Stark wrote:
Also, I thought we said this would be an error:
postgres=# select length(char(0));
length
0
(1 row)
IIRC, we said chr(0) would give you an error, and it does. I don't
recall any discussion of char(0), but no doubt a few brain cells have
died
On Wed, Feb 20, 2008 at 09:36:43AM -0300, Alvaro Herrera wrote:
Dawid Kuroczko escribió:
1) changes that cannot be done to live server:
SET PERMANENT shared_buffers = '1GB';
Now, this is a setting that cannot be changed live, but it should be
changeable. And we need a command to
On Wed, 20 Feb 2008, Gregory Stark wrote:
Ah, that's not going to work in 8.3 any longer. You have to change this to:
SET_VARSIZE(im, out_len+VARHDRSZ)
Phew. You had me scared there.
Thank you. Sorry for scaring :)
I hope that everything will work fine now.
Regards,
Sergey
On Wed, Feb 20, 2008 at 10:20:55AM -0300, Alvaro Herrera wrote:
Magnus Hagander escribió:
On Wed, Feb 20, 2008 at 09:36:43AM -0300, Alvaro Herrera wrote:
IMO restart-only settings should not be changeable via the new SQL
command. It's just too messy to deal with that.
I
Andrew Dunstan [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Also, I thought we said this would be an error:
postgres=# select length(char(0));
length
0
(1 row)
IIRC, we said chr(0) would give you an error, and it does. I don't recall any
discussion of char(0), but
Magnus Hagander escribió:
On Wed, Feb 20, 2008 at 09:36:43AM -0300, Alvaro Herrera wrote:
IMO restart-only settings should not be changeable via the new SQL
command. It's just too messy to deal with that.
I respectfully disagree. It should be settable. You need a restart, sure,
and the
On Tue, Feb 19, 2008 at 08:37:51PM -0500, Andrew Dunstan wrote:
The way I intended to do it would indeed allow it to be undone simply by
executing 'drop language plpgsql' in template1.
Why isn't it enough that administrators can do CREATE LANGUAGE plpgsql in
template1?
I think this is
Le mercredi 20 février 2008, Magnus Hagander a écrit :
What about having a postgresql.conf.d directory containing a file per
setting, maybe with a subdir per section. If I take Josh Berkus example,
we'd have
snip
IMHO, if we do that it really sucks for those who use manual configuration
Dimitri Fontaine wrote:
Le mercredi 20 février 2008, Magnus Hagander a écrit :
What about having a postgresql.conf.d directory containing a file per
setting, maybe with a subdir per section. If I take Josh Berkus example,
we'd have
snip
IMHO, if we do that it really sucks for those
Le mercredi 20 février 2008, Andrew Dunstan a écrit :
No. Seriously. We need to have reasonable manual editability preserved
for all cases. The tree of files proposal just strikes me as a basic
non-starter, and, frankly, a piece of bad design. If you need structure,
then using the file system
On Tue, Feb 19, 2008 at 09:32:30PM -0500, Andrew Dunstan wrote:
As discussed a little while back, I would like to add a generic
trigger function which will force an update to skip if the new and
old tuples are identical.
This one has lots of use cases. Did the earlier discussion settle on
David Fetter wrote:
On Tue, Feb 19, 2008 at 09:32:30PM -0500, Andrew Dunstan wrote:
As discussed a little while back, I would like to add a generic
trigger function which will force an update to skip if the new and
old tuples are identical.
This one has lots of use cases. Did the
Tom Lane wrote:
Naz Gassiep [EMAIL PROTECTED] writes:
I think that it would be great if the pg_timezone_names and
pg_timezone_abbrevs included a boolean field indicating if that item is
in the Olsen DB
Huh? They're all in the Olsen DB
Not true, the zone.tab file has 398 zones
Alvaro Herrera wrote:
Naz Gassiep wrote:
It may also be beneficial to add the ISO 3166 column into that view, the
data is in zone.tab and I can't see a reason to not include it.
We also have the country name in iso3166.tab and the geo coordinates.
And there is also a comment field.
Andrew Dunstan [EMAIL PROTECTED] writes:
All this discussion seems to me to be going off into the clouds, where
every objection is met with some still more elaborate scheme. I think we
need to look at simple, incremental, and if possible backwards
compatible changes.
+1. Let me propose
On Feb 19, 2008 8:31 AM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
In my workload, ANALYZE takes long time (1min at statistics_target = 10,
and 5min at 100), but the updated table needs to be vacuumed every 30
Magnus, all:
Other thoughts:
1) fix category display for pg_settings. 'nuff said.
2) allow *commenting* of pg_settings / SET PERMANENT. Thus:
SET PERMANENT work_mem = '12mb' COMMENT '16mb too high; OOM';
SET
SELECT name, comment FROM pg_settings WHERE name = 'work_mem';
work_mem|
Tom,
The SQL-exposed function knows how to find and replace the definition
of a variable (commented or otherwise) in the primary configuration
file. It does not chase INCLUDEs. If it doesn't find the target
variable anyplace in the primary file, it errors out.
Hmmm. I guess I'm just not
Gregory Stark [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Fixing it would be trivial, I'm sure, but is it really a problem?
The char data type which I was mistakenly using is enough of a wart that it
probably doesn't matter what we do with it. There aren't any security
On Wed, Feb 20, 2008 at 01:27:25PM -0500, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
The problem I've constantly run into with parsing and modifying settings
in a user-edited postgresql.conf file is that sometimes users do their
own chronological documentation:
[snip]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 13:27:25 -0500
Tom Lane [EMAIL PROTECTED] wrote:
For the point-and-drool crowd that can't cope with editing a text
*ahem*
I am far form a point and drool person and I am telling you:
SET PERMANENTLY work_mem TO 65MB ;
Is a
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Feb 20, 2008 at 01:27:25PM -0500, Tom Lane wrote:
For the point-and-drool crowd that can't cope with editing a text file,
perhaps the best avenue to having a GUI is to build it atop the
just-mentioned facility, namely
1. suck out the current
Josh Berkus [EMAIL PROTECTED] writes:
The problem I've constantly run into with parsing and modifying settings
in a user-edited postgresql.conf file is that sometimes users do their
own chronological documentation:
[snip]
Yeah, those are good examples. It would be fairly easy to deal with
Josh Berkus [EMAIL PROTECTED] writes:
2) allow *commenting* of pg_settings / SET PERMANENT. Thus:
SET PERMANENT work_mem = '12mb' COMMENT '16mb too high; OOM';
Ugh :-(
I think that putting this into SET is a pretty bad idea in any case.
SET is, and always has been, a session-local operation.
* Joshua D. Drake [EMAIL PROTECTED] [080220 13:43]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 13:27:25 -0500
Tom Lane [EMAIL PROTECTED] wrote:
For the point-and-drool crowd that can't cope with editing a text
*ahem*
I am far form a point and drool person and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 13:55:05 -0500
Aidan Van Dyk [EMAIL PROTECTED] wrote:
Once we have people comfortable with it rewriting the file, the
bikeshedding can start as to how to use it through the SQL
interface.
But, until there's code out there...
On Wed, Feb 20, 2008 at 01:55:05PM -0500, Aidan Van Dyk wrote:
* Joshua D. Drake [EMAIL PROTECTED] [080220 13:43]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 13:27:25 -0500
Tom Lane [EMAIL PROTECTED] wrote:
For the point-and-drool crowd that can't cope with
On Wed, Feb 20, 2008 at 01:43:46PM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Feb 20, 2008 at 01:27:25PM -0500, Tom Lane wrote:
For the point-and-drool crowd that can't cope with editing a text file,
perhaps the best avenue to having a GUI is to build it atop
* Magnus Hagander [EMAIL PROTECTED] [080220 14:03]:
I think the first step is really for some people to show code that
rewrites the config file changing a setting reliably and correctly.
But what we're donig now is discussing *how to do that*, no?
Sort of, but of course, we're getting
On Mon, Feb 18, 2008 at 03:13:24PM -0300, Alvaro Herrera wrote:
Christian Robottom Reis wrote:
I'm running a conversion of PostgreSQL's CVS repository, but I'm
stuck on a revision that cscvs fails to parse. The hint that the error
gives me is:
Parser error: failed to parse
Hi,
I want to keep an array of localized strings in memory.
This array is dynamically allocated and is going to be used between
transactions (that are not necessarily nested).
It must be cleaned/freed when postmaster exists.
In which context should this array be initialized? TopMemoryContext
Christian Robottom Reis [EMAIL PROTECTED] writes:
On Mon, Feb 18, 2008 at 03:13:24PM -0300, Alvaro Herrera wrote:
There's no corrupted revision -- the text you see is part of a log
message, not a real header line. So the cscvs tool would seem to
need to be able to cope with that.
Wow,
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Feb 20, 2008 at 01:43:46PM -0500, Tom Lane wrote:
The main part of that is the GUI, which is certainly not going to be in
the server, so I fail to see exactly what you think you're really
gaining.
The way things are now, writing the GUI is
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Feb 20, 2008 at 01:43:46PM -0500, Tom Lane wrote:
The main part of that is the GUI, which is certainly not going to be in
the server, so I fail to see exactly what you think you're really
gaining.
The way things are now,
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
No you don't. All you need is the output of the pg_settings view.
Or at least, if that's insufficient, let's discuss exactly how.
I can read the settings. How do I write them, if the only interface to
write them is to deal with the
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
No you don't. All you need is the output of the pg_settings view.
Or at least, if that's insufficient, let's discuss exactly how.
I can read the settings. How do I write them, if the only interface to
write them is
Why isn't pg_ctl.c using PG_VERSIONSTR from miscadmin.h? Seems like
this is something that will have to be kept in sync manually (I see
from the CVS logs that Peter already had to do that once).
If the feeling is that miscadmin.h is a backend include file that
shouldn't be used by pg_ctl (which
Tom Lane wrote:
Why isn't pg_ctl.c using PG_VERSIONSTR from miscadmin.h? Seems like
this is something that will have to be kept in sync manually (I see
from the CVS logs that Peter already had to do that once).
If the feeling is that miscadmin.h is a backend include file that
shouldn't be
Gevik Babakhani wrote:
I want to keep an array of localized strings in memory.
This array is dynamically allocated and is going to be used between
transactions (that are not necessarily nested).
It must be cleaned/freed when postmaster exists.
In which context should this array be initialized?
On Wed, Feb 20, 2008 at 7:34 PM, Tom Lane [EMAIL PROTECTED] wrote:
Josh Berkus [EMAIL PROTECTED] writes:
2) allow *commenting* of pg_settings / SET PERMANENT. Thus:
SET PERMANENT work_mem = '12mb' COMMENT '16mb too high; OOM';
Ugh :-(
I think that putting this into SET is a pretty
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Why isn't pg_ctl.c using PG_VERSIONSTR from miscadmin.h?
It looks like I adapted it from initdb.c - that would make sense given
the time frames.
Oh, I hadn't seen the one in initdb.c. That's just plain silly,
seeing that it's
Being prodded by this, I decided to take another look at why cvsps
doesn't work on PostgreSQL CVS repository...
It happens that it's choking on a bunch of the various REL7_1 tags...
And, the fromcvs converter, which works fine, just happens to *not*
support importing tags - go figure ;-)
So,
On Tue, 2008-02-19 at 14:22 +0100, Magnus Hagander wrote:
I'd like to add a way for a client (in this case, typicallyi pgadmin,
phppgadmin or similar) to get the available options on the server for the
GUC settings we have that take fixed options. This is to make it possible
to generate pretty
Aidan Van Dyk wrote:
And, the fromcvs converter, which works fine, just happens to *not*
support importing tags - go figure ;-)
Meaning it chokes on the $PostgreSQL: ...$ stuff? or what?
cheers
andrew
---(end of broadcast)---
TIP 5:
On Wed, Feb 20, 2008 at 05:00:14PM -0500, Aidan Van Dyk wrote:
So, for people having problems with the cvs repository, try and
eliminate the REL7_1* tags, and see if the problems go away...
I'm currently trying an import off Subversion. Is there a copy of the
CVS repo somewhere I can rsync, if
* Andrew Dunstan [EMAIL PROTECTED] [080220 17:11]:
Aidan Van Dyk wrote:
And, the fromcvs converter, which works fine, just happens to *not*
support importing tags - go figure ;-)
Meaning it chokes on the $PostgreSQL: ...$ stuff? or what?
$something$ are keywords in CVS speak. Tags are
Christian Robottom Reis wrote:
On Wed, Feb 20, 2008 at 05:00:14PM -0500, Aidan Van Dyk wrote:
So, for people having problems with the cvs repository, try and
eliminate the REL7_1* tags, and see if the problems go away...
I'm currently trying an import off Subversion. Is there a copy
Christian Robottom Reis wrote:
I'm currently trying an import off Subversion. Is there a copy of the
CVS repo somewhere I can rsync, if that doesn't work?
Sure:
http://www.postgresql.org/docs/8.3/interactive/rsync.html
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
* Christian Robottom Reis [EMAIL PROTECTED] [080220 17:32]:
On Wed, Feb 20, 2008 at 05:00:14PM -0500, Aidan Van Dyk wrote:
So, for people having problems with the cvs repository, try and
eliminate the REL7_1* tags, and see if the problems go away...
I'm currently trying an import off
* Aidan Van Dyk [EMAIL PROTECTED] [080220 17:00]:
It happens that it's choking on a bunch of the various REL7_1 tags...
And, the fromcvs converter, which works fine, just happens to *not*
support importing tags - go figure ;-)
So, my solution - strip them all out, and low-and-behold, cvsps
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-02-19 at 14:22 +0100, Magnus Hagander wrote:
I'd like to add a way for a client (in this case, typicallyi pgadmin,
phppgadmin or similar) to get the available options on the server for the
GUC settings we have that take fixed options. This is
TopMemoryContext sounds right. Be careful not to leak there.
Thank you :)
I have allocated memory using: MemoryContextAlloc(TopMemoryContext,n *
sizeof(char*));
In pgsql/src/backend/utils/mmgr/README:142 is stated that memory allocated
using above should be freed manually, Is this correct? Or
All,
I think we're failing to discuss the primary use-case for this, which
is one reason why the solutions aren't obvious.
And that use case is: multi-server management.
PostgreSQL is *easy* to manage on one server. For a single server, the
existing text file editor GUIs are clunky but good
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Josh Berkus [EMAIL PROTECTED] [080220 18:00]:
We need a server-based tool for the manipulating postgresql.conf, and
one which is network-accessable, allows updating individual settings,
Do we need to develop our own set of remote management
Aidan Van Dyk wrote:
-- Start of PGP signed section.
* Josh Berkus [EMAIL PROTECTED] [080220 18:00]:
All,
I think we're failing to discuss the primary use-case for this, which
is one reason why the solutions aren't obvious.
However, imagine you're adminning 250 PostgreSQL servers
* Josh Berkus [EMAIL PROTECTED] [080220 18:00]:
All,
I think we're failing to discuss the primary use-case for this, which
is one reason why the solutions aren't obvious.
However, imagine you're adminning 250 PostgreSQL servers backing a
social networking application. You decide the
Gevik Babakhani wrote:
I have allocated memory using: MemoryContextAlloc(TopMemoryContext,n *
sizeof(char*));
In pgsql/src/backend/utils/mmgr/README:142 is stated that memory allocated
using above should be freed manually, Is this correct? Or does the system
release everything allocated in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 18:38:09 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
Agreed. Put postgresql.conf on an NFS server and restart the servers.
Bruce, that is insane.
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company since 1997:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 18:38:10 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Josh Berkus [EMAIL PROTECTED] [080220 18:00]:
We need a server-based tool for the manipulating postgresql.conf,
and one which is
On backend exit, everything in TopMemoryContext, like all
other non-shared memory, is automatically released.
So it is safe to not free the allocated memory in TopMemoryContext and leave
it to be released on backend exit.
Thank you for the help :)
Regards,
Gevik.
Tom Lane [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
All this discussion seems to me to be going off into the clouds, where
every objection is met with some still more elaborate scheme. I think we
need to look at simple, incremental, and if possible backwards
Tom Lane wrote:
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Josh Berkus [EMAIL PROTECTED] [080220 18:00]:
We need a server-based tool for the manipulating postgresql.conf, and
one which is network-accessable, allows updating individual settings,
Do we need to develop our own
On Thu, Feb 21, 2008 at 12:02 AM, Josh Berkus [EMAIL PROTECTED] wrote:
All,
I think we're failing to discuss the primary use-case for this, which
is one reason why the solutions aren't obvious.
And that use case is: multi-server management.
...and third-party management solutions.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The way I intended to do it would indeed allow it to be undone
simply by executing 'drop language plpgsql' in template1.
Why isn't it enough that administrators can do CREATE LANGUAGE
plpgsql in template1?
Because people do not have the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 09:42:02 -0500
Andrew Dunstan [EMAIL PROTECTED] wrote:
All this discussion seems to me to be going off into the clouds,
where every objection is met with some still more elaborate scheme. I
think we need to look at simple,
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
The problem I've constantly run into with parsing and modifying settings
in a user-edited postgresql.conf file is that sometimes users do their
own chronological documentation:
[snip]
Yeah, those are good examples. It would be
* Joshua D. Drake [EMAIL PROTECTED] [080220 21:15]:
The one thing this does is make the postgresql.conf basically a
placeholder. It is not definitive anymore, in the sense that settings
will be overwritten on restart. That really isn't that uncommon anyway
in other applications.
Man, I'ld
Gevik Babakhani wrote:
On backend exit, everything in TopMemoryContext, like all
other non-shared memory, is automatically released.
So it is safe to not free the allocated memory in TopMemoryContext and leave
it to be released on backend exit.
All local memory is safe to handle that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 23:02:34 -0500
Aidan Van Dyk [EMAIL PROTECTED] wrote:
* Joshua D. Drake [EMAIL PROTECTED] [080220 21:15]:
The one thing this does is make the postgresql.conf basically a
placeholder. It is not definitive anymore, in the
This is a proposal of fast data loading using batch update of indexes for 8.4.
It is a part of pg_bulkload (http://pgbulkload.projects.postgresql.org/) and
I'd like to integrate it in order to cooperate with other parts of postgres.
The basic concept is spooling new coming data, and merge the
Dawid Kuroczko [EMAIL PROTECTED] wrote:
I am sure the idea is not original, yet still I would like to know how hard
would it be to support local (per table) oldest visible XIDs.
I mean, when transaction start you need to keep all tuples with xmin =
oldest_xid in all tables, because who
Greg Sabino Mullane [EMAIL PROTECTED] writes:
I'm not sure I understand the security implications of turning plpgsql on:
has there been some security concerns in the past? Does having access
to plpgsql really faciliate an attacker that much above what they might
already be capable of without
I got around to testing PG 8.3 on HPUX on Itanium (feel free to play
along at www.testdrive.hp.com) ... and was dismayed to find that it
doesn't work. If compiled with HP's C compiler, the regression tests
dump core. Investigation shows that the problem occurs where
tuptoaster.c tries to copy a
On 21/02/2008, Joshua D. Drake [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Feb 2008 23:02:34 -0500
Aidan Van Dyk [EMAIL PROTECTED] wrote:
* Joshua D. Drake [EMAIL PROTECTED] [080220 21:15]:
The one thing this does is make the postgresql.conf
95 matches
Mail list logo
