On Wed, 2006-02-08 at 11:10 +0100, Csaba Nagy wrote:
Another issue is that unless you got the archive_command right in the
master server from the beginning, you will have to restart the server
once you decide to build your standby... the archive_command is a
start-up time parameter
Much of
On Wed, Feb 08, 2006 at 09:04:46PM -0500, Tom Lane wrote:
http://archives.postgresql.org/pgsql-admin/2006-02/msg00084.php
reports a problem with default btree operator classes that are
not in pg_catalog: you can create a UNIQUE or PRIMARY KEY constraint
that depends on such an opclass, but
OK, this is news to me, I recall that last looking at the configuration
docs it was start-up time, but I might be wrong.
[looking up the docs]
OK, citing the 8.1 online docs:
17.5.3. Archiving
archive_command (string)
The shell command to execute to archive a completed segment
To give it to you straight... its just to ease the minds of management.
Someone pointed out to them how easy it really is to access the data, and
this kind of started to make them feel uncomfortable.
They know the admins are very computer literate and that any protection
can be broken by them.
Hi,
I'd like to enable UDT's written in Java and made some initial trial and
error. I don't get very far. Here's what I do:
I take the 'complex' type example described in '31.11 User-Defined
Types' and change it to use Java functions (see below). But I get:
ERROR: type complex does not
On Thu, Feb 09, 2006 at 01:08:01PM +0100, Thomas Hallgren wrote:
Hi,
I'd like to enable UDT's written in Java and made some initial trial and
error. I don't get very far. Here's what I do:
I take the 'complex' type example described in '31.11 User-Defined
Types' and change it to use Java
Tom Lane wrote:
Given that we only allow one default opclass for a datatype regardless
of schema (see DefineOpClass), it's not really necessary for
GetDefaultOpClass to restrict its search. I can think of some corner
cases involving multiple binary-compatible-datatype matches where the
Martijn van Oosterhout wrote:
On Thu, Feb 09, 2006 at 01:08:01PM +0100, Thomas Hallgren wrote:
Hi,
I'd like to enable UDT's written in Java and made some initial trial and
error. I don't get very far. Here's what I do:
I take the 'complex' type example described in '31.11 User-Defined
On Thu, Feb 09, 2006 at 01:53:13PM +0100, Thomas Hallgren wrote:
If you look at the code it says in a comment:
/*
* Only C-coded functions can be I/O functions. We
enforce this
* restriction here mainly to prevent
Martijn van Oosterhout wrote:
On Thu, Feb 09, 2006 at 01:53:13PM +0100, Thomas Hallgren wrote:
If you look at the code it says in a comment:
/*
* Only C-coded functions can be I/O functions. We
enforce this
* restriction here
If you want the data hidden from system administrators, you need to have
the client encrypt it before storing it. Of course, that will have
massive implications for your application.
Have you considered storing your data on an encrypted filesystem? I have no
idea what kind of performance hit
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Given that we only allow one default opclass for a datatype regardless
of schema (see DefineOpClass), it's not really necessary for
GetDefaultOpClass to restrict its search.
How about doing the constrained search first, and revert to
Thomas Hallgren [EMAIL PROTECTED] writes:
I'd like to enable UDT's written in Java
Does Java really give you enough control over the bit-level
representation of an object for this goal to be considered sane?
In particular, it seems unsafe to use a Java class as a PG UDT,
because the method
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
I'd like to enable UDT's written in Java
Does Java really give you enough control over the bit-level
representation of an object for this goal to be considered sane?
Most definitely yes!
In particular, it seems unsafe to
Martijn van Oosterhout kleptog@svana.org writes:
Actually, I'm think this whole automatic creation of a shell-type a bit
silly anyway. Why not simply solve the problem directly like so:
CREATE TYPE complex AS SHELL;
One of the unwritten consequences of the way that it works now is that
only
korry wrote:
If you want the data hidden from system administrators, you need to have
the client encrypt it before storing it. Of course, that will have
massive implications for your application.
Have you considered storing your data on an encrypted filesystem? I have no
idea what kind
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Actually, I'm think this whole automatic creation of a shell-type a bit
silly anyway. Why not simply solve the problem directly like so:
CREATE TYPE complex AS SHELL;
One of the unwritten consequences of the
PostgreSQL promptly uses all available memory for the query and
subsequently crashes.
I'm sure it can be corrected with a setting, but should it crash?
freedb=# create table ucode as select distinct ucode from cdtitles group
by ucode having count(ucode)1 ;
server closed the connection
On 2/7/06, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Rawnsley [EMAIL PROTECTED] writes:
IMHO the #1 priority in the current PITR/WAL shipping system is to make the
standby able to tolerate being shut down and restarted, i.e. actually having
a true standby mode and not the current method of
The interval datatype can go to microsecond precision though currently
the smallest unit is seconds. Microseconds are represented as decimal
places, eg 5 microseconds is 0.05 seconds.
To insert microseconds I have to use the following line, ($1*0.01 ||
' seconds')::interval
Being
Devrim GUNDUZ [EMAIL PROTECTED] wrote:
Hi,
On Wed, 2006-02-08 at 11:28 -0500, Stephen Frost wrote:
I'd really like to see the multiple DB connections with different
Kerberos credentials go in to 8.1.3. It solved the problem we were
having authenticating to PostgreSQL using Kerberos from
Title: {I} One Information required...
Hi all,
When I try to run initdb id get the messing creating template1 database in c:/postgres/data/base/1 ... Execution of PostgreS
QL by a user with administrative permissions is not permitted. The server must be started under an unprivileged user
More info: the machine has 512M RAM and 512M swap
Work mem is set to:work_mem = 1024
This should't have crashed, should it?
PostgreSQL promptly uses all available memory for the query and
subsequently crashes.
I'm sure it can be corrected with a setting, but should it crash?
freedb=#
Alexander Schreiber wrote:
At least two of the distributions I use
regularly (Gentoo and Debian) have the habit of adding a load of patches
during package build. And not all of those go back to the upstream, to
put it mildly ...
And they are not always sensible. A while back the Gentoo
Hey,
Simply create a new non adminstrator user, say postgres with a password.
Give this user write permissions to the empty data directory.
Then login as this user and run initdb like did before.
You are going to have to register the postgres service under this user too.
You can do this by
Mark Woodward [EMAIL PROTECTED] writes:
PostgreSQL promptly uses all available memory for the query and
subsequently crashes.
I'll bet a nickel this is on a Linux machine with OOM kill enabled.
What does the postmaster log show --- or look in the kernel log to
see if it mentions anything about
Thomas Hallgren [EMAIL PROTECTED] writes:
Tom Lane wrote:
In particular, it seems unsafe to use a Java class as a PG UDT,
because the method pointers wouldn't remain the same across
backend runs.
I'm not sure I understand what you mean.
Doesn't a Java object contain a method-table pointer
Mark Woodward [EMAIL PROTECTED] writes:
PostgreSQL promptly uses all available memory for the query and
subsequently crashes.
I'll bet a nickel this is on a Linux machine with OOM kill enabled.
What does the postmaster log show --- or look in the kernel log to
see if it mentions anything
Stephen Frost wrote:
Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it.
Sorry that Debian/stable releases havn't been coming out as frequently
as they really should have been. We're working on that, honest!
The only thing that I hate is that libpq defaults to searching
David Tulloh [EMAIL PROTECTED] writes:
To insert microseconds I have to use the following line, ($1*0.01 ||
' seconds')::interval
Actually, the preferred way to do that is to use the numeric-times-interval
operator, eg
regression=# select 7 * '0.01 second'::interval;
?column?
Mark Woodward [EMAIL PROTECTED] writes:
- HashAggregate (cost=106527.68..106528.68 rows=200 width=32)
Filter: (count(ucode) 1)
- Seq Scan on cdtitles (cost=0.00..96888.12 rows=1927912
width=32)
Well, shouldn't hash aggregate respect work memory
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
Tom Lane wrote:
In particular, it seems unsafe to use a Java class as a PG UDT,
because the method pointers wouldn't remain the same across
backend runs.
I'm not sure I understand what you mean.
Doesn't a Java
Mark Woodward [EMAIL PROTECTED] writes:
- HashAggregate (cost=106527.68..106528.68 rows=200
width=32)
Filter: (count(ucode) 1)
- Seq Scan on cdtitles (cost=0.00..96888.12
rows=1927912
width=32)
Well, shouldn't hash aggregate respect work memory
Mark Woodward [EMAIL PROTECTED] writes:
Still, I would say that is is extremly bad behavior for not having
stats, wouldn't you think?
Think of it as a kernel bug.
Meanwhile, I'd strongly recommend turning off OOM kill. That's got to
be the single worst design decision in the entire Linux
Mark Woodward [EMAIL PROTECTED] writes:
Still, I would say that is is extremly bad behavior for not having
stats, wouldn't you think?
Think of it as a kernel bug.
While I respect your viewpoint that the Linux kernel should not kill an
offending process if the system runs out of memory, I
Tom Lane wrote:
Mark Woodward [EMAIL PROTECTED] writes:
Still, I would say that is is extremly bad behavior for not having
stats, wouldn't you think?
Think of it as a kernel bug.
Meanwhile, I'd strongly recommend turning off OOM kill. That's got to
be the single worst design
Mark Woodward [EMAIL PROTECTED] writes:
I think it is still a bug. While it may manifest itself as a pg crash on
Linux because of a feature with which you have issue, the fact remains
that PG is exeeding its working memory limit.
The problem is that *we have no way to know what that limit is*
Since what he is worried about is the ability of admins to get at the
data by connecting to the postgres server (after changing pg_hba.conf),
this will not make the slightest difference - the data would be
decrypted before it ever got to the intruder.
I was suggesting that pg_hba.conf could
On Thu, Feb 09, 2006 at 09:33:35AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Actually, I'm think this whole automatic creation of a shell-type a bit
silly anyway. Why not simply solve the problem directly like so:
CREATE TYPE complex AS SHELL;
One of the
korry wrote:
Since what he is worried about is the ability of admins to get at the
data by connecting to the postgres server (after changing pg_hba.conf),
this will not make the slightest difference - the data would be
decrypted before it ever got to the intruder.
I was suggesting that
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Feb 09, 2006 at 09:33:35AM -0500, Tom Lane wrote:
You'd have to go over a lot of code with a fine-tooth comb before
putting this ability into the hands of ordinary users, else you'd be
creating loopholes for DOS attacks (or worse).
I was suggesting that pg_hba.conf could be stored in the same encrypting
filesystem.
Then how can it be changed? What if you need to allow access from, say,
another user or another network? Oh, the admins have to change it ...
Not all admins are equal... the admin that takes care of the
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Feb 09, 2006 at 09:33:35AM -0500, Tom Lane wrote:
You'd have to go over a lot of code with a fine-tooth comb before
putting this ability into the hands of ordinary users, else you'd be
creating loopholes for DOS attacks
Mark Woodward [EMAIL PROTECTED] writes:
I think it is still a bug. While it may manifest itself as a pg crash on
Linux because of a feature with which you have issue, the fact remains
that PG is exeeding its working memory limit.
The problem is that *we have no way to know what that limit
korry wrote:
I was suggesting that pg_hba.conf could be stored in the same encrypting
filesystem.
Then how can it be changed? What if you need to allow access from, say,
another user or another network? Oh, the admins have to change it ...
Not all admins are equal... the admin
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it.
Sorry that Debian/stable releases havn't been coming out as frequently
as they really should have been. We're working on that, honest!
The only thing
Why would you not simply set this up on a seperate machine to which only
the trusted admins had access? Most data centers I am familiar with use
single purpose machines anyway. If someone is trusted as root on your
box they can screw you no matter what you do. Pretending otherwise is
just
Mark Woodward [EMAIL PROTECTED] writes:
Again, regardless of OS used, hashagg will exceed working memory as
defined in postgresql.conf.
So? If you've got OOM kill enabled, it can zap a process whether it's
strictly adhered to work_mem or not. The OOM killer is entirely capable
of choosing a
I'm having some problems when using pfree() on functions in C.Calling it on psql gives the exception below on both versions of function insert() [1,2] if pfree() is enabled:
server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing
On Thu, Feb 09, 2006 at 10:37:34AM +0100, Csaba Nagy wrote:
option can only be set at server start or in the postgresql.conf
Yeah, this is something that was actually discussed on -docs recently. I
believe -HEAD was changed so that every parameter that used to have that
text now says:
On Thu, Feb 09, 2006 at 04:44:20PM +0200, Marko Kreen wrote:
On 2/7/06, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Rawnsley [EMAIL PROTECTED] writes:
IMHO the #1 priority in the current PITR/WAL shipping system is to make
the
standby able to tolerate being shut down and restarted, i.e.
* Tom Lane ([EMAIL PROTECTED]) wrote:
Mark Woodward [EMAIL PROTECTED] writes:
Again, regardless of OS used, hashagg will exceed working memory as
defined in postgresql.conf.
So? If you've got OOM kill enabled, it can zap a process whether it's
strictly adhered to work_mem or not. The
Mark Woodward [EMAIL PROTECTED] writes:
Again, regardless of OS used, hashagg will exceed working memory as
defined in postgresql.conf.
So? If you've got OOM kill enabled, it can zap a process whether it's
strictly adhered to work_mem or not. The OOM killer is entirely capable
of choosing
On Thu, Feb 09, 2006 at 10:30:30AM -0500, Tom Lane wrote:
David Tulloh [EMAIL PROTECTED] writes:
To insert microseconds I have to use the following line, ($1*0.01 ||
' seconds')::interval
Actually, the preferred way to do that is to use the numeric-times-interval
operator, eg
On Thu, Feb 09, 2006 at 02:03:41PM -0500, Mark Woodward wrote:
Mark Woodward [EMAIL PROTECTED] writes:
Again, regardless of OS used, hashagg will exceed working memory as
defined in postgresql.conf.
So? If you've got OOM kill enabled, it can zap a process whether it's
strictly adhered
On Thu, Feb 09, 2006 at 11:42:57AM -0500, Mark Woodward wrote:
Mark Woodward [EMAIL PROTECTED] writes:
Still, I would say that is is extremly bad behavior for not having
stats, wouldn't you think?
Think of it as a kernel bug.
While I respect your viewpoint that the Linux kernel should
* Jim C. Nasby ([EMAIL PROTECTED]) wrote:
On Thu, Feb 09, 2006 at 02:03:41PM -0500, Mark Woodward wrote:
If it is not something that can be fixed, it should be clearly documented.
work_mem (integer)
Specifies the amount of memory to be used by internal sort
operations and hash
On Thu, Feb 09, 2006 at 02:03:41PM -0500, Mark Woodward wrote:
Mark Woodward [EMAIL PROTECTED] writes:
Again, regardless of OS used, hashagg will exceed working memory as
defined in postgresql.conf.
So? If you've got OOM kill enabled, it can zap a process whether it's
strictly
On Wed, Feb 08, 2006 at 10:57:20PM -0500, Bruce Momjian wrote:
TODO has:
* %Disallow changing default expression of a SERIAL column
Sure, the DROP SERIAL I proposed would rather change the data type
to int by dropping the default and would delete referring pg_depend entries.
Stephen Frost [EMAIL PROTECTED] writes:
Unless I've missed something here, disabling the OOM killer doesn't
really solve the problem here.
Well in a way it does. Postgres would get an out-of-memory error from malloc
which it would handle properly and the world would be happy.
Except not
Greg Stark [EMAIL PROTECTED] writes:
Except not quite, since I think an out of memory error still means that
backend exits instead of just that query failing.
Not at all! PG will recover from this perfectly well ... if it's given
the opportunity, rather than being SIGKILLed.
It doesn't seem
Joachim Wieland wrote:
On Wed, Feb 08, 2006 at 10:57:20PM -0500, Bruce Momjian wrote:
TODO has:
* %Disallow changing default expression of a SERIAL column
Sure, the DROP SERIAL I proposed would rather change the data type
to int by dropping the default and would delete
Thomas Hallgren [EMAIL PROTECTED] writes:
What do you think of my earlier suggestion. Skip all the 'create function'
statements and
just add the AS 'filename' LANGUAGE C to the CREATE TYPE.
Very little, as it makes unjustifiable assumptions about all the
datatype's support functions being
Greg Stark wrote:
Well in a way it does. Postgres would get an out-of-memory error from malloc
which it would handle properly and the world would be happy.
Except not quite, since I think an out of memory error still means that
backend exits instead of just that query failing.
Not at all
* Tom Lane ([EMAIL PROTECTED]) wrote:
Greg Stark [EMAIL PROTECTED] writes:
It doesn't seem like a bad idea to have a max_memory parameter that if a
backend ever exceeded it would immediately abort the current
transaction.
See ulimit (or local equivalent).
As much as setting ulimit in
Bruce Momjian pgman@candle.pha.pa.us writes:
Is it also desired to convert an int column to a serial column?
I think the only sane solution is if a SERIAL column is changed to
INTEGER, the default and dependencies are removed. Do you want a TODO
for that?
If we are going to do something
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Is it also desired to convert an int column to a serial column?
I think the only sane solution is if a SERIAL column is changed to
INTEGER, the default and dependencies are removed. Do you want a TODO
for that?
If we are
Stephen Frost wrote:
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Oh, pah, I'm there already, as 'Snow-Man' and I've heard all about it.
Sorry that Debian/stable releases havn't been coming out as frequently
as they really should have been. We're working on that,
Alvaro Herrera wrote:
Stephen Frost wrote:
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
The only thing that I hate is that libpq defaults to searching the
local socket in /var/postgresql/ or thereabouts. It really drives me
crazy and I've banned the libpq packages from my system.
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
If we are going to do something like that, I think we should take a hard
look at the idea I floated of putting SERIAL back to a pure
creation-time macro for type and default expression. This is getting to
have way too much hidden
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Greg Stark [EMAIL PROTECTED] writes:
It doesn't seem like a bad idea to have a max_memory parameter that if a
backend ever exceeded it would immediately abort the current
transaction.
See ulimit (or
Tom Lane wrote:
The only thing we'd lose is that dropping a column
originally declared as serial wouldn't implicitly drop the sequence.
Wasn't that the primary purpose that the main coder for dependencies did
the work for? AFAIR the fact that the sequence wasn't dropped was a big
gotcha.
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe this should be a configure flag, just like the port number is.
It is ... that isn't the issue, the problem is exactly that Debian
chooses to exercise the option to make their installations different
from everyone else's.
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Greg Stark [EMAIL PROTECTED] writes:
It doesn't seem like a bad idea to have a max_memory parameter that
if a
backend ever exceeded it would immediately abort the current
transaction.
See ulimit (or
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
The only thing we'd lose is that dropping a column
originally declared as serial wouldn't implicitly drop the sequence.
Wasn't that the primary purpose that the main coder for dependencies did
the work for?
My recollection is that the
On Thu, Feb 09, 2006 at 04:16:51PM -0200, Rodrigo Hjort wrote:
I'm having some problems when using pfree() on functions in C.
Calling it on psql gives the exception below on both versions of function
insert() [1,2] if pfree() is enabled:
server closed the connection unexpectedly
On Thu, Feb 09, 2006 at 03:16:29PM -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe this should be a configure flag, just like the port number is.
It is ... that isn't the issue, the problem is exactly that Debian
chooses to exercise the option to make their
On Thu, Feb 09, 2006 at 02:35:34PM -0500, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Except not quite, since I think an out of memory error still means that
backend exits instead of just that query failing.
Not at all! PG will recover from this perfectly well ... if it's given
Martijn van Oosterhout kleptog@svana.org writes:
FWIW, I prefer the Debian location. AFAICS the only rationale for
putting it in /tmp is because it's always been there.
Actually, it's because it's certain to be there and be accessible to
unprivileged users. If we tried to change to something
On Feb 9, 2006, at 11:22 AM, Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Mark Woodward [EMAIL PROTECTED] writes:
Again, regardless of OS used, hashagg will exceed working
memory as
defined in postgresql.conf.
So? If you've got OOM kill enabled, it can zap a process
Martijn van Oosterhout kleptog@svana.org writes:
When people talk about disabling the OOM killer, it doesn't stop the
SIGKILL behaviour,
Yes it does, because the situation will never arise.
it just causes the kernel to return -ENOMEM for
malloc() much much earlier... (ie when you still
Rodrigo Hjort [EMAIL PROTECTED] writes:
I'm having some problems when using pfree() on functions in C.
I think your pfree is just the bearer of bad news, ie, it's the victim
of a memory clobber that you've already executed. Take another look at
your string manipulation --- that strncpy followed
Martijn van Oosterhout kleptog@svana.org writes:
When people talk about disabling the OOM killer, it doesn't stop the
SIGKILL behaviour,
Yes it does, because the situation will never arise.
it just causes the kernel to return -ENOMEM for
malloc() much much earlier... (ie when you still
On Friday 10 February 2006 00:53, Mark Woodward wrote:
Martijn van Oosterhout kleptog@svana.org writes:
When people talk about disabling the OOM killer, it doesn't stop the
SIGKILL behaviour,
Yes it does, because the situation will never arise.
it just causes the kernel to return
On Feb 9, 2006, at 12:49 PM, Mark Woodward wrote:
On Thu, Feb 09, 2006 at 02:03:41PM -0500, Mark Woodward wrote:
Mark Woodward [EMAIL PROTECTED] writes:
Again, regardless of OS used, hashagg will exceed working
memory as
defined in postgresql.conf.
So? If you've got OOM kill enabled, it
Rick Gigger [EMAIL PROTECTED] writes:
However if hashagg truly does not obey the limit that is supposed to
be imposed by work_mem then it really ought to be documented. Is
there a misunderstanding here and it really does obey it? Or is
hashagg an exception but the other work_mem
This generalizes to any scale factor you care to use, eg fortnights...
so I don't see a pressing need to add microseconds.
Perhaps an argument for adding microseconds to interval declarations is
that you can extract them using extract()... Those two lists of allowed
scales should be the
Kevin Grittner wrote:
On Wed, Feb 1, 2006 at 10:50 am, in message
[EMAIL PROTECTED], Bruce Momjian
pgman@candle.pha.pa.us wrote:
(1) I couldn't figure out the best way to obtain a value for
standard_conforming_strings in the psql version of the scanner.
The proper way to do (1)
On 2/9/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
What happens right now when you want to bring the standby up? Do you
have to kill it out of recovery mode and re-start, forcing it to replay
WAL again anyway?
touch $LOGDIR/STOP ...
--
marko
---(end of
89 matches
Mail list logo
