Hi Doug.
Many users are haphazard in their approach until
the machine fails and then they expect to be pulled from the poo.
Done it too many times. I now will get the application to enforce an
additional integrity check. It must be backed up or else! Seems futile
to put all the effort into a
We use the instructions at http://www.keyvaluecoding.com
Works great.
Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED]
ClickSpace Interactive Inc.
Suite L100, 239 - 10th Ave. SE
Calgary, AB T2G 0V9
http://www.
On 2006-02-05, Niederland <[EMAIL PROTECTED]> wrote:
> I am using postgres 8.1.2 on a windows computer.
> My postgres.config has:
> add_missing_from = off
>
> In the following example, the first update sets value for v1 in table
> t1 to 4 for all rows.
> Just for my sanity, I checked the null condi
I am using postgres 8.1.2 on a windows computer.
My postgres.config has:
add_missing_from = off
In the following example, the first update sets value for v1 in table
t1 to 4 for all rows.
Just for my sanity, I checked the null condition in the second update,
and this
does not update any of the row
On Fri, Feb 03, 2006 at 12:13:15AM -0500, Tom Lane wrote:
> I think you're getting bit by a standard beginner gotcha: commenting out
> an entry in postgresql.conf will not change the state of a running
> postmaster. (A comment is a no-op, eh?) You need to put in a
> non-comment entry that sets th
On Sun, Feb 05, 2006 at 07:43:47PM +0100, Joachim Wieland wrote:
> I propose to change it on the grounds that:
>
> - other unix daemons reset their values to defaults before reading
>conffiles
To be fair, most daemons can do this by simply re-execing themselves,
something we don't have the l
Joachim Wieland <[EMAIL PROTECTED]> writes:
>> There's been various discussions in the past about making this behavior
>> less non-intuitive, but nothing's been settled on ...
> So what about deciding now that it should be changed. What are the reasons
> for why it should be kept as it is?
1. Bac
On Sun, Feb 05, 2006 at 07:59:06PM +0100, Martijn van Oosterhout wrote:
> On Sun, Feb 05, 2006 at 07:43:47PM +0100, Joachim Wieland wrote:
> > I propose to change it on the grounds that:
> > - other unix daemons reset their values to defaults before reading
> >conffiles
> But the biggest iss
On Sun, Feb 05, 2006 at 02:37:53PM -0500, Tom Lane wrote:
> Joachim Wieland <[EMAIL PROTECTED]> writes:
> >> There's been various discussions in the past about making this behavior
> >> less non-intuitive, but nothing's been settled on ...
> > So what about deciding now that it should be changed.
Joachim Wieland wrote:
> > > - other unix daemons reset their values to defaults before
> > > reading conffiles
> >
> > Examples please?
>
> inetd, Apache, squid, exim, postfix, a famous database starting with
> m...
cron, syslog, ntp, ssh
--
Peter Eisentraut
http://developer.postgresql.org/~pe
Hi,
I've never noticed before, but I don't manage to do a "SELECT" with
conditions on REAL columns !!
For example, the following command always returns 0 row, even if rows
with myreal=10.5 do exist :
SELECT * FROM mytable WHERE myreal=10.5;
Where am I wrong ?!
Thank you in advance,
Phi
Hi PgSQL Users,
I need to define an array of composite types namely “rc_list” in
the following context.
CREATE TYPE
gui_ep_rc_action_type AS (
route_action
VARCHAR,
reject_code
VARCHAR,
da_cdpn_strip
INT2,
da_cdpn_prefix
VARCHAR,
da_cdpn_replace
VARCHAR,
da_c
On Sun, Feb 05, 2006 at 09:56:17PM +0100, Peter Eisentraut wrote:
> > inetd, Apache, squid, exim, postfix, a famous database starting with
> > m...
>
> cron, syslog, ntp, ssh
All of those work either by re-execing themselves, if they implement a
reload at all. Except mysql which only appears to a
On Feb 6, 2006, at 7:30 , Philippe Ferreira wrote:
For example, the following command always returns 0 row, even if
rows with myreal=10.5 do exist :
SELECT * FROM mytable WHERE myreal=10.5;
Where am I wrong ?!
Without seeing a more complete example, it's hard to say. It works
for me
On Feb 5, 2006, at 2:30 PM, Philippe Ferreira wrote:
Hi,
I've never noticed before, but I don't manage to do a "SELECT" with
conditions on REAL columns !!
For example, the following command always returns 0 row, even if
rows with myreal=10.5 do exist :
SELECT * FROM mytable WHERE my
Hey,
I was puzzling over how to make sure a database has plpgsql
installed in it in pure SQL. I felt this would simplify the schema's
installation process since calling of extra binaries is no longer
neccessary. Here's what I came up with:
CREATE OR REPLACE FUNCTION make_plpgsql () RETUR
TODO has:
o %Allow commenting of variables in postgresql.conf to restore them
to defaults
Currently, if a variable is commented out, it keeps the
previous uncommented value until a server restarted.
hi,
i have acidentally deleted rows from a table. is it
possible to recover them
i have read somewhere that the source code can be
modified to recover them, can some one tell me the way so that it can be
done.
Please note that i have no back up of the data, is
it not possible to recover
hello!
I am trying to access a postgresql server though a tightly configured
firewall, and I'd like to know the source port range is that postgresql
clients use to access the database.
it seems the source port starts at the 5 range. Is there an upper limit or
does it randomly pick any non-
"John Tulodziecki" <[EMAIL PROTECTED]> writes:
> I need to define an array of composite types
Sorry, this isn't supported at the moment ... and AFAIR no one
is working on it.
regards, tom lane
---(end of broadcast)---
TIP 3:
i am trying to do :
pg_dump -f op.tar -F t database_name
then i do
dropdb database_name
and then i do pg_restore op.tar
and when i do psql database_name
it says database does not exist.
where am i going wrong?
thanks,
regards
Surabhi
Matthew Smith <[EMAIL PROTECTED]> writes:
> I am trying to access a postgresql server though a tightly configured
> firewall, and I'd like to know the source port range is that postgresql
> clients use to access the database.
You seem to be under the misimpression that Postgres might have
someth
Hello Tom,
Thanks for the reply. So in other words, the postgres clients do not use a
specific range for the source port (as a specific decision by the developers,
or as written down in a given spec), but rather relies on the operating
system's socket implementation to assign a source port?
So
You may be able to recover them, but you could make things worser if
you do not do it correctly.
http://archives.postgresql.org/pgsql-patches/2005-02/msg00126.php
http://archives.postgresql.org/pgsql-general/2006-02/msg00091.php
On 2/6/06, surabhi.ahuja <[EMAIL PROTECTED]> wrote:
> hi,
>
> i ha
Did you check if your pg_restore was successful?
I think you need to include the following option while using pg_dump &
pg_restore
-C, --create include/issue commands to create database
On 2/6/06, surabhi.ahuja <[EMAIL PROTECTED]> wrote:
> i am trying to do :
>
> pg_dump -f op.tar
Basing on the way you did the pg_dump (without the -C option), I think you
should have created the database before you performed the pg_restore,
You can see some examples of database backup/restore in this page:
http://nediam.com.mx/en/tips/backups_pgsql.php
Regards,
Javier
On Mon, 6
26 matches
Mail list logo
