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 broadcast)--
Kevin Grittner wrote:
> >>> On Wed, Feb 1, 2006 at 10:50 am, in message
> <[EMAIL PROTECTED]>, Bruce Momjian
> 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) is
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 same
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 a
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 enable
On Friday 10 February 2006 00:53, Mark Woodward wrote:
> > Martijn van Oosterhout 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 -ENO
> Martijn van Oosterhout 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 actually
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 foll
Martijn van Oosterhout 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 actually have memor
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 w
Martijn van Oosterhout 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 like
/var/pos
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
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 inst
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
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
> 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
>> > > transactio
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.
r
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. Ev
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.
> >
> >
Bruce Momjian 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 behavior, and w
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.
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
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 like that, I think we
* 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 ul
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 a
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 be
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 de
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 s
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
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
> 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
* 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
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 Li
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
>
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, e
> "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
* 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
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 r
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: op
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 o
"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 choos
> 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
* 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
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 tha
> "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 t
Tom Lane wrote:
Martijn van Oosterhout 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).
Woul
> >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 th
Martijn van Oosterhout 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).
> Would it be r
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 pg
On Thu, Feb 09, 2006 at 09:33:35AM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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
> 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 coul
"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 limi
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:
>> 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 mem
"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
> "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 aggregat
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 o
"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
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?
-
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
> "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
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-tab
"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 a
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 run
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 pa
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=#
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 unprivile
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 Kerbe
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 able
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 m
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 unexpected
Tom Lane wrote:
Martijn van Oosterhout 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
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
Martijn van Oosterhout 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 superusers can "
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 t
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 po
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 re
> 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 h
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 m
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 preve
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
Types'
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
>
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
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 e
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.
B
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
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
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
89 matches
Mail list logo
