beulah prasanthi wrote:
> Can i insert all the data into all the tables(multiple tables) with
> a single trip to the database,by creating rules/triggers
This is not a bug. Please repost to another list; perhaps
pgsql-general.
When you re-post, you may want to provide more detail about the
p
yua ** wrote:
> What kind of information shall, I geve you
There are some good guidelines here:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
"Jodi Escalante" wrote:
> INSERT INTO assessment (id, created, taken, current_weight, note,
> assessment_type, stay_id, contact_id, estimated_discharge_date,
> cond_chf, cond_pulm_heart, cond_endocrine_other, cond_skin_temp,
> ) VALUES ( 50, 2008-01-11 15:06:40.257000 -07:00:00,
> 2008-01-11
Murali Mohan Nareddy wrote:
> Do any of the problems I am facing are fixed in a recent release
> so that I can upgrade to that release?
You're taking a big risk if you don't update, even though your
immediate problems seem to be caused by the AV software. To view
the bugs which have been fixe
"Murali" wrote:
> PostgreSQL version: 8.0.6
> Operating system: Windows Server 2003 Standard 32 Bit
> Description:Postgres hangs / crashes every day
You do realize that Windows is not a supported platform for any
release less than 8.2?
http://wiki.postgresql.org/wiki/PostgreSQL_Rel
Tom Lane wrote:
> "Kevin Grittner" writes:
>> This looks like another situation where we're running into
>> trouble because of non-standard behavior when people might be
>> expecting something consistent with other products and the
>> explicit la
Tom Lane wrote:
> What's the data type of the value being compared to? I get, for
> instance,
>
> postgres=# select substr('ab '::char(4), 1, 4) = 'ab '::char(4);
> ?column?
> --
> t
> (1 row)
This looks like another situation where we're running into trouble
because of non-stan
beulah prasanthi wrote:
This is very unlikely to be a PostgreSQL bug. Another list would
have been more appropriate.
> Error : could not open server file C:\\My Pictures\\sample.jpg
> No such file or directory
Anyway, do you have standard_conforming_strings turned on?
-Kevin
--
Sent vi
Craig Ringer wrote:
> Greg Stark wrote:
>> Ankit Kumar wrote:
>>> Thanks for your response. Hibernate works well when I change the
>>> DB to SQL server but somehow the moment I point to Postgresql it
>>> start generating OutOfMemory. Is there some configuration at DB
>>> end to ensure it starts us
"Chris Travers" wrote:
> I am noticing that that a failed database connection results in an
> unusable SQLSTATE in libpq, and a very different SQLSTATE than the
> backend registers.
Well, if the client fails to connect to the server, I'm not sure how
the server could communicate its SQLSTATE t
postgres bee wrote:
> insertion time is increasing as the data in the table is growing.
You have given no indication that there is a bug. Please re-post to
the performance list, but first you should read these pages (both
referenced in the description of the performance list):
http://wiki.p
"Kevin Grittner" wrote:
> There is an understandable tendency of those who work deep in the
> guts of the PostgreSQL software, making all this custom type code
> work,
I mangled that sentence worse than usual. The tendency is to see
the PostgreSQL behavior as natura
"Wagner, Kurt" wrote:
> when writing a character constant elsewhere
> then at first it is interpreted as character constant - right?
> then it is casted to the desired type
No. It was confusing for me, too; but the PostgreSQL behavior is to
treat what the standard calls a as being
of type U
Tom Lane wrote:
> Sorry about that --- I had confused this case with that of a bare
> NULL literal, which Postgres treats the same as an unadorned
> string literal for type determination purposes. You're right that
> the spec treats them differently. This is feasible for the spec's
> purposes
Craig Ringer wrote:
> On 3/12/2009 12:35 AM, Tom Lane wrote:
>> You really ought to cast the 'I' to some specific type.
>
> It's usually neatest to do this by just explicitly identifying
> the intended type in the first place, eg:
>
>
> SELECT firmnr,
> werknr,
>
"Amaya Gamarra" wrote:
> PostgreSQL version: 8.1.11
> We've got a Slony-I cluster over 2 postgres 8.1.11 servers.
> I join the pgsql.conf file.
> logging_collector = on
That option (and others) are not present in 8.1.
Either that's not your version or it's not your postgresql.conf file
takiguchi wrote:
> public void testConnection() {
>Connection con = dataSource.getConnection(); // get a connection
> from pool (If DB server restarted, invalid connection will be
> returned)
>boolean valid = true;
>try {
>// execute some DMLs...
>con.commit();
>}
takiguchi wrote:
> This is a problem of connection pooling, not of transaction.
>
> public void testConnection() {
>Connection con = dataSource.getConnection(); // get a connection
> from pool (If DB server restarted, invalid connection will be
> returned)
>boolean valid = true;
>tr
wrote:
> If PostgreSQL server is restarted, old Connection pooled in
> Application server's ConnectionPool cannot connect to DB.
> That's OK.
> But, I can call rollback() on old Connection and it throws no
> exception.
Hmmm What problem are you having? The transaction would have
been r
Robert Haas wrote:
> UUIDs throw away 6 bits?
http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_4_.28random.29
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
> Alternatively, do the postmaster support and make the
> presumably-minor pg_ctl mods to use it, and then a standalone
> pg_ping utility could come later. I'm not sure how big the utility
> would be, but surely bigger than the delta in pg_ctl.
Bigger than the delta for *just
Tom Lane wrote:
> I was envisioning just using PostmasterRandom() (after initializing
> the seed from time(NULL) as we do now). I don't think we need a
> super-wide random number.
Fine with me. Just that and CanAcceptConnections in the response?
It seems like pg_ping (client utility and re
Robert Haas wrote:
> Well, then Tom's idea of using a random number seems pretty solid no
> matter how you slice it. Maybe a UUID.
A random number is looking like the best option. I'm not sure why I'd
want to generate a perfectly good 128 bit random number and then throw
away six of the bits
Pedro Gimeno wrote:
> Tom Lane wrote:
>
>> This could be addressed by having the postmaster report its $PGDATA
>> value in the pg_ping response, but I would be against that on
>> security grounds. We don't let nonprivileged users know where
>> PGDATA is, why would we make the information availab
Tom Lane wrote:
> I'm not sure whether we'd want to provide a function within libpq
> for this, or just code it in pg_ctl.
I'm inclined to think there would be value to a pg_ping utility to
support automated monitoring by unprivileged users on other boxes.
That both suggests libpq as the locat
Tom Lane wrote:
> [ thinks... ] Maybe we could have the postmaster generate a random
> number at start and include that in both the postmaster.ports file
> and its pg_ping responses. That would have a substantially lower
> collision probability than PID, if the number generation process
> were
Tom Lane wrote:
> I would rather see us implement the hypothetical pg_ping protocol
> and remember to include the postmaster's PID in the response. One
> of the worst misfeatures of pg_ctl is the need to be able to
> authenticate itself to the postmaster, and having it rely on being
> able to a
"Kevin Grittner" wrote:
> I neglected that point in my recently proposed LSB conforming script
Hmmm... On review, I see that I assumed that the -w switch on pg_ctl
start would cover this. I see that the problem is that this uses psql
to connect to the specified port. Besides
Tom Lane wrote:
> Well, it's arguably a start-script bug
OK.
> While mulling that it occurred to me that some additional output
> from the postmaster would help to solve another thing that's an
> acknowledged shortcoming of pg_ctl, namely that it can't parse
> postgresql.conf to find out whe
"Gerhard Leykam" wrote:
> I am using a start script to set up my PostgreSQL database: it runs
> initdb, if not done yet, starts the instance with pg_ctl start and
> checks everything is fine by pg_ctl status.
>
> If there is another PostgreSQL database on the same machine
> listening to the sa
Sean Hsien wrote:
> 2009/10/15 Kevin Grittner :
>> what are the OS and Java versions on the client side?
> I'm using CentOS 5.2 64-bits with postgres 8.1.11 + java 6u16, and
> Windows Vista 32-bits with postgres 8.4.1 + java 6u13.
So the Java code is running on the
"Vladimir Kokovic" wrote:
> For ALTER TABLE ADD CONSTRAINT documentation says:
> ADD table_constraint
> This form adds a new constraint to a table using the same syntax
< as CREATE TABLE.
Which is specified as UNIQUE ( column_name [, ... ] )
> But if expression is used
it's not sup
Sean Hsien wrote:
> using the latest JDBC driver type 4.
> I have a nullable integer column in one of my tables. When I'm
> updating the column in 8.4 Windows with value 0, it stays as null,
> but on the Linux 8.1 it will try to update it with the value 0.
Could you post a small, self-contai
Tom Lane wrote:
> ... Actually, I just noticed that there *is* a bug here:
>
> regression=# select '1' /* foo
> regression*# */
> regression-# '2';
> ERROR: syntax error at or near "'2'"
> LINE 3: '2';
> ^
> regression=#
>
> The above should be accepted, but it isn't.
It works with
"Walter Mesz" wrote:
> my problem is that this select into does not throw a NO_DATA_FOUND
> if my select involves a max(). I did not see this behaviour
> documented anywhere and could not find it in a reasonable time at
> google.
> SELECT max(tanum)
>INTO STRICT x
>FRO
"Geoff Tolley" wrote:
> postgres=# SELECT 'hello' WHERE '1' IN ('1'
> postgres(# '2');
Per the SQL standard, that is the same as
SELECT 'hello' WHERE '1' IN ('12');
I believe that's intended to make it easier to code long string
literals without creating query text which has long line len
Sam Mason wrote:
> the deeper problem seems to be that the table was created as:
>
> create table test (a tstdom);
>
> and not as:
>
> create table test (a tstdom not null);
Given that tstdom is declared as NOT NULL, is this difference
considered a *feature* or is it an implementation q
Tom Lane wrote:
> I'm not certain what you're trying to say, but the above is complete
> nonsense ...
Ah, so it is. I thought someone up-thread said that in this case it
wound up as bpchar; but I see that's not so:
test=# select pg_typeof((select case when true then 'xxx' else
'a'::char(1)
Sam Mason wrote:
> I fail to see how an error isn't the right thing; if we try with
> some other types let see if you think any of these should succeed.
>
> SELECT CASE WHEN TRUE THEN text 'xxx' ELSE 0 END;
> SELECT CASE WHEN TRUE THEN text 'xxx' ELSE TRUE END;
> SELECT CASE WHEN TRUE TH
Sam Mason wrote:
> you seem to be wanting in-memory representations of "string like
> types" to all use the same representation and only use the actual
> types when saving to/from disk.
Doing so when actually assigning to *something* of the more specific
type would probably be better. In my v
Tom Lane wrote:
> I certainly don't want to have "char" emulate the misbegotten
> decision to have explicit and implicit coercions behave differently.
> So it looks to me like the argument to make "char" work like char(1)
> doesn't actually help us much to decide if an error should be thrown
>
Tom Lane wrote:
> One other point worth making is that we don't always consider SQL
> compliance to be a hard requirement that trumps every other
> consideration.
Point noted.
> An example is case-folding of identifiers; it's been pretty well
> agreed that between readability and backwards-c
Tom Lane wrote:
> In a formal sense the type information available is the same, ie,
> none.
Well, in the sense that an international standard is formal, there is
a formal difference, in that one has no type information and the other
is a character string. However:
> The argument that SQL sa
Tom Lane wrote:
> "Kevin Grittner" writes:
>> go with the suggestion of having a character string literal type,
>> and change the semantics such that if there is a valid
>> interpretation of the statement with the character string literal
>> taken as text,
Sam Mason wrote:
> On Wed, Sep 02, 2009 at 02:59:54PM -0500, Kevin Grittner wrote:
>> Sam Mason wrote:
>> > CREATE VIEW v (c) AS
>> > SELECT NULL;
>> >
>> > PG allows it, but the resulting view seems somewhat unusable.
>>
>>
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Yep. I don't know if it would be remotely feasible, but the
>> implementation which seems like it would be "standard-safe" but
>> still give reasonable concessions to those wanting to skip the
>>
Sam Mason wrote:
> CREATE VIEW v (c) AS
> SELECT NULL;
>
> PG allows it, but the resulting view seems somewhat unusable.
I'm not sure whether the only place the standard doesn't require a
cast is on assignment, but this is one place that the standard clearly
does require a cast, and I'm
Sam Mason wrote:
> I'd always thought '2001-01-01' was a valid date literal, seems the
> standard has required it to be prefixed by DATE at least back to
> SQL92.
Yep. I don't know if it would be remotely feasible, but the
implementation which seems like it would be "standard-safe" but still
Tom Lane wrote:
> "Kevin Grittner" writes:
>> And I'm not even sure how I'd explain the rules to someone.
>
> text is preferred to "char" which is preferred to unknown.
>
> This particular example would be less confusing if 'Hey'::&
"Kevin Grittner" wrote:
> Well, unless things have changed in recent versions of the standard
> and I've missed the change, a series of characters enclosed in
> apostrophes is what the standard calls a "character string literal"
> and defines it to be be rel
Sam Mason wrote:
> you were requiring the types of literals that happened to be
> enclosed in quotes to have their type ascribed, so why not the NULL
> literal?
Well, unless things have changed in recent versions of the standard
and I've missed the change, a series of characters enclosed in
a
I wrote:
> A simple, self-contained example derived from the OP:
>
> test=# create table t (c "char");
> CREATE TABLE
> test=# insert into t values ('a');
> INSERT 0 1
> test=# select case when c = 'a' then 'Hey' else c end from t;
> c
> ---
> H
> (1 row)
>
> test=# select case when c = 'a'
Tom Lane wrote:
> "Kevin Grittner" writes:
>> What I'm most concerned about are the corner cases where strict
>> typing would give one non-error result and the inferred typing
>> results in an error or a different result from the strict typing.
>> I&
Sam Mason wrote:
> If we did follow Kevin's request directly, should we also be
> specifying the type of NULL?
I don't *think* the SQL standard requires that, and barring that I
don't see any compelling reason to type NULL. One problem I do see
with the current scheme, however, is that NULL *
Tom Lane wrote:
> It's interesting that you want to go in 100% the opposite direction
> from Kevin, who seems to want to eliminate type inference
> altogether. Maybe our current compromise isn't too bad, if it makes
> everybody unhappy in opposite directions ;-)
Well, it's probably worth noti
Jeff Davis wrote:
> I disagree that using implicit casts to make up for a lack of an
> "unknown" type will improve matters
I certainly never meant to imply that additional implicit casts should
be added. I apologize for not being more clear about that.
Thanks again for helping fill in the b
Tom Lane wrote:
> "Kevin Grittner" writes:
>> No, that's not it. I'm wondering why it isn't treated as text.
>> Period. Full stop. Nothing to infer.
>
> Because then we would have to provide implicit casts from text to
> everything else,
Jeff Davis wrote:
> On Tue, 2009-09-01 at 13:49 -0500, Kevin Grittner wrote:
>> I figured that; I'm just trying to understand what seems to me like
>> an odd wart on the type system. I figure I must be missing
>> something important, so I'd kinda like to f
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> Joseph Shraibman writes:
>>>> So the type of what is in the ELSE clause determines the type of
>>>> the output?
>>>
>>> If all the other branches are unkno
Tom Lane wrote:
> Joseph Shraibman writes:
>> So the type of what is in the ELSE clause determines the type of
>> the output?
>
> If all the other branches are unknown literals, yes.
What's the best place to look to get a handle on what the benefits are
of treating character string literals as
Joseph Shraibman wrote:
> Kevin Grittner wrote:
>> Did you try putting quotes inside the apostrophes?:
>>
> No, I didn't. I didn't know I could do that.
That's generally true in recent versions. (Try the -t option on
pg_dump for the first place I ra
"Joseph Shraibman" wrote:
> The pg_relation_size(text) method cannot determine the size of a
> relation that has capital letters.
Did you try putting quotes inside the apostrophes?:
SELECT pg_relation_size('"MixedCaseRelation"');
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
Merlin Moncure wrote:
> This leads to some very weird behaviors, for example 'coalesce(foo,
> something)' and 'case when foo is null then something else foo end'
> can give different answers.
Quite apart from the issue you're pursuing, this is another example of
how the COALESCE predicate in P
"James Bardin" wrote:
> Is this currently possible, or do I have to send a full file-level
> backup to sync the ex-master server with the new master?
I believe you have to get a new base backup from the new master to the
new standby. Consider rsync, which might do it *really* fast if not
much
"walkerlacombe" wrote:
> PostgreSQL version: 8.0
> Operating system: vista home premium
While Alvaro has very kindly added something to the "Frequently Asked
Questions" (FAQ) page which might help you:
http://wiki.postgresql.org/wiki/FAQ#I_lost_the_database_password.__What_can_I_do_to_reco
"Kevin Grittner" wrote:
> The withouttimezone column sees the literal in your local time and
s/withouttimezone/withtimezone/
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"William Crawford" wrote:
> set time zone 'US/Eastern';
> select
> timestamp '2009-01-01',
> timestamp '2009-01-01' at time zone 'US/Pacific'
>as withouttimezone,
> timestamp with time zone '2009-01-01' at time zone 'US/Pacific'
>
"Matthias" wrote:
> It is about when using a upper-boundary timestamp. The value of
> -12-31 23:59:59.99 is sometimes used to indicate an infinite
> validity.
One other thought -- using a "magic value" for something like this is
usually a bad idea. NULL indicates the absence of a valu
"Matthias" wrote:
> I noticed an unusual (and from my point of view inconsistent)
> rounding of a timestamp:
What do you get when you run?:
show integer_datetimes;
If it is off, which is probably the default for your distribution
under 8.3.X, timestamps are floating point (approximate) val
Mathieu Fenniak wrote:
> I entered a bug report yesterday through the PostgreSQL web site
> that was assigned bug ID 4906. However, looking through the
> pgsql-bugs list, I don't see the posting I entered -- is it possible
> this bug report disappeared into the void? Should I resubmit it?
A
David Kerr wrote:
> I'm working on my management to allow me to roll my own PG and get a
> 3rd party support.
FWIW, we're a SLES shop, and we've found it best to build our own.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
htt
Tom Lane wrote:
> Or you could turn on standard_conforming_strings if you'd prefer not
> to deal with escapes.
That doesn't help with this, because of the separate pgpgsql parser:
ccdev=> select version();
version
--
"Luis angel camacho" wrote:
> the service can't start
How are you starting it?
What error messages, if any, do you see? (Copy/paste if possible;
failing that, please give exact text.)
What is in the logs from around the time of the failed attempt to
start the service?
-Kevin
--
Sent
Tom Lane wrote:
> Look under "computed fields" in the index ... looks like it's
> towards the bottom of 34.4.2 in the 8.3 docs.
> http://www.postgresql.org/docs/8.3/static/xfunc-sql.html#AEN40267
>
> I had thought it was mentioned somewhere in chapter 4 as well, but
> am not seeing it there ri
Tom Lane wrote:
> Per the fine manual, sp.count is another way of writing count(sp).
Wow, that seems a horrid kludge. Is the standard responsible for that
one, or is it a PostgreSQL extension?
Could you point me at where in the fine manual this is covered? I've
never stumbled across it in
David Leppik wrote:
> Never mind. Turns out the bug was in our own code (read: me,
> personally, being stupid) to convert a java.sql.Timestamp to
> java.sql.Date. Why it works at all in MySQL... I don't even want
> to know.
java.sql.Date or java.util.Date? (You don't show your imports,
Tom Lane wrote:
> Robert Haas writes:
>> This seems like the only option that will produce correct answers,
>> so it gets my vote. How much is the performance penalty for
>> materializing the tuplestore? I'm inclined to think that whatever
>> it is, you just have to pay it if you ask for a WIT
>>> Tom Lane wrote:
> but I bet it's the change in the default integer_datetimes setting
> that is the relevant difference.
Confirmed.
cc=> select '1999-08-06 00:12:57.99900Z'::timestamptz;
ERROR: date/time field value out of range: "1999-08-06
00:12:57.99900Z"
cc=> select version();
>>> CK Leung wrote:
> the result : select * from tt order by item_code;
>
> item_code
> --
> V
> .V
> V.
> VA.AAA
> V.B
> V
> (V
> (V)
> (V)B.BBB
> (VB)BBB
> V.
> V)
> VCCC
> (13 rows)
>
> the sort sequence like ignore t
"Ted Holzman" wrote:
> AGGREGATE functions don't appear to respond to LIMIT clauses.
Not a bug. LIMIT affects how many rows are in the result set the
LIMIT qualifies.
> select sum(generate_series)
> from generate_series(1,10) limit 3;
> sum
> -
> 55
> (1 row)
>
> I was expecting
Wayne Conrad wrote:
> the database started getting slow over time.
As Alvaro pointed out, this can happen if your fsm configuration
doesn't allow enough space for a normal VACUUM to keep track of all
the free space. Since you're running VACUUM with the VERBOSE option,
be sure to capture the ou
>>> "Wayne Conrad" wrote:
> "VACUUM FULL ANALYZE VERBOSE" on a "deadlocks"
> "VACUUM VERBOSE ANALYZE" (without the "FULL") does not
You do realize that FULL should not be part of normal maintenance,
right? It is sometimes useful to recover from table bloat when normal
maintenance fails. A
>>> Kyle Butt wrote:
> select (bug_function()).*;
> psql:sql/bug_example.sql:32: NOTICE: in bug_function
> psql:sql/bug_example.sql:32: NOTICE: in bug_function
> psql:sql/bug_example.sql:32: NOTICE: in bug_function
> psql:sql/bug_example.sql:32: NOTICE: in bug_function
> psql:sql/bug_examp
>>> wrote:
> We have a lot of test databases with multiple db_owners, but very few
> superusers, and table_owners switch all the time.
A quick, untested idea:
Create a table_owner role.
Create your users with NOINHERIT and GRANT table_owner to them as
appropriate.
REVOKE CREATE ON SCHEMA
>>> "Nitin" wrote:
> Is the server running on host "PostgreSQL" and
> accepting TCP/IP connections on port 5432?
This is very unlikely to be a bug, so a better list would have been
general or admin.
You probably haven't configured connections properly for your intended
use. Start with this p
>>> <[EMAIL PROTECTED]> wrote:
> installing postgreSQL it brings up an error message that last part of
> the install saying "could not create user name" and then some other
> stuff about how this may affect post-install operations.
People will have a hard time offering useful suggestions w
>>> Francisco Olarte Sanz <[EMAIL PROTECTED]> wrote:
> Similarly nearly nobody bothers
> to fclose() stdin/out/err
On that one, maybe it should be done more often. In writing
pg_clearxlogtail I found that closing stdout improved performance
markedly. This was a filter piping from disk into gz
>>> On Fri, Jul 18, 2008 at 2:35 PM, in message
<[EMAIL PROTECTED]>,
Sanjay Rajdev <[EMAIL PROTECTED]> wrote:
> Thanks for the thought, I think that this can be the problem, as
earlier
> there was no indexing on the column, but 2 days back we added index
on 5 of
> columns in the table and "so
Resend attempt -- previous attempt rejected for size. I have NOT
attached the PostgreSQL log (110kB) to this attempt.
--
We had an odd problem the other night which appears to be a rare but
serious bug in PostgreSQL 8.2.4. I don't see anything in the release
notes to indicate that thi
>>> "Bob Thompson" <[EMAIL PROTECTED]> wrote:
> What we have is an apparent security problem on your computer.
Perhaps
> problem isn't the correct word, but security is so tight on your
computer
> that the program cannot do a network loopback to itself on IP
address
> 127.0.0.1.
Exactly wha
>>> "Wojciech Tylek" <[EMAIL PROTECTED]> wrote:
> Why the query like:
>
> select * from b where a_id in (select a_id from a where b_id in
(10,20));
>
> does not return error?
> The table "a" does not have b_id!
This is a correlated subquery. A previous list post on the topic:
http://arch
>>> D Galen <[EMAIL PROTECTED]> wrote:
> Server will load & I see the server processes loaded but none of
> them have any open ports.
Please show us your listen_addresses line from postgresql.conf.
Are you trying to connect to localhost, 127.0.0.1, or some other IP
address?
If W2K supports
>>> On Fri, Apr 25, 2008 at 11:59 AM, in message
<[EMAIL PROTECTED]>,
valgog
<[EMAIL PROTECTED]> wrote:
> On Apr 24, 12:28 pm, [EMAIL PROTECTED] (Kris Jurka) wrote:
>> On Wed, 23 Apr 2008, valgog wrote:
>> > Is it possible to implement the setStatementTimeout() as somethig
>> > like:
>>
>> > s = c
>>> On Wed, Mar 26, 2008 at 9:23 PM, in message
<[EMAIL PROTECTED]>, Taiki Yamaguchi
<[EMAIL PROTECTED]> wrote:
> 8.3.0
> ==
> yamaguti=# create table t1 (i int, j int primary key);
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "t1_pkey" for tabl
>>> On Wed, Jan 30, 2008 at 12:33 PM, in message
<[EMAIL PROTECTED]>, "David Dunwoody"
<[EMAIL PROTECTED]> wrote:
> pg_dump -v -T=b test > /dev/null
Get rid of the equals sign. Not used for single-letter form.
pg_dump -v -T b test > /dev/null
-Kevin
---(end
>>> On Fri, Jan 4, 2008 at 8:00 AM, in message
<[EMAIL PROTECTED]>, "Michael Orozco"
<[EMAIL PROTECTED]> wrote:
> Someone tell me now to get off this list
From the main web page at:
http://www.postgresql.org/
There is a link to "Mailing Lists". If you take that, you will see, up at the
to
>>> On Thu, Dec 27, 2007 at 4:22 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> To the extent that you do believe the spec, there are more problems with
> our precedence ru
>>> On Mon, Dec 17, 2007 at 1:58 PM, in message
<[EMAIL PROTECTED]>, "Pedro Gimeno"
<[EMAIL PROTECTED]> wrote:
> Description:Nonstandard precedence for comparison operators
> The operators <>, <= and >= are expected to have the same precedence as =, <
> and >, but according to the doc
>>> On Fri, Nov 30, 2007 at 4:13 AM, in message
<[EMAIL PROTECTED]>, Gregory Stark <[EMAIL PROTECTED]>
wrote:
> "Mike C." <[EMAIL PROTECTED]> writes:
>
>> I don't know if this is either a wording change, or a more serious bug, but
>> when I do a pg_restore (from a 8.1.9 setup) to a fresh 8.3beta
>>> On Tue, Nov 20, 2007 at 3:47 PM, in message
<[EMAIL PROTECTED]>, Cade Cairns <[EMAIL PROTECTED]>
wrote:
> On 20-Nov-07, at 2:42 PM, Heikki Linnakangas wrote:
>>
>> http://www.postgresql.org/docs/8.1/interactive/datatype-bit.html
>>
>> "Note: If one explicitly casts a bit-string value to bit(
401 - 500 of 533 matches
Mail list logo
