error at or near cross
LINE 1: create user cross;
^
If we don't have to treat type_func_name_keywords as reserved in these
situations, shouldn't we avoid doing so?
I am almost always in favor of making more things less reserved, so +1 from me.
--
Robert Haas
EnterpriseDB
to include save/restore errno. Or else rip that
stuff out entirely --- I've sure never built this code with FDDEBUG
set, has anyone else?
Not me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs
instructions even under the best of
circumstances, but is that really material here? I'm just wondering
whether this is premature optimization that's going to potentially
bite us later in the form of subtle, hard-to-reproduce bugs.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
and try to
reproduce this with wal_debug = on. Then we will find out what WAL
records are being emitted, which will presumably give us a clue as to
what is really happening here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs
receiving keepalives from the master and terminate the connection? I
thought I had tested this at some point and it was working, so either
it's subsequently gotten broken again or the scenario you're talking
about is different in some way that I don't currently understand.
--
Robert Haas
break here. I don't know what
else to call the new GUC (replication_server_timeout?) but I'm not
excited about breaking existing conf files, nor do I particularly like
the proposed new names.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
-friendly. I'd rather not copy that same design to this walreceiver
timeout. If there's two different timeouts like that, it's even worse,
because it's easy to confuse the two.
I agree, but also note that wal_receiver_status_interval serves
another user-visible purpose as well.
--
Robert Haas
On Thu, Sep 13, 2012 at 1:45 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote:
On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis pg...@j-davis.com wrote:
This bug seems particularly troublesome because the right fix would be
to include the relpersistence
, then by definition the
table is RELPERSISTENCE_PERMANENT. So there's probably a localized
fix.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
whether we've narrowed the scope of the problem without
eliminating it, or whether that fix just didn't help at all. But they
still can't reproduce it on 9.2. This suggests that there's some
other difference between 9.1 and 9.2 that is relevant here, but I'm
not sure what. Any ideas?
--
Robert
not impossible to do; it's just a bunch of work
that nobody's gotten excited about doing yet. We've fixed similar
issues in many other cases, IIUC.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs
to reject it. I think it needs some fixes, though, so a
formal review process is called for.
+1. I added it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
filled in heap_update much later.
So now should the fix be that it returns an error for system column
reference except for OID case?
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
whitespace. I submit that all of those cases are pretty uncommon,
especially compared to embedded space.
That seems reasonable.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
WAL logging while
running pg_dump.
pg_dump doesn't modify any data, so I don't see how it could be
causing WAL logs to get generated.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 5, 2012 at 9:57 AM, b...@atsc.nl wrote:
So it would be nice if there is an option to disable WAL logging while
running pg_dump.
pg_dump doesn't modify any data, so I
On Thu, Sep 6, 2012 at 4:08 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 06.09.2012 13:07, Robert Haas wrote:
pg_dump doesn't modify any data, so I don't see how it could be
causing WAL logs to get generated.
Doesn't hint-bit setting cause WAL traffic these days?
I sure as heck don't
On Thu, Sep 6, 2012 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinn...@iki.fi writes:
On 06.09.2012 13:07, Robert Haas wrote:
On Thu, Sep 6, 2012 at 3:55 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Doesn't hint-bit setting cause WAL traffic these days?
I sure as heck don't
patch would have that effect, but currently no.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
chuck an error?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Wed, Aug 22, 2012 at 10:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 21, 2012 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Meanwhile, back at the ranch: I'm fine with applying that patch now that
it's had some field testing.
Attached
On Tue, Aug 7, 2012 at 2:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
We just had a customer hit a very similar problem on 9.1.3, running on
Windows Server 2008 SP2. ...
The customer finds that they can reproduce this on a variety of
systems under heavy
to me how to
handle the ereport/elog calls.
What to do pre-9.1 is a bit less clear to me, as the latch machinery
doesn't exist at all in those versions. Some of the fixes can
probably still be pulled out and applied, though.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
to perform actions on more than one table).
I think that you're talking about a problem with PgAdmin rather than
PostgreSQL itself, so please report your bug here:
http://www.pgadmin.org/support/list.php
http://archives.postgresql.org/pgadmin-support/
--
Robert Haas
EnterpriseDB: http
ideas?
While looking at it, I observe that no context is passed to
hash_create(), and no hash_destroy() is called. Unless I'm missing
something, that's a leak in TopMemoryContext.
I've pushed a fix for this; thanks for catching it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
not
guarantee to restore plpgsql to the state it was in, just to restore
it to existence. But previous complaints about similar issues have
fallen on deaf ears (see bug #5184). Perhaps Tom has had a change of
heart, but if so we have a few things to fix, not just this one.
--
Robert Haas
EnterpriseDB
On Fri, Jun 1, 2012 at 2:17 AM, Andrzej Krawiec
a.kraw...@focustelecom.pl wrote:
2012/5/31 Robert Haas robertmh...@gmail.com:
How long was strace -s run for to generate this?
Strace - s was running for about 2 minutes.
Hmm, I'm sort of confused then. This only shows a total of 1.815816
of things based on a single report. Three is a lot.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
errors at all in the logs... there's no
indication that anything actually failed.
/me scratches head...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
is not supported (nor is 8.0). But you
could try asking on pgsql-general.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
why I thought errdetail_internal was a good idea.
Should we just change all those to errdetail?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
connections on port
5432?
I'd check the PostgreSQL log files, if any, and the Windows event log
for errors.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
this
http://postgresql.1045698.n5.nabble.com/high-CPU-usage-for-stats-collector-in-8-2-td1962590.html
affect our environment?
Not sure, but that's a much older version of PostgreSQL than the one
you're running, and I think there may have been some improvements
meanwhile.
--
Robert Haas
EnterpriseDB
have had more complaints,
so there must be something different about your system, but I don't
know what it is. Did it leave behind any useful logfiles, maybe in
your temp directory?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs
-9.2beta1/src/include/utils/uuid.h
best regards,
chris
--
chris ruprecht
database grunt and bit pusher extraordinaíre
On May 22, 2012, at 15:58 , Robert Haas wrote:
On Tue, May 15, 2012 at 7:28 PM, ch...@cdrbill.com wrote:
The following bug has been logged on the website:
Bug reference
know what a diplom is.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
in
pg_dump no matter what I try. Maybe you're leaving out a step or two?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
you about problems in kernel-space, but I'm not sure it
exists that far back.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
- , bye as (select 'bye'::text as name)
deik3qfhu265n6- select * from hello UNION ALL select * from bye;
name
---
hello
bye
(2 rows)
I think it should return a column of type text, just as if you'd done this:
select v from (select 'hello' union all select 'bye') x(v);
--
Robert Haas
)
Summer (DST) WEST (UTC+1)(May 2nd to August 7th)
So, I cannot set correctly the DateTime for an install in Morocco.
We get the time zone list from the operating system. It might not be
working correctly, but based on this amount of information I can't
speculate as to why.
--
Robert Haas
On Tue, May 22, 2012 at 3:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 14, 2012 at 11:08 AM, dch...@odotech.com wrote:
The following bug has been logged on the website:
Bug reference: 6637
Logged by: David Chuet
Email address: dch...@odotech.com
PostgreSQL
pg_dump:
pg_dump -n superschema --inserts superdatabase superduper.sql
I just tried this exact series of steps and it worked for me. What
version are you using?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql
On Tue, May 22, 2012 at 3:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
deik3qfhu265n6= with hello as (select 'hello' as name)
deik3qfhu265n6- , bye as (select 'bye' as name)
deik3qfhu265n6- select * from hello UNION ALL select * from bye;
ERROR: failed
using the EnterpriseDB installers?
What shows up in the installation log files?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
changing the
password of that account to something that you know, and then using
that password for the installer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
.
Repeat that a few times and send us the backtrace that occurs most
frequently.
Is it a regular backend that is eating all that CPU time, or an
autovacuum worker?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs
a pg_dump --extension=XYZ option.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, May 10, 2012 at 1:32 AM, kurosawa-ak...@mxc.nes.nec.co.jp wrote:
When I executed TRUNCATE command to unlogged table,
init fork of new relfilenode (include toast) wasn't created.
Fixed, thanks for the report!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On Thu, May 10, 2012 at 9:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 2, 2012 at 6:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The only way we could suppress such warnings would be if we made
tab-complete.c use E'' strings for literals
.
And maybe any build with --enable-cassert should also emit WARNINGs
when we go past whatever we determine the same limit to be.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
rather than use any facility now available
from libpq.
PQescapeLiteral will do the job, no? At least in 9.0+.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
as to which of these solutions is
more preferable? And should we regard this as a back-patchable bug
fix, or a definition change suitable only for HEAD?
I vote for not back-patching, regardless of exactly what we decide to do here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
failure
The error message above on the FATAL line is wrong (or at least misleading).
I think it's trying to tell you that you had wal_level=minimal
configured on the master *at the time you took the base backup*.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
the order in which rows get selected for update; but I don't want to
go there.
In the use cases I'm thinking of, it doesn't matter which row you
decide to update or delete, only that you pick a single one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
release?
The previous discussion seems to indicate that it's caused by using
the wrong version of Perl.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
.)
I am not against to functionality - I am against just to syntax DELETE
FROM tab LIMIT x
because is it ambiguous what means: DELETE FROM tab RETURNING * LIMIT x
What's ambiguous about that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent
On Sat, Apr 14, 2012 at 12:15 PM, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2012-04-14 at 08:23 -0400, Robert Haas wrote:
On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It has a lot of sense. Without it, it's very difficult to do logical
replication
think it would be a good idea for UPDATE and DELETE to expose
a LIMIT option, but I can't really see the virtue in making that
functionality available only through SPI.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list
.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Poker Tracker or
their installers.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
. You might want to try posting your question to
the pgsql-odbc mailing list.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
.
Is there a setting on the ODBC driver for incoming vairables?
If not it is a buf.
Given the lack of any response here, I suggest reposting this to the
pgsql-odbc mailing list.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing
to help you with this.
Please including the installer log files as well, if possible - check
for it in your temporary files directory.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
. Not sure exactly what.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
removing it from the docs unless someone wants to pull this tool into the
core.
This complaint appears to be accurate. I think we should go ahead and
remove that mention.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing
service, it works well. This log entry comes from
src/backend/libpq/pqcomm.c. I am not certain that this is a bug. I searched
but could not find a clue. Thanks!
Sometimes this sort of issue can be caused by anti-virus software
(even if it's disabled).
--
Robert Haas
EnterpriseDB: http
database.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
be to check what %TEMP% points to - maybe
it's a nonexistent directory or something like that. The installer is
not going to abort without a reason.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
nondeterministically.
I guess this sentence is outdated now?
Hmm, sounds like it. Does anyone think otherwise?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
On Mon, Apr 9, 2012 at 9:56 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 20, 2012 at 2:59 AM, ka...@hotmail.fr wrote:
The following bug has been logged on the website:
Bug reference: 6545
Logged by: AYACHI ABDELAKDER
Email address: ka...@hotmail.fr
PostgreSQL
and don't want to use your OS vendor's
packages, you can still compile it yourself, and it should work fine.
I've done a bunch of testing recently on PPC64 and it works great.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing
.
Does the SQL standard say anything on this topic?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
(Centos 6, 32 bit). I created a small example run with psql, to demonstrate
this.
I have a vague feeling this is a known issue. It sure seems like we
should handle it better, but I'm not sure how hard that would be to
implement.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
be a good idea to
change that or not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Mon, Mar 12, 2012 at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 5, 2012 at 6:52 AM, rene.vanpaas...@gmail.com wrote:
I found some unexpected behaviour when changing the schema search path in
combination with plpgsql functions (may
about it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
improperly. It might help to see a few more lines of the log
output, rather than just the last one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, and then try again.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
driver do it
too? I think return the underlying table name is much more useful than an
empty string.
I think you might want to post this question to the pgsql-jdbc mailing
list, rather than here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent
registration but doesn't work. thanks for your time
Just use the control panel to completely delete the postgres user, and
then retry the installer. Or else change the password of the postgres
user to something that you know, and then use that for the installer.
--
Robert Haas
EnterpriseDB: http
and the queries?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, Jan 31, 2012 at 4:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 31, 2012 at 12:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, after a bit more reflection it occurs to me that it's not so much
that the data is necessarily *bad
would have missed
something that obvious; there aren't that many things that need a
cleanup lock on a heap page.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
as a negative IP address.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
dump.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
investigated involved corruption on the master, and I think
it predated Hot Standby. However, the symptom is generic enough that
it seems quite possible that there's more than one way for it to
happen. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
to handle both
the ADD COLUMN and RENAME COLUMN cases, and as such have posted an
update of Vik's patch on the other thread.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
behavior requires more quoting than the
old one did.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Mon, Jan 9, 2012 at 2:37 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 9 January 2012 18:47, Robert Haas robertmh...@gmail.com wrote:
On Sat, Dec 31, 2011 at 8:54 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
ISTM that the following reference, at config.sgml line 1345, ought
On Tue, Jan 17, 2012 at 1:23 PM, Noah Misch n...@leadboat.com wrote:
On Mon, Jan 16, 2012 at 08:54:53PM -0500, Robert Haas wrote:
On Sun, Dec 18, 2011 at 11:53 AM, Noah Misch n...@leadboat.com wrote:
Here's a version that calls sigsetjmp() once per file. ?While
postgresql.conf
scanning
in access/htup.h...should it be?
IMHO comment is wrong, code is in the right place.
It used to be in heapam.h ... evidently, whoever moved it missed this
comment.
I imagined that that was the case.
It's a fairly inconsequential bug, but it is worth fixing...
Fixed.
--
Robert Haas
, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, but you
could start by trying 8.2.23, 8.3.x, 8.4.x, etc. if you want to try to
figure it out.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
On Fri, Dec 23, 2011 at 1:58 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 23.12.2011 19:21, Robert Haas wrote:
On Thu, Dec 15, 2011 at 3:40 PM, Holec, JPH Softwareho...@jphsw.cz
wrote:
I Have PostgreSQL server 8.4.9 on Linux, database utf-8 and Client app on
Windows
/listinfo/pgbr-geral
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
feature than a bug.
That having been said, I hope we'll get around to improving it at some
point. Even though in most cases inlining is a huge win, there are
certainly boundary cases where it's not, and this is one of them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
some rows and then commit.
Is that even per spec? I would not expect the results, or the
side-effects, of a query to depend on the method used to retrieve its
results.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list
1 - 100 of 731 matches
Mail list logo
