On Thu, Aug 12, 2010 at 06:33:13PM -0400, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
I have this in my .psqlrc:
\set HISTFILE ~/.psql_history- :DBNAME
This is great, except when I change databases in a session:
% psql foo
foo % \c bar
You are now
This leads to assertion failure, on versions 8.3 onwards where plan
cache invalidation was introduced:
postgres=# CREATE FUNCTION ttfunc() RETURNS VOID AS $$
begin
PERFORM * FROM temptable;
END;
$$ LANGUAGE plpgsql;
CREATE FUNCTION
postgres=# begin;
BEGIN
postgres=# CREATE TEMPORARY TABLE
hubert depesz lubaczewski dep...@depesz.com writes:
On Thu, Aug 12, 2010 at 06:33:13PM -0400, Tom Lane wrote:
I don't think this is a bug. The history file is read at psql startup
and written out (to the same file name) at exit. Those operations are
quite expensive, so it would be insane to
I already have done this but this file still remains. There is no problem with
windows, the compute is like new and runs everyting else smooth. This is the
only problem i have ever had, i have even tried deleting the file through CMD
but no luck it still will not delete. Can you tell me what
The following bug has been logged online:
Bug reference: 5617
Logged by: Leo Shklovskii
Email address: l...@thermopylae.net
PostgreSQL version: 8.4.4
Operating system: Windows 7 (x86)
Description:pg_restore behaves unexpectedly on 'invalid' command
line
Details:
If
Leo Shklovskii l...@thermopylae.net writes:
If I put options after the filename to use for pg_restore.exe then it
behaves in a very unintuitive way.
Hmm ... pg_dump is coded to complain about that, but pg_restore just
ignores any extra arguments after the filename. I agree that's not
too good,
Scott Wheeler wheels7...@hotmail.com wrote:
Can you tell me what the pg_stat_tmp file is used for?
It's not a file; it's a subdirectory. The statistics information is
periodically written to a file within that subdirectory when
PostgreSQL is running.
I concur with prior advice -- make sure
The following bug has been logged online:
Bug reference: 5618
Logged by: Pierre
Email address: pma...@neuf.fr
PostgreSQL version: 8.4.4
Operating system: Linux
Description:restore won't work with files transferred with NFS
Details:
Computer A running
Ubuntu 9.10,
On Fri, Aug 13, 2010 at 02:01:02PM +, Pierre wrote:
The following bug has been logged online:
Bug reference: 5618
Logged by: Pierre
Email address: pma...@neuf.fr
PostgreSQL version: 8.4.4
Operating system: Linux
Description:restore won't work with files
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
PushOverrideSearchPath() assumes that if the temporary namespace existed
when an override search path was memorized with GetOverrideSearchPath(),
it must still exist. That's not true in the above example, rolling back
the
On 13/08/10 18:18, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
PushOverrideSearchPath() assumes that if the temporary namespace existed
when an override search path was memorized with GetOverrideSearchPath(),
it must still exist. That's not true in the above
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 13/08/10 18:18, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
PushOverrideSearchPath() assumes that if the temporary namespace existed
when an override search path was memorized with
The following bug has been logged online:
Bug reference: 5619
Logged by: Pierre
Email address: pma...@neuf.fr
PostgreSQL version: 8.4.4
Operating system: Linux
Description:restore won't work with files transferred with NFS
Details:
Sorry, my previous report was
More info on this issue:
1. SQL queries where executed using JDBC.
2. I was trying to repeat the bug (executing 'direct queries', from psql)- I
created a new table, added some rows, then alter table adding varchar column
field (password_pdf) with DEFAULT NULL, added some rows problem does not
Pierre pma...@neuf.fr writes:
Detailed operations:
1. on computer A, using PgAdmin3, backup of database x into file
saveddb.backup
2. tranfer of this file to a directory of computer B, using NFS
3. on computer B, Restore of this file from the local directory won't work:
3.1. If it is the
The sql statement 'ALTER TABLE table name DROP CONSTRAINT IF EXISTS
constraint-name' returns with a syntax error on exists. The
documentation states that the IF EXISTS clause is allowed in DROP
CONSTRAINT statements.
william.a.d...@gdc4s.com writes:
The sql statement 'ALTER TABLE table name DROP CONSTRAINT IF EXISTS
constraint-name' returns with a syntax error on exists. The
documentation states that the IF EXISTS clause is allowed in DROP
CONSTRAINT statements.
Apparently you're reading 9.0
2010/8/10 Tom Lane t...@sss.pgh.pa.us:
Eventually it might be nice to have some sort of way to specify the
estimate to use for any aggregate function --- but for a near-term
fix maybe we should just hard-wire a special case for array_agg in
count_agg_clauses_walker().
The attached patch is
The following bug has been logged online:
Bug reference: 5620
Logged by: Samuel Marinov
Email address: samuel.mari...@gmail.com
PostgreSQL version: 9.0b4
Operating system: Ubuntu Linux 10.04 64-bit
Description:PostgreSQL won't accept the word user as a valid
column
2010/8/14 Itagaki Takahiro itagaki.takah...@gmail.com:
2010/8/10 Tom Lane t...@sss.pgh.pa.us:
Eventually it might be nice to have some sort of way to specify the
estimate to use for any aggregate function --- but for a near-term
fix maybe we should just hard-wire a special case for array_agg
20 matches
Mail list logo
