'.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
; in particular the problem would come back if you did a dump and
reload.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
= true
auto_explain.log_buffers = true
As the postgres user, issue pg_ctl reload
pg_ctl status will now show that there is no running postmaster.
This looks like the same thing as bug #6097, which is fixed in 9.0.5.
regards, tom lane
--
Sent via pgsql-bugs mailing
might want to check for pg_class entries with reltablespace =
16384 before pulling the trigger.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, they will NOT have the replication
permission and cannot be used as a replication user until you explicitly
grant that permission.
That doesn't sound to me like a bug. These flags are independent, we
just provide a certain default at role creation time.
regards, tom
this by having pg_ctl try to absolute-ify the -D
setting during postmaster start, but I'm not convinced it's worth the
trouble, or even that it's appropriate for pg_ctl to editorialize on the
user's choice of absolute vs relative path.
regards, tom lane
--
Sent via pgsql-bugs
old
recipe for target `uninstall'
make[1]: Nothing to be done for `all'.
You probably need to report that to the postgis folk, not here.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
database means
little, and it certainly doesn't explain why you're seeing it when
nobody else has reported any such thing.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
), the command works.
In that case you're dealing with a libedit bug. libedit has a lot of
known problems, especially if you're trying to use an old version as
it sounds like you might be. There's not a lot we can do about that.
regards, tom lane
--
Sent via pgsql-bugs mailing
personally, so replying only to me isn't going to get you
anywhere. Please keep the list cc'd when replying.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
DBs might be
confused by this; but the current arrangement is also confusing lots
of people, so I don't think that argument has all that much weight.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
available.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
be an unreasonable thing to just interpret a SELECT
with no INTO clause as being a PERFORM (ie execute and discard results).
Then we'd not have to do anything magic for commands starting with WITH.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
a SELECT and discarding the result simply
isn't there.
So at this point it looks like we made up PERFORM out of whole cloth,
and we could just as easily choose to do it another way. Jan, do you
remember anything about the reasoning for PERFORM?
regards, tom lane
--
Sent
standard is perfectly clear on this. *Values* of type
varchar can be of zero length, but that does not mean that you can
*declare* a column to be varchar(0), and that NOTE says specifically
that you can't.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
proposed patch seems to me
to be making more assumptions about what bison will emit (specifically,
about the ordering of various code blocks) than what we're doing now.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
Robert Young yay...@gmail.com writes:
On Tue, Oct 18, 2011 at 18:22, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm, what version of bison are you using?
# /usr/bin/bison -V
bison (GNU Bison) 2.3
Written by Robert Corbett and Richard Stallman.
Copyright (C) 2006 Free Software Foundation, Inc
copy of m4, but GNU m4 1.4.4, and that the
problem is not reproducible with newer versions of m4. So what it seems
to boil down to is get a newer m4. Especially if you've got 1.4.4.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
Robert Young yay...@gmail.com writes:
I've update my m4 to version 1.4.13
from:
http://ftp.openbsd.org/pub/OpenBSD/4.9/packages/amd64/m4-1.4.13.tgz
the problem solved perfectly!
Just for the archives' sake, can you confirm which m4 version you had
before?
regards, tom
the blocking of the sequence?
Why did you do that, that is what were you trying to accomplish? It
never did block nextval() on the sequence, for example.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
Laerson keler laerson.ke...@lkmc.com.br writes:
2011/10/17 Tom Lane t...@sss.pgh.pa.us
Laerson Keler laerson.ke...@lkmc.com.br writes:
Why did you do that, that is what were you trying to accomplish? It
never did block nextval() on the sequence, for example.
Tom Lane, good afternoon, I
it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Did not find any relation named foo.
regression=# \d :foo
Did not find any relation named bar.
\copy is different because it uses OT_WHOLE_LINE mode to read the
argument, and that doesn't expand :variable references. I'd be a bit
leery of changing that.
regards, tom lane
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
subdirectory of $PGDATA/base to create a new database in.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
for updates caused by FK actions, which would be a cure worse
than the disease.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
to be multiple instances of the dubious coding. It's a bit hard to
believe that nobody's noticed that before.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Pavel Stehule pavel.steh...@gmail.com writes:
[ we forgot to record dependencies on function default expressions ]
Fixed, thanks for the report.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
the standard contraction for if and only if.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
be bothered to do that, using text instead
of varchar as the column type would avoid most of the cases where you'll
see something like this.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
trying to delete a referenced row that is in fact
still referenced. One solution would be to declare the foreign key
constraint as DEFERRABLE INITIALLY DEFERRED. (The same would be the
case for a trigger, unless you made it an AFTER trigger.)
regards, tom lane
--
Sent via
by schemaname
This produces the internal error message no relation entry for relid
1. Why is that?
Looks like I broke it here:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1cb108efb0e60d87e4adec38e7636b6e8efbeb57
Fixed, thanks for the report!
regards, tom lane
Peter Geoghegan pe...@2ndquadrant.com writes:
On 29 September 2011 23:15, Tom Lane t...@sss.pgh.pa.us wrote:
Looks like I broke it here:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1cb108efb0e60d87e4adec38e7636b6e8efbeb57
Hmm. Although it was obvious to me
catalogs never have been supported, meaning
that we will never offer a guarantee that something that (more or less)
worked in a previous release will still work in newer ones.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
case for index corruption, since we must be able to compare other OID
values to the non-leaf-page entry to figure out which leaf page to
descend to in searches.
In short, the reason why this type of code hasn't been adopted into core
is that it doesn't work.
regards, tom
be ignored when matching to a collation-less index? If not, what's
the correct rule? I don't like the idea of concluding that hstore has
to be forcibly assigned a collation just because it has some operators
that accept text ...
regards, tom lane
--
Sent via pgsql-bugs
not anything too obviously broken
about the idea.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
of the 8.1 release branch
if you can't easily migrate to a supported branch.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
you didn't use the same locale settings when creating
your 9.1 database. Check LC_CTYPE and LC_COLLATE settings.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
good reason to think that someone might not ask for a snapshot
during commit processing.
Alvaro, do you happen to remember why this got designed as an early
transaction shutdown action, rather than delaying it as long as
possible?
regards, tom lane
--
Sent via pgsql-bugs
, but
I see you beat me to the deduction. Will commit it (with more than
zero comments) in a moment.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
! (But a fix like this really requires a comment IMO.)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
with commitfest
stuff, but please let me know otherwise.
I have what-I-think-is-the-fix pretty clear in my own mind, so let me
give it a try. If it doesn't work I'll bounce it back to you.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
bricklen brick...@gmail.com writes:
Is this a bug,
Yes. Thanks for the test case, will look.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I wrote:
bricklen brick...@gmail.com writes:
Is this a bug,
Yes. Thanks for the test case, will look.
Fixed, patch is at
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1679e9feddc94bd7372a6829db92868e55ef7177
regards, tom lane
--
Sent via pgsql
the following patch make sense?
Maybe, but I'd still like to see a test case, because I can't reproduce
any such problem by preparing ROLLBACK in an aborted transaction.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
*
like elsewhere in the same file instead of char const* const*.
Yep, I'm happy with that. It does what it says and no more.
I went ahead and committed this, since there seems no very good reason
to make it wait for the next commitfest.
regards, tom lane
--
Sent via
Magnus Hagander mag...@hagander.net writes:
On Thu, Sep 22, 2011 at 07:42, Tom Lane t...@sss.pgh.pa.us wrote:
I think we ought to map Central America Standard Time to plain CST6.
Magnus, AFAICT from the commit logs, that lookup table was your work to
begin with --- do you remember anything
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 18, 2011 at 5:10 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Sep 15, 2011 at 12:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In that case I'm betting Robert broke it somewhere in the unlogged-table
changes.
Yeah, looks like
: resowner.c, Line:
365)
LOG: server process (PID 16832) was terminated by signal 6: Abort trap
There isn't terribly much we can do with this report unless you can
provide a complete test case to reproduce it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
and then
changed their laws.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
| scalargtsel | scalargtjoinsel
(inet,inet) | network_sub | - | -
=(inet,inet) | network_subeq | - | -
(inet,inet) | network_sup | - | -
=(inet,inet) | network_supeq | - | -
(10 rows)
regards, tom lane
--
Sent via pgsql-bugs
Josh Berkus j...@agliodbs.com writes:
On 9/21/11 1:56 PM, Tom Lane wrote:
A look in pg_operator will show you that these operators have no
associated selectivity estimators at all. It's not so much broken
as unimplemented.
Oh! I was assuming that the special case code kicked in regardless
is
*not* a substitute for providing a selectivity estimator.
It's possible that we could build simple estimators for these operators
that just turn the problem into a range estimation and then pass it off
to somewhere else, but nobody has tried.
regards, tom lane
--
Sent via pgsql-bugs
the reasoning for the
Central America entries?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, the reason you just get 0. is that it's
rounding off after 15 digits to ensure it doesn't print garbage. Maybe
it could be a bit smarter for cases where the value is very much smaller
than 1, but it wouldn't be a simple change.)
regards, tom lane
--
Sent via pgsql-bugs
?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
If we're gonna fix it, we should just fix it, I think. I was
considering taking a stab at it, but if someone else would like
to, that's fine too.
I wouldn't mind doing it, but not until after the CF wraps
Greg Stark st...@mit.edu writes:
On Tue, Sep 20, 2011 at 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, it would
be interesting to know what Oracle etc do with NaN and Infinity,
assuming they even support such numbers.
Note that it looks like NUMBER cannot store either Infinity or NaN
you're supposed to put static,
but in any case char const * looks pretty weird to me.) Also,
the existing usages in libpq-fe.h look like that, and there's no good
reason for these to be randomly different.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
yulin liu e9320...@gmail.com writes:
can't change Column COLLATE pg_catalog.default to pg_catalog.zh_TW.euctw
Use ALTER TABLE ... ALTER COLUMN ... TYPE ... COLLATE ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
probably trying to tell you is that you can't use an EUC_TW
based locale in a database with UTF8 encoding. Try zh_TW.utf8.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
it just to prevent peculiar errors.
Can you point to any worse consequences?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
caleb.wel...@emc.com writes:
On Sep 16, 2011, at 11:11 AM, Tom Lane wrote:
Hmm. It would require an extra catalog lookup per parameter to enforce
that. Not sure that it's worth it just to prevent peculiar errors.
Can you point to any worse consequences?
I haven't found any more severe
to the name
of the database encoding (or more likely, some suitable abbrevation).
The logging collector protocol would have to be expanded to include that
information, but that seems do-able.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
got exactly the same issue.
One related thing that seems worth doing is ripping out relhaspkey,
Having a hard time getting excited about that either ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
no value. Will fix, thanks.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Robert Haas robertmh...@gmail.com writes:
On Sep 10, 2011, at 11:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(IOW, rather than fix this I'd prefer to rip out the code altogether.
But maybe we should wait a couple more years for that.)
IIRC, it's not dead code. I think you can still generate
years obsolete at this point. We don't even
document that you can do the above, do we?
(IOW, rather than fix this I'd prefer to rip out the code altogether.
But maybe we should wait a couple more years for that.)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
if it crashes?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
hubert depesz lubaczewski dep...@depesz.com writes:
On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
It's not just the port, it's all the connection parameters ---
do_connect relies on the PGconn object to remember those, and in this
case there no longer is a PGconn object.
We
.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
---
do_connect relies on the PGconn object to remember those, and in this
case there no longer is a PGconn object.
We could have psql keep that information separately, but I'm not sure
it's really worth the trouble.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, ie ['2011-08-01', '2011-08-31').
So that does not overlap the point '2011-08-31'.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
of default_statistics_target
to point out that it costs not only more time but more memory in
ANALYZE.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Lampa lamp...@gmail.com writes:
Trying analyze table (ANALYZE TABLE table or VACUUM ANALYZE table) with
3051316 rows (displayed size 2521MB in \dt+)
What have you got maintenance_work_mem set to? shared_buffers might
also be interesting.
regards, tom lane
--
Sent via
create view vv as select val from CAST(random() as integer) as val;
you will find that the system prints it out with the :: syntax,
which won't work.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
', NULL)
- array_to_string(ARRAY[NULL, 'X'], '/')
Yeah, I think you're right. Fortunately it's not too late to change
this without introducing backwards-compatibility issues of our own.
Will fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Steven Williams stwilli...@novell.com writes:
Description:/etc/init.d/postgresql-8.4 is incomplete for chkconfig
This file is not distributed by us. You probably need to contact the
SUSE packager of postgresql.
regards, tom lane
--
Sent via pgsql-bugs mailing
that
access pg_authid, and for some reason aren't releasing their locks
promptly?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
resolutions are different on
different platforms.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
have (specifically, wanting
different revision numbers of some shared libraries). If so, you may
need to build the software locally to get something that will work for
you.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
how that switch interacts with wildcard
--table specs ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
. The
configuration file option does have use-cases, just not yours.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
On the whole I'm starting to think that throwing an error is the best
thing. We could always relax that later, but going the other way might
be problematic.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
discussed. I've seen
at least a few people saying that they do rely on it ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, in that es_trig_tuple_slot is mainly
meant for the use of the layer of functions that are calling
TriggerEnabled --- it's not hard to foresee other bugs if we rearrange
the timing of the existing ExecStoreTuple calls in ExecBRUpdateTriggers
and friends.
regards, tom lane
--
Sent via pgsql
something to do with
http://git.postgresql.org/gitweb/?p=postgresql.gita=commitdiffh=eb15f26d577a11319b9429fb84f752a0135918db
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
(The error message seems to be suffering from a bad case of copy-and-
paste-itis, too.)
Actually, it is accurate. The code is:
#ifdef WIN32
h1 = CreateFile(TEMP_FILENAME_1, GENERIC_WRITE, 0, NULL,
OPEN_ALWAYS, 0
that might happen in code called by the backend, and it's doing exactly
what it's supposed to.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
... if you know it's a transient table, why do you care about backing
it up?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
using.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
seems to be suffering from a bad case of copy-and-
paste-itis, too.)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, then source the dump, ignoring
the object-already-exists errors you get for the module's objects.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
801 - 900 of 6572 matches
Mail list logo
