> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > The connection was terminated.
The connection has been terminated. ??
> > > And make the postmaster print out
> > > The system is shutting down.
> > > before it sends out the SIGTERM's.
I like above. Imho it is sufficient i
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Seems like overkill to me. We could have the postmaster use SIGQUIT for
> > db shutdown and leave SIGKILL for admin shutdown of individual backends.
>
> Wrong... at least not with the current definitions of those signals!
I see you just changed th
[ Charset ISO-8859-1 unsupported, converting... ]
> > > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > > The connection was terminated.
>
> The connection has been terminated. ??
>
> > > > And make the postmaster print out
> > > > The system is shutting down.
> > >
> First day in week is Monday in ISO week.
> Thomas, we have ISO week-of-year (IW in to_char or 'week' in date_part),
> but we haven't ISO day-of-week (may be as 'ID' for to_char).
> TODO for 7.2?
> ..but in ISO is 0-6; 0=Mon
I've been ignoring this until now, hoping no one would notice ;)
Uni
On Wed, Mar 14, 2001 at 02:50:35PM +, Thomas Lockhart wrote:
> > First day in week is Monday in ISO week.
> > Thomas, we have ISO week-of-year (IW in to_char or 'week' in date_part),
> > but we haven't ISO day-of-week (may be as 'ID' for to_char).
> > TODO for 7.2?
> > ..but in ISO is 0-6; 0
"Martin A. Marques" <[EMAIL PROTECTED]> writes:
> CheckPoint Data Base: fork failed: Not enough space
> [ whereupon postmaster quits ]
> Any idea on this? I think the the postmaster shouldn't die, at least it's
> what I first thought.
I agree. Dying if the startup subjob fails is one thing, bu
> Unix day-of-week starts on Sunday, not Monday, which is what
> date_trunc('dow',...) returns. Presumably this is modeled on the
> traditional notion (at least in the US; I suspect this is true in most
> European countries at least) of Sunday being "the first day of week".
Germany and Austria h
>OK, I phoned Tom and we agreed on this wording:
>
> This connection has been terminated by the administrator
>
>Comments?
This connection has been terminated by an administrator
(there may be more than one...) :)
Other than that it's informative enough.
OTOH, I had a small thought on
I would like to apply the following patch to the CVS tree. It allows
pgmonitor to show query strings even if the backend is not compiled with
debug symbols.
It does this by creating a global variable 'debug_query_string' and
assigning it when the query begins and clearing it when the query ends.
Thomas Swan writes:
> It may seem stupid but I was thinking the reason could be an argument to
> the pg_ctl program with a default of (Database Shutdown).
>
> pg_ctl stop --message="System going down for a reboot"
> or
> pg_ctl stop -msg "System upgrade. System will be available again at 5:00am"
not with me it isn't ... it doesn't fix a bug, it doesn't go in ... save
it for after v7.1 is released ...
On Wed, 14 Mar 2001, Bruce Momjian wrote:
> I would like to apply the following patch to the CVS tree. It allows
> pgmonitor to show query strings even if the backend is not compiled wit
>
> not with me it isn't ... it doesn't fix a bug, it doesn't go in ... save
> it for after v7.1 is released ...
You are saying save it for 7.2, right? That will certainly be months
away. Without this patch, pgmonitor's 'query' button will only work if
the postgres binary was compiled with deb
On Wed, 14 Mar 2001, Bruce Momjian wrote:
> >
> > not with me it isn't ... it doesn't fix a bug, it doesn't go in ... save
> > it for after v7.1 is released ...
>
> You are saying save it for 7.2, right? That will certainly be months
> away. Without this patch, pgmonitor's 'query' button will o
> On Wed, 14 Mar 2001, Bruce Momjian wrote:
>
> > >
> > > not with me it isn't ... it doesn't fix a bug, it doesn't go in ... save
> > > it for after v7.1 is released ...
> >
> > You are saying save it for 7.2, right? That will certainly be months
> > away. Without this patch, pgmonitor's 'quer
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> The POSIX numbering (0-6) is actually pretty slick because
Peter> it allows both versions to work: In the U.S. (e.g.) you get
Peter> a natural order starting at 0, in Germany (e.g.) you get
Peter> Monday as #1.
> Bruce Momjian writes:
>
> > It does this by creating a global variable 'debug_query_string' and
> > assigning it when the query begins and clearing it when the query ends.
>
> You can find out the current query for a given backend by configuring the
> server with "debug_print_query on" and "lo
Bruce Momjian writes:
> It does this by creating a global variable 'debug_query_string' and
> assigning it when the query begins and clearing it when the query ends.
You can find out the current query for a given backend by configuring the
server with "debug_print_query on" and "log_pids on" and
> "AZ" == Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> Unix day-of-week starts on Sunday, not Monday, which is what
>> date_trunc('dow',...) returns. Presumably this is modeled on
>> the traditional notion (at least in the US; I suspect this is
>> true in most Europea
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> I'm saying no because it doesn't fix any known bugs, it *adds* another
> feature ... we are *months* too late in the cycle for that ...
I thought it was a pretty good idea even without any consideration for
Bruce's monitor program. The advantage is
On Wed, 14 Mar 2001, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > It does this by creating a global variable 'debug_query_string' and
> > assigning it when the query begins and clearing it when the query ends.
>
> You can find out the current query for a given backend by configuring the
> > This doesn't tell you whether the query is still running, but ps tells you
> > that. In fact, it might be an idea to add a logging option that prints
> > something like "query finished in xxx ms". We actually have something
> > similar hidden under show_query_stats, but the formatting needs
On Wed, Mar 14, 2001 at 04:54:54PM +0100, Zeugswetter Andreas SB wrote:
> > Unix day-of-week starts on Sunday, not Monday, which is what
> > date_trunc('dow',...) returns. Presumably this is modeled on the
> > traditional notion (at least in the US; I suspect this is true in most
> > European coun
Jim Mercer writes:
> most western calendars that i have seen show "Sun Mon Tue Wed Thu Fri Sat".
Most *English* calendars you have seen, I suppose. In Germany there is no
such possible calendar. If you printed a calendar that way, it would be
considered a printo. The same is true in most part
On Wed, Mar 14, 2001 at 07:02:41PM +0100, Peter Eisentraut wrote:
> Jim Mercer writes:
> > most western calendars that i have seen show "Sun Mon Tue Wed Thu Fri Sat".
>
> Most *English* calendars you have seen, I suppose. In Germany there is no
> such possible calendar. If you printed a calenda
At 3/14/2001 11:13 AM, Peter Eisentraut wrote:
>Thomas Swan writes:
>
> > It may seem stupid but I was thinking the reason could be an argument to
> > the pg_ctl program with a default of (Database Shutdown).
> >
> > pg_ctl stop --message="System going down for a reboot"
> > or
> > pg_ctl stop -ms
> traditional notion (at least in the US; I suspect this is true in most
> European countries at least) of Sunday being "the first day of week".
I believe that in most European countries, Monday is the first day of the
week.
--
Kaare Rasmussen--Linux, spil,--Tlf:38
"Martin A. Marques" <[EMAIL PROTECTED]> writes:
>> I agree. Dying if the startup subjob fails is one thing, but dying
>> because a routine checkpoint fails is another. The code is treating
>> those two cases alike however ... will change it.
> Just happend again. At this moment the postgres on
Philip Warner <[EMAIL PROTECTED]> writes:
> Fixed & done...
Only part of the way there: pg_dump is still pretty seriously broken for
mixed-case table names. Observe:
regression=# create table "Foo" (z int);
CREATE
regression=# \q
$ pg_dump -a -t '"Foo"' regression
--
-- Selected TOC Entries:
--
I'm running Postgres 7.0.3 on a RedHat Linux 6.1. For some reason, rtrim
is giving me an incorrect result:
db01=# SELECT tablename FROM pg_tables WHERE tablename LIKE '%_opto' AND
tablename NOT LIKE 'pg%' ORDER BY tablename ASC ;
tablename
-
center_out_opto
circles_opto
e
"G. Anthony Reina" <[EMAIL PROTECTED]> writes:
> I'm running Postgres 7.0.3 on a RedHat Linux 6.1. For some reason, rtrim
> is giving me an incorrect result:
No, you have an incorrect understanding of rtrim. The second argument
is a set of removable characters, not a string to be matched.
AFAIK
Hi, all,
Could somebody tell me if there is a work around to
create "union on view" (which seems not implemented
in the postgres yet) ?
Also, is there any alternative query that can do:
select * from (select * from table);
I could not find an answer from the old archieve,
and sorry if this ha
If you're willing to wait or use the betas, 7.1
should probably do both of these. (Won't
quite make toast though).
[Although I believe the second'll be something
like: select * from (select * from table) alias;]
On Wed, 14 Mar 2001, Jae-Woong Hwnag wrote:
> Hi, all,
>
> Could somebody tell
The second parameter to "rtrim" is interpreted as a set of characters and
rtrim:
"Returns string with final characters removed after the last character not
in set"
So rtrim("center_out_opto", "_opto") returns
"center_ou"
because "u" is not in the set {o, p, t, _} but all the characters after
33 matches
Mail list logo
