Hello,
We have a very strange problem when restoring a database on Windows XP.
The PG version is 8.1.10
The backup was made with the pg_dump on the same machine.
pg_restore -F c -h localhost -p 5432 -U postgres -d "configV3" -v
"c:\Share\POSTGRES.backup"
pg_restore: connecting to database for re
> Tom Tom wrote:
> > Hello,
> >
> > We have a very strange problem when restoring a database on Windows XP.
> > The PG version is 8.1.10
> > The backup was made with the pg_dump on the same machine.
> >
> > pg_restore -F c -h localhost -p
Brian Maguire wrote:
> We need to restore one table from a backup. What is the proper way to do
> this?
>
> Our backup command looks like this:
>
> pg_dump -C -Fc -S postgresql mydatabase > today.backup.sqlc
>
> I am using PostgreSQL 8.1.
>
> --
> Sent via pgsql-general mailing list (pgsql-
Magnus Hagander wrote:
> Tom Tom wrote:
> >> Tom Tom wrote:
> >>> Hello,
> >>>
> >>> We have a very strange problem when restoring a database on Windows XP.
> >>> The PG version is 8.1.10
> >>> The backup was made with the
Magnus Hagander wrote:
> Tom Tom wrote:
> > Magnus Hagander wrote:
> >> Tom Tom wrote:
> >>>> Tom Tom wrote:
> >>>>> Hello,
> >>>>>
> >>>>> We have a very strange problem when restoring a database on Windows X
Magnus Hagander wrote:
> Tom Lane wrote:
> > I wrote:
> >> Of course the larger issue is why it's failing --- 150MB doesn't seem
> >> like that much for a modern machine. I suspect that PQerrorMessage()
> >> would tell us something useful, but pg_
Magnus Hagander wrote
> Tom Lane wrote:
> > =?us-ascii?Q?Tom=20Tom?= <[EMAIL PROTECTED]> writes:
> >> Magnus Hagander wrote:
> >>> Attached is a pg_restore.exe off CVS tip today, which should include the
> >>> patch. Please try this one.
&
Magnus Hagander wrote
> Tom Tom wrote:
> > Magnus Hagander wrote
> >> Tom Lane wrote:
> >>> =?us-ascii?Q?Tom=20Tom?= <[EMAIL PROTECTED]> writes:
> >>>> Magnus Hagander wrote:
> >>>>> Attached is a pg_restore.exe off CVS t
Magnus Hagander wrote:
> >>> 2.Our production PG version is 8.1.3. For some reasons it is not possible
> to
> >> upgrade to the LATEST;
> >>> I tested the libpq also on this version and it worked. Is it OK? I mean,
> did
> >> it worked by chance or the library
> >>> API & contracts didn't change b
I found a problem with my application which only occurs under high loads
(isn't that always the case?).
snippets of perl...
insert into tokens (token)
select values.token
from (values TOKEN_LIST_STRING) as values(token)
left outer join tokens t using (token)
where t.token_idx is null
$sql =~ s/
On 6/14/2007, "Gregory Stark" <[EMAIL PROTECTED]> wrote:
>
>
><[EMAIL PROTECTED]> writes:
>
>> But everyone once in a long while it seems that I hit simultaneaous
>> execute() statements that deadlock on the insertion.
>
>What version of Postgres is this and do you have any foreign key constraint
On 6/14/2007, "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] wrote:
>> I found a problem with my application which only occurs under high loads
>> (isn't that always the case?).
>>
>> snippets of perl...
>>
>> insert into tokens (token)
>> select values.token
>> from (values TOKE
l or on how to
fix issues with my 3d attempt are appreciated.
Tom
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
For what may be really strange reasons I am trying to store emails
into a database table. The idea is to take the entire original
message and store it into a table with two columns, an serial primary
key column and a column for the message.
Originally I thought I would just use column type
Might I suggest you consider using dbmail as an IMAP server.
This indexing you speak of is exactly what it will do.
But the additional advantage with IMAP is that you can have multiple
clients attached to the same folders (especially useful if shared) or be
able to attach from multiple sources (
No.
Postgres does not represent an economic entity that can compete for $
$ with Oracle.
It's also not nearly as popular. And I mean that in a very pop-
culture way.
How long did it take Oracle to support Linux? Only when it became
"pop"ular to do so.
Who would they target anyways?
There
I'm running my database on a Pentium 2 with 450MHz CPU.
It runs dbmail and spamassassin's Bayes and has overhead available.
You'll find it works well enough for your database size.
As for being it overkill. I think you've answered your own questions:
I don't have to write as much code -- less bu
I'm wondering where the differences are in running two different
types of SQL statements.
Given ~300 tokens/words I can either run 1 sql statement with a large
list in a "WHERE foo IN (...300 tokens...)"
or I can run ~300 statements, one for each token.
In the first case, the SQL is not prep
iscuit')
for up to ~300 words
OR
SELECT bar FROM tokens WHERE foo = 'apple' up to ~300 times as a
prepared/cached SQL statements.
On Apr 6, 2007, at 9:10 AM, Oleg Bartunov wrote:
Tom,
have you seen contrib/intarray ?
Oleg
On Fri, 6 Apr 2007, tom wrote:
I'm wonderin
I've never seen this before.
Is this PG specific or generic SQL that I've never been exposed to?
On Apr 6, 2007, at 10:08 AM, Listmail wrote:
I have a choice of running:
SELECT bar FROM tokens WHERE foo IN
('apple','orange','biscuit') for up to ~300 words
OR
SELECT bar FROM tokens
at is in the right place on this email, but it's
the second ')' that's the problem.
On Apr 6, 2007, at 2:26 PM, Listmail wrote:
On Fri, 06 Apr 2007 18:45:15 +0200, Markus Schiltknecht
<[EMAIL PROTECTED]> wrote:
Hi,
tom wrote:
Initially it seems that the WHERE IN
OK, I can do some reading and such.
But first I will run pg_dump just in case...
On 4/10/2007, "Martijn van Oosterhout" wrote:
>On Tue, Apr 10, 2007 at 06:01:34AM -0400, Tom Allison wrote:
>> A while back I threw together a postgresql installation on a computer with
Is there a tutorial on this stuff?
I did check the Really Fine Manual and they said explain plans are
beyond the scope RTFM.
On Apr 22, 2007, at 10:36 AM, A. Kretschmer wrote:
am Sun, dem 22.04.2007, um 9:43:32 -0400 mailte Tom Allison
folgendes:
"Seq Scan on" - is this j
I have a math question and a benchmark question and I'm not sure how
to benchmark it.
What I'm trying to do is use pgsql as a bayes token store for a spam
filter I'm writing.
In doing this I have a data structure with index keys and two integer
fields 'h_msgs' and 's_msgs' for each token an
On 4/26/2007, "Chris" <[EMAIL PROTECTED]> wrote:
>tom wrote:
>
>> In pgsql I have to modify this a bit with 'cast (s_msgs as double
>> precision)' or 'cast(s_msgs as real)' in order to get floating point math.
>> ( cast(s_msgs as doubl
How do I pull a random sample of either 100 records or 5% of the
population of a table?
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On 5/24/2007, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
>Hi,
>
>First, I would advise never using " insert into xx values (y,x)" without
>explicitly naming the columns; same for select statements - never use
>select * (a table change can mess things up).
>
>By the way, I just noticed in the
Greets,
I'm trying to get my head around what the benefits to inheritance are.
Is the data duplicated or just referenced in the parent table? If it's
duplicated then the database size and bloat are an issue for me.
Another question I have is that say I have a parent table
st. )
Session halted.
..
I'd appreciate any and all solutions/hints (guesses even) as to where to
look to resolve/rectify this.
sincerely,
Tom
p. maybe that helps.
Maybe you could reduce the statistics targets for that table.
I think we've heard that the analyze functions for PostGIS data types are
memory hogs, too --- maybe it's worth inquiring about that on the postgis
mailing lists.
regards, tom lane
wambacher writes:
> Tom Lane-2 wrote
>> Maybe you could reduce the statistics targets for that table.
> don't understand what you mean. do you mean how often that table is
> autovacuumed? at the moment about once a day or once in two days, i think.
No, I mean the amount
at into pg_dumpall?
I feel no compulsion whatsoever to preserve any user-initiated changes
in template0 across an upgrade.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Perhaps pg_upgrade should deliberately ignore template0 regardless of
>> datallowconn? And/or we should hard-wire that into pg_dumpall?
> My thinking would be that pg_dumpall should be hard-wired for template0
nup of known-dead rows. But we were just
guessing at that over here.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ndard language for you. If not, maybe you don't want that job.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
quoting, it would get some cases wrong,
potentially creating security holes.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
be able to help much about that.
If you'd like additional advice, I'd recommend reviewing
https://wiki.postgresql.org/wiki/Slow_Query_Questions
and then taking the discussion to the pgsql-performance list.
regards, tom lane
--
Sent via pgsql-general mailing li
x27;t
scan all the partitions.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
output. You
can do
format('... AS %I ...', ..., column_label, ...)
and be confident that the label will be exactly what you've got in
column_label. This proposed change would break that for labels that
happen to already have double-quotes --- but who are we to say that
SQL code in an SCM repo, somewhere
outside the database. Postgres itself saves views as parse trees, so
there's no way it will ever remember whitespace or comments.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To mak
e that both
plans we've been shown are going to produce output sorted by actor.id.
Maybe that's happenstance, or maybe not.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
re
nontrivial effort to change it --- for example, there are several
early-exit cases that return the original array unmodified, and that would
be wrong if we were to adopt some other definition such as "force the
lower bound to 1".
regards, tom lane
--
Sent via pgs
Pavel Stehule writes:
> result of xmlagg is not valid xml.
Really? Either that's a bug, or it's declared wrong.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.p
ontain a regular DML
command. I'm pretty sure there is a hack in there that allows parameters
to be transmitted down through PREPARE or D.C. ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
7;s
expectable that the data distribution stats would be a bit different on
the two systems, but large differences that persist across multiple
ANALYZE attempts are unlikely. (Although ... you do have the
same default_statistics_target on both systems, no? Table-specific
statistics targets could
storage that's local to the backend running CREATE INDEX, and isn't
accessible to other processes at all.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
about what your
data is, what PG version you're using, etc.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
27;re you gonna return when there were no input rows? You won't be
able to distinguish "no input rows" from "first input row had a NULL".
Maybe you should rethink whatever activity you were wanting it for.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
n int, in 2038), so you
really don't want to be using it.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
free (6 chunks); 32 used
> 2015-04-01 14:23:27 EDT ERROR: out of memory
> 2015-04-01 14:23:27 EDT DETAIL: Failed on request of size 80.
> 2015-04-01 14:23:27 EDT STATEMENT: analyze verbose;
We need to see all of that memory map, not just the last six lines of it.
new.*
or some variant of that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
f what you've said here, though, I can
only suggest that you're looking for the problem in the wrong place.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Looks to me like a bug (ie, the code seems to think this is a can't-happen
case). Don't suppose you could supply sample data that triggers this?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscr
ou define
for "variant" is going to be a loaded gun just waiting to shoot your foot
off, if you make all those casts implicit.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Jim Nasby writes:
> On 4/7/15 4:17 PM, Tom Lane wrote:
>> I suspect that that's only the tip of the iceberg. Remember the mess
>> we had with implicit casts to text? And those only existed for a dozen
>> or so types, not for everything. Every function or operator you
Jim Nasby writes:
> On 4/7/15 4:35 PM, Tom Lane wrote:
>> Just out of curiosity, what's the point of this type at all, compared
>> to "anyelement" and friends?
> The two big differences are that you can store a variant in a table
> (with reasonable protect
t to something like DropBox and posting the public link here.
So far I've been unable to reproduce the failure from Chris' data :-(
Don't know why not.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
re commonly filled from execution of
previous commands.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ee from its initial location.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
amounts of memory as a
single chunk).
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
d
knowledge about cross-column correlations. The actual details of the plan
(ie, that the pkey index can be used) are determined much later.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscri
index on the referencing
column. That would make the FK is-it-ok-to-delete checks very slow.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ime,
implying more buffer-access overhead, tuple visibility checking, etc.
A closer comparison might be to a nestloop that has a Materialize node
above its inner relation.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To ma
that it was
not as simple as it seems at first glance, and that it would be difficult
to satisfy all use-cases. Try searching the archives for previous threads.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to
Bruce Momjian writes:
> Is there a reason the following patch wasn't applied?
I don't think anybody ever did the legwork to verify it was a good idea.
In particular, it'd be good to check if sending a tabstat message for each
table adds noticeable overhead.
Bruce Momjian writes:
> On Wed, May 13, 2015 at 06:10:26PM -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Is there a reason the following patch wasn't applied?
>> I don't think anybody ever did the legwork to verify it was a good idea.
>> In partic
command
> --- yeah, confusing, so no, the pl/psql ability is not deprecated.
Part of the argument for deprecating the SQL-level SELECT INTO is
exactly that it's confusingly spelled the same as plpgsql's SELECT INTO,
but it means something totally different.
regards
guration if you
recreate the database using C locale, but personally I wouldn't risk it.
Masters and slaves in a WAL-shipping replication configuration should be
on substantially identical platforms, else you're just asking for trouble.
regards, tom lane
--
S
do something
that is also in Oracle or DB2 or one of the other big boys, then we can
probably rely on the assumption that they'll block anything really
incompatible from becoming standardized ;-).
OTOH, if the actual meaning of "a lot" is "MySQL", I'd be pretty worried
r int8). And it'd likely behoove you to check how Microsoft
answers those questions, if you want to point to SQL Server as what's
going to keep you out of standards-compatibility problems. (IOW,
if 0x ever did get standardized, the text might well match what
SQL Server does.)
Bill Moran writes:
> Tom Lane wrote:
>> Other questions you'd have to think about: what is the data type of
>> 0x; what do you do with 0x (too big
>> even for int8). And it'd likely behoove you to check how Microsoft
>> an
a bit out of date,
or at least oversimplified.
One possible theory is that you had an "include" directive in
the config file in /etc, causing it to try to read the other one?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
the bit types under the bus and replaced them with "binary strings".
I wonder how painful it would be to update that stuff to be compatible
with more recent versions of the standard. Or whether anyone really
cares --- people doing this in PG seem to be happy enough with bytea
irably
for WHERE conditions on the enum column; you'd need to test.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Adrian Klaver writes:
> On 05/23/2015 08:06 AM, Tom Lane wrote:
>> I can't explain that claim, but for me, -c config_file=something
>> seems to work as you'd expect, and a look at the server source
>> code confirms that it should honor that (cf SelectConfigFiles()
ses
though. Also, I thought the fsync-everything code would only run if
the server had been shut down uncleanly. Which maybe it was, but that
bit of info wasn't provided either.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
abling SELinux makes the problem go away then
that's it. (I do *not* recommend that as a permanent solution, of course.
You'll want to find some finer-grained change to the security policy.
Don't remember enough about SELinux to know what the most likely bet is.)
better design in principle, because the necessary maintenance
can be done in background processes rather than making clients wait
for transactions to finish. In practice, it's still pretty annoying,
just in different ways than Oracle's UNDO.
regards, tom lane
--
* in the data directory unaccessible, even renamed it,
> and everything worked fine. The only difference is that these are
> streaming-replicated standby servers. They also had been restarted without
> explicitly terminating Postgres.
Hm. I wonder why we aren't fsync'ing on crash
ABLE looks --- but in a concurrent-transactions
situation, neither CREATE TABLE will see the other's table as already
existing. In race conditions like this, it's the unique index on the
catalog that is the duplicate-preventer of last resort, and it's going
to throw this error.
n the current setting of TimeZone.
So the planner will refuse to make any deductions at all with them.
You'd be much better off using child-table constraints like
"timestamp" >= '2015-01-01' AND "timestamp" < '2015-01-08'
because the p
"=?utf-8?b?RG91ZyBHb3JsZXk=?=" writes:
> On Wed, 27 May 2015 18:21:58 -0400, Tom Lane wrote:
> You'd be much better off using child-table constraints like
> "timestamp" >= '2015-01-01' AND "timestamp" < '2015-01-08
;t cost anything much to scan. If it's significant
relative to the child table access time then you probably didn't
need partitioning in the first place.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
f magnitude either way, but it's just not worth the
extra complexity for data volumes very much less than that.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ercising either of those
win scenarios, and all you're measuring is the overhead of partitioning,
which as I said is substantial.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
places to contain similar logic.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
width=24) (actual
time=0.008..0.811 rows=1228 loops=1)
-> Seq Scan on c (cost=0.00..16370.00 rows=100 width=24)
(actual time=0.007..0.310 rows=1228 loops=1)
Planning time: 0.796 ms
Execution time: 1.390 ms
(15 rows)
regards, tom lane
all the indexes on a table to be used like
that, though.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
really be able to prevent with this approach.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
get rid of the database's public schema
and/or restrict who has CREATE permissions on it. But I can't see us
shipping a default configuration in which only superusers can create
tables. That would just encourage people to operate as superusers, which
overall would be much less secure.
Getting rid of the useless join to pg_stat_all_tables would probably help;
there's a lot of computation in that view.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
nother one because of
the fresh UPDATE.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
correct.
> What else should I look for to try to determine the cause of this error?
Postmaster's log might offer some insight, especially if you turn on
log_connections.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
sues remain to be looked at?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Robert Haas writes:
> On Fri, Jun 5, 2015 at 12:00 PM, Andres Freund wrote:
>> On 2015-06-05 11:43:45 -0400, Tom Lane wrote:
>>> So where are we on this? Are we ready to schedule a new set of
>>> back-branch releases? If not, what issues remain to be looked at?
>
ntially throw off offsets for other values?
Yes. This *will* break your table, spectacularly. The other person who
was opining that it would work has no understanding of the actual storage
layout.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgr
re saying is that you don't trust the already-committed patch
very much, then maybe we'd better hold off another couple weeks for more
review and testing.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
u can omit FROM. If you suppose that that's the underlying model
then the result of "select count(*)" is completely natural.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
an't all forcibly win.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
your real problem is you have a broken gcc installation. Basic
tools like that should not need a custom LD_LIBRARY_PATH to work.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.
1 - 100 of 14353 matches
Mail list logo
