ntax error at or near "binary"
> LINE 1: create role binary;
> ^
> regression=# create user cross;
> ERROR: syntax error at or near "cross"
> LINE 1: create user cross;
> ^
>
> If we don't have to treat type_fun
that macro 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 li
ordinary CPU 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.e
ned 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-bug
andby realize that it's no longer
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&#
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
en the options they tend to do it wrong. I think a
simpler system would be better.
--
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.postgres
very
> user-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
On Thu, Sep 13, 2012 at 1:45 PM, Jeff Davis wrote:
> On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote:
>> On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis wrote:
>> > This bug seems particularly troublesome because the right fix would be
>> > to include the relpersiste
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
ould 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
On Thu, Sep 6, 2012 at 4:23 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 06.09.2012 13:07, Robert Haas wrote:
>>> On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote:
>>>> Doesn't hint-bit setting cause WAL traffic these days?
>
>>> I sure as
On Thu, Sep 6, 2012 at 4:08 PM, Heikki Linnakangas 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-bi
On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 5, 2012 at 9:57 AM, 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
> 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 don't see how it could be
causing WAL logs to get generated.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
h the old only for
> paths including commas, leading double quotes, or leading/trailing
> 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 Enterp
et
> 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-bu
e
> any reason 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 ma
;> Is this something I could expect to be fixed in the near future, or is it
>> enough of an edge case that I should come up with some solution or
>> work-around
>> on my own? Thanks,
>
> Late reply, but I don't see any way we could fix this easily.
To me it seems like
ar 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.
FWIW, 9.2 adds support for constraints that only apply to the named
> table and don't get inherited to children. I think use of such
> constraints is probably better design than mucking around with tableoid,
> even if we were to make that work.
Maybe, but in that case shouldn't referenci
On Wed, Aug 22, 2012 at 10:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 21, 2012 at 4:30 PM, Tom Lane wrote:
>>> Meanwhile, back at the ranch: I'm fine with applying that patch now that
>>> it's had some field testing.
>
>> Attac
ly clear 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
On Tue, Aug 7, 2012 at 2:22 PM, Tom Lane wrote:
> Robert Haas 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 loa
even when no rebuild is in progress if the
rebuild errors out, but it doesn't really matter; the next rebuild
will fix it.
Anyone see a hole in that, or have better ideas?
> While looking at it, I observe that no context is passed to
> hash_create(), and no hash_destroy() is
le inconvenient (at first I didn't
> realise it was possible 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://
; plain text version of the backup file generated by:
>
> pg_dump.exe --host localhost --port 5432 --username "postgres" --format
> plain --verbose --schema-only --file
> "C:\other\postgres-bak\transfer\data.backup" oec
pg_restore only handles custom and tar format
x27;re telling it to change its mind. This sounds an awful
lot like something that could have been caused by the oversights fixed
in commit b85427f2276d02756b558c0024949305ea65aca5. Was there a
reason we didn't back-patch that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
Does anyone else
> understand the problem Tom is seeing?
Well, the part I understood was that your fix apparently does 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
nning on host "127.0.0.1" and accepting TCP/IP 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-
with what I saw.
Huh. I have no idea 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
dvector (int2vector)!
>
> it's possible ?
This is not a bug, and 7.3 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
any 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
FROM "GeoNames" WHERE fcode LIKE 'ADM%' GROUP BY iso ORDER BY iso ASC;
It's not clear how the behavior that you're getting is different from
what you expect.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-
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
On Fri, Jun 1, 2012 at 2:17 AM, Andrzej Krawiec
wrote:
> 2012/5/31 Robert Haas :
>> 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
seconds of system time,
cal/source/postgresql-9.1.2/src/include/utils/uuid.h
> /usr/local/source/postgresql-9.1.3/src/include/utils/uuid.h
> /usr/local/source/postgresql-9.2beta1/src/include/utils/uuid.h
>
>
> best regards,
> chris
> --
> chris ruprecht
> database grunt and bit pusher extr
: 0004df8b
I doubt this is broken in general, or we'd 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.enterprised
t; 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.
-
if it is absent on site now?
I don't 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
#x27;t reproduce an error 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:
ons, but it
> happened again.
perf can tell 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 ch
with following settings in postgresql.conf:
> wal_level = archive
> archive_mode = on
> archive_command = 'copy
My German isn't very good, but it looks like you took this backup with
wal_level=minimal, which is no good.
--
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
sions are not schema objects.
But it seems like maybe we need 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
stop it again, get another backtrace.
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 Compa
an existing postgres account. Try 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@postgresq
irewall and antivirus does NOT affect this behaviour (turned off).
Are you 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
On Tue, May 22, 2012 at 3:55 PM, Tom Lane wrote:
> Robert Haas writes:
>>> deik3qfhu265n6=> with hello as (select 'hello' as name)
>>> deik3qfhu265n6-> , bye as (select 'bye' as name)
>>> deik3qfhu265n6-> select * from hello UNION A
sql IMMUTABLE
> COST 1;
>
> 4. Dump the schema using 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
On Tue, May 22, 2012 at 3:46 PM, Robert Haas wrote:
> On Mon, May 14, 2012 at 11:08 AM, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 6637
>> Logged by: David Chuet
>> Email address: dch...@odotech
Wikipedia, for Morocco:
>
> Time zone WET (UTC+0)
> 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 thi
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
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
>
> i can't complete the installation process as i have persisting problem. it
> gives me the following error message: Service pgsql 8.3 failed to start.
> Verify that you have sufficient privileges to start system service. where's
> the problem?
Maybe you don't have s
what the max length of that list is during the regression tests.
Yeah.
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 v
On Thu, May 10, 2012 at 9:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 2, 2012 at 6:29 PM, Tom Lane wrote:
>>> The only way we could suppress such warnings would be if we made
>>> tab-complete.c use E'' strings for literals containing name
On Thu, May 10, 2012 at 1:32 AM, 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 PostgreSQL Company
-
ive patch that fixes it that way.
>
> Does anybody else have an opinion 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 wh
g escaping 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 cha
exited with exit code 1
> LOG: aborting startup due to startup process 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 ba
not very well. You should use some other system to
coordinate near-simultaneous creation of tables, such as perhaps doing
pg_advisory_lock/CINE/pg_advisory_unlock.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (p
ve this issue, has it been fixed in a later
> 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-bu
to also invent a way of specifying
> 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
Enterpri
On Sat, Apr 14, 2012 at 12:15 PM, Peter Eisentraut 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
>> wrote:
>> >> It has a lot of sense. Without it, it's very difficult to do logical
>> >
se, beside the point.)
>
> 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.co
IMIT after UPDATE or DELETE has no sense. Clean
> solution should be based on using updateable CTE.
It has a lot of sense. Without it, it's very difficult to do logical
replication on a table with no primary key.
(Whether or not people should create such tables in the first place
is, of c
ion when returning tuples thus it'd be applied
> for only SELECT or DML with RETURNING. So I'm +1 for non-fix but
> redefine the behavior. Who wants to limit the number of rows
> processed inside the backend, from SPI?
Yeah. I think it would be a good idea for UPDATE and DELETE to
On Mon, Apr 9, 2012 at 9:56 AM, Robert Haas wrote:
> On Tue, Mar 20, 2012 at 2:59 AM, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 6545
>> Logged by: AYACHI ABDELAKDER
>> Email address: ka...@hotmail
ery.html#RUNTIME-CONFIG-QUERY-GEQO
>
> """GEQO's searching is randomized and therefore its plans may vary
> nondeterministically."""
>
> I guess this sentence is outdated now?
Hmm, sounds like it. Does anyone think otherwise?
--
Robert Haas
Enter
exe) has
> opened key
> \REGISTRY\USER\S-1-5-21-1897005561-2437030572-477490838-1005\Control
> Panel\International
> Process 9020 (\Device\HarddiskVolume5\PostgreSQL\9.0\bin\postgres.exe) has
> opened key
> \REGISTRY\USER\S-1-5-21-1897005561-2437030572-477490838-1005\Control
>
is responsible for this problem.
My first suggestion would 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
hen restore into a freshly created 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
asionally. After restarting the
> PostgreSQL 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
le to compile it. Suggest
> 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
ostgreSQL's built-in
operators of the same names, except that they work only on integer arrays
that do not contain nulls, while the built-in operators work for any array
type. This restriction makes them faster than the built-in operators
in many cases.
But maybe some more
as what your locale settings are, for anyone to
be able 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 p
postgres as "Double Precision" format
> instead of integer.
>
> 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:
datasource to enable this level of access?
I doubt this is a bug. 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.or
upport. The
PostgreSQL community can not and does not support 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
-built binary packages there for the most
popular version/distribution/architecture combinations. If you are
running something more obscure 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
tor would, but that concept doesn't really exist
in SQL, which is seemingly deliberately quite murky about when values
spring into existence.
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
foo WHERE timestamp_column > $1 - interval
'1 hour' AND timestamp_column < $1 + interval '1 hour'
Instead do:
PREPARE x (timestamp) AS SELECT * FROM foo WHERE timestamp_column > $1
--
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
socket that is already in use, or listen_addresses
is set 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@p
eadInitThunk+0xd
> ntdll.dll!RtlUserThreadStart+0x21
This is a known issue, but I am not sure anyone has a plan for what to
do 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
On Mon, Mar 12, 2012 at 11:16 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 5, 2012 at 6:52 AM, wrote:
>>> I found some unexpected behaviour when changing the schema search path in
>>> combination with plpgsql functions (may be true for other function t
y would. I am not sure whether it would 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
, 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
The Enterpris
ow where to get, I tried the one from the website
> 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 th
esult set of "join"
> query easily.
>
> Since all other drivers have the same action, will postgresql 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 m
ompletely remove the
postgres user, and then try again.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
we see the table definitions 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
it's just the only
thing that pops out at me.
--
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, Feb 1, 2012 at 11:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> No, I wasn't thinking about a tuple descriptor mismatch. I was
>> imagining that the page contents themselves might be in flux while
>> we're trying to read from it.
>
> Oh, gotcha.
On Tue, Jan 31, 2012 at 4:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 31, 2012 at 12:05 AM, Tom Lane wrote:
>>> BTW, after a bit more reflection it occurs to me that it's not so much
>>> that the data is necessarily *bad*, as that it seemi
#x27;s no such thing 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
er hand, it's a little hard to believe we 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 (p
u do manage to get it working correctly, the backtrace should
show not only ALL (rather than only some) functions in the call stack
but also the values of the arguments passed to each of those
functions, which, probably needless to say, would be awfully helpful
in figuring this one out.
--
; Thanks again for the help, and we'll keep you posted as we learn more...
The case I 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.
the code this is
happening and put in a higher-level guard so that we get a better
error message.
You want want to compile a modified PostgreSQL executable that puts an
extremely long sleep (like a year) just before this error is reported.
Then, when the system hangs at that point, you can attach
day - like which relkinds have system
columns associated with them. But I do agree we ought 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 Enterp
On Mon, Jan 9, 2012 at 2:37 PM, Peter Geoghegan wrote:
> On 9 January 2012 18:47, Robert Haas wrote:
>> On Sat, Dec 31, 2011 at 8:54 PM, Peter Geoghegan
>> wrote:
>>> ISTM that the following reference, at config.sgml line 1345, ought to
>>> be adjusted d
1 - 100 of 787 matches
Mail list logo
