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.
B
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
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
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
Types'
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: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
> 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
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
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
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
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 "
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 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
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
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
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
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
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
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 pa
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
"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
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
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
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 aggregat
"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:
>> 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
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 limi
> 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
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
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
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
> >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
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
> "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
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
* 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
> 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 choos
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
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
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
* 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
> "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
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
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 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
* 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 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
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
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 s
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
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
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
* 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
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 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
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
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 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
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.
> >
> >
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
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
> 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
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
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 inst
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
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 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:
> 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
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
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
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
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
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
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
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)--
89 matches
Mail list logo
