On 02.10.2013 14:57, manindra.sar...@brightnorth.co.uk wrote:
Excel does not seem to respond with any data - but does give an idea that it
has made some sort of a connection with the database. SQL commands fail from
being executed.
I'm afraid you'll have to provide a lot more details for anyone
On 24.09.2013 14:42, marian.kruc...@gmail.com wrote:
CREATE INDEX ON tstzrange fail on 9.3.0 and 9.2.4 - default postgres
configuration.
It ate whole memory and was killed by oom.
Example:
postgres=# CREATE TABLE range_test AS SELECT tstzrange(t, t+'1min') tr FROM
generate_series('2000-1-1'::TI
Right after a fresh initdb on a 9.3 or master database:
postgres=# select oid,relname,relminmxid from pg_class where
relname='pg_database';
oid | relname | relminmxid
--+-+
1262 | pg_database | 4244967297
(1 row)
That bogus value seems to appear already some
On 13.09.2013 15:13, stu...@stuartbishop.net wrote:
pg_basebackup blocks until all necessary WAL files have been archived by
archive_command. This can take a few minutes under normal circumstances, and
indefinitely if archive_command is failing.
I would like to be able to disable this check, as
On 21.09.2013 20:16, jan.m...@inf-it.com wrote:
today I tried to upgrade from 9.2 to 9.3 (pg_upgradecluster 9.2 main) and
the upgrade of one of my databases failed with the following error: "ERROR:
new row for relation ... violates check constraint ...".
I created an example to reproduce this bu
On 16.09.2013 22:59, Andrew Gierth wrote:
"Heikki" == Heikki Linnakangas writes:
Heikki> Attached is a patch to fix both of these issues. I'm too
Heikki> tired right now to thoroughly test it and commit, so I'll get
Heikki> back to this tomorrow. Meanwhil
On 15.09.2013 15:02, and...@tao11.riddles.org.uk wrote:
The following bug has been logged on the website:
Bug reference: 8453
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 9.3.0
Operating system: any
Description:
The first snprintf
On 28.08.2013 05:01, syxj...@gmail.com wrote:
postgres=# create table pg_class(a int);
CREATE TABLE
postgres=# insert into pg_class values (1);
ERROR: null value in column "relnamespace" violates not-null constraint
DETAIL: Failing row contains (1, null, null, null, null, null, null, null,
null
On 28.08.2013 02:28, Valentine Gogichashvili wrote:
Running this sproc on the master:
CREATE OR REPLACE FUNCTION public.f()
RETURNS integer
LANGUAGE plpgsql
AS $function$
begin
CREATE TEMP TABLE temp_table_to_test_replication AS
SELECT s.i as id from generate_series(1, 100) as s(i);
On 28.08.2013 12:46, Valentine Gogichashvili wrote:
Hello
This is a well documented feature of Hot-Standby Replication.
see:
http://www.postgresql.org/docs/9.2/static/runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-STANDBY
That explains how streaming delay and query cancellations w
On 17.08.2013 12:37, Jov wrote:
http://postgresql.1045698.n5.nabble.com/BUG-5199-Window-frame-clause-wrong-behaviour-td2131492.html
tody I hit by this bug and can't find any doc about this, after google I
find the bug 5199 reported 4 years ago.
it is really nice to improve the error message or d
On 19.08.2013 13:33, nitishsaur...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 8387
Logged by: Nitish
Email address: nitishsaur...@gmail.com
PostgreSQL version: 9.2.4
Operating system: AIX7.1
Description:
Gives Error while compiling (co
On 05.08.2013 17:58, Jeremy Whiting wrote:
Hello Tom,
A quick update on progress. A second PR was created to provide a patch.
https://github.com/pgjdbc/pgjdbc/pull/76
Thanks. Looks good to me.
I wish the backend would throw a more specific error code for this,
42704 is used for many other er
(Quoted pg_controldata output edited to highlight the important parts)
On 11.07.2013 06:26, dig...@126.com wrote:
PostgreSQL 9.3 beta2 stream replication primary and standby cann't
switchover.
...
Primary :
psql
checkpont;
pg_controldata
...
Database cluster state: in production
On 26.06.2013 17:15, Tom Lane wrote:
Heikki Linnakangas writes:
We've discussed retrying short writes before, and IIRC Tom has argued
that it shouldn't be necessary when writing to disk. Nevertheless, I
think we should retry in XLogWrite(). It can write much bigger chunks
than
On 01.07.2013 00:41, emes...@redhat.com wrote:
Hi
Postgres does not support currently defining the schema in teh connection
parameters which makes it imposible to seprate the database to several
schemas and connect to the right one from the application.
There is already a thread discussing that
On 26.06.2013 15:21, Andres Freund wrote:
On 2013-06-26 13:14:37 +0100, Greg Stark wrote:
On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane wrote:
(Though if it is, it's not apparent why such
failures would only be manifesting on the pg_xlog files and not for
anything else.)
Well data files are o
On 11.06.2013 19:04, Joshua Berry wrote:
Hiroshi Inoue has developed the attached patch to correct the issue that
was reported. More of the dialogue can be found in the pgsql-odbc list.
I tried to follow that thread over at pgsql-odbc, but couldn't quite
understand what the problem is. Did yo
On 04.06.2013 15:27, Stephen Frost wrote:
* Naoya Anzai (anzai-na...@mxu.nes.nec.co.jp) wrote:
I've found a memory-leak bug in PostgreSQL 9.1.9's background
writer process.
This looks legit, but probably not the right approach to fixing it.
Looks like it'd be better to work out a way to use a
On 26.05.2013 04:31, Simon Riggs wrote:
This works fine...
COPY pgbench_accounts TO '/tmp/acc' BINARY;
This new format does not
COPY pgbench_accounts FROM '/tmp/acc' (FORMAT BINARY);
ERROR: syntax error at or near "BINARY" at character 47
which looks like I've mistyped something. Until you rea
On 21.05.2013 18:20, lal...@fhcrc.org wrote:
The following bug has been logged on the website:
Bug reference: 8173
Logged by: Lloyd Albin
Email address: lal...@fhcrc.org
PostgreSQL version: 9.2.4
Operating system: SUSE Linux (64-bit)
Description:
During testing for our 9.2
On 17.05.2013 18:53, Vladimir Jovanovic wrote:
Hi Heikki,
Here you can find attached .csv semicolon separated made by :"SELECT * FROM
pg_proc WHERE proname LIKE 'sp_get_league_prediction".
"\df sp_get_league_prediction" is also attached.
Both functions are returning the same setof record:
On 17.05.2013 11:57, Boszormenyi Zoltan wrote:
Sorry for diverting the thread but if bugfixes are urgent, you can also
look at
http://www.postgresql.org/message-id/cabuevewx2dqt45x1phhdzd_khy8hz5a9xo95xvghou2ztyn...@mail.gmail.com
and the fix at https://commitfest.postgresql.org/action/patch_vie
On 17.05.2013 13:31, vladimir.jovano...@aparteko.com wrote:
I noticed that I have two functions with the same signature.
sp_get_league_prediction(IN _id bigint, IN _rank integer, IN
_log_in_expectence double precision, IN _feathers_gained integer, IN
_tokens_all integer, IN _tokens_active intege
On 14.05.2013 16:48, bnichol...@hp.com wrote:
I've installed the 9.3 beta 1 packages (via pgdg repo and yum) and when I
try to do an initdb it fails. /var/lib/pgsql/9.3/data has nothing in it when
I attempt the initdb :
#service postgresql-9.3 initdb
Initializing database:[FAILED]
# cat /var/li
On 13.05.2013 17:09, Tom Lane wrote:
Heikki Linnakangas writes:
Would it be possible to be lenient, and also accept . as the decimal
separator, when there is no ambiguity? Ie. when . is not the thousands
separator.
I originally coded it that way, but concluded that it was probably a
waste of
On 11.05.2013 01:17, Euler Taveira wrote:
On 10-05-2013 13:09, Thomas Kellerer wrote:
Tom Lane wrote on 10.05.2013 17:49:
I looked into this, and find that the reason it misbehaves is that
NUM_numpart_from_char() will treat a '.' as being a decimal point
*without any regard to locale considerat
On 08.04.2013 18:58, Jeff Bohmer wrote:
On Apr 6, 2013, at 1:24 PM, Jeff Janes wrote:
On Sat, Apr 6, 2013 at 1:24 AM, Heikki Linnakangas
wrote:
Perhaps we should improve the documentation to make it more explicit that
backup_label must be included in the backup. The docs already say that
On 05.05.2013 21:18, fr...@heuveltop.nl wrote:
PostgreSQL version: 9.1.8
Not that it makes any difference for this issue, but you should upgrade
to 9.1.9.
After
ALTER ROLE frank SET TimeZone = 'Europe/Amsterdam';
Where the TimeZone differs from the default timezone.
SELECT current_set
On 30.04.2013 09:40, Bansal, Pradeep wrote:
I have observed the below issue after upgrading to the above mentioned version
of postgress. Any help is very much appreciated:-
ISSUE:-
===
SEQUENCE STATEMENTS = SELECT nextval('
On 24.04.2013 08:01, Hari Babu wrote:
As the following raised bug is not received by the bugs mailing list.
Forwarding the same to mailing list.
http://www.postgresql.org/message-id/E1USmqv-0006X0-5X@wrigleys.postgresql.o
rg
Please check the above defect needs any handling?
1. create table.
On 23.04.2013 10:54, ams...@cam.ac.uk wrote:
The following bug has been logged on the website:
Bug reference: 8106
Logged by: Adrian Schreyer
Email address: ams...@cam.ac.uk
PostgreSQL version: 9.2.4
Operating system: Ubuntu 12.04 LTS
Description:
The cube.c file in the cub
On 12.04.2013 09:41, Singh, Devendra wrote:
Hi All,
I hit a hang issue in postgres 8.4 query. Hit this issue multiple time on
HP-UX. Below is the snapshot of the hang thread.
lwpid : 600943
---
0: c054ced0 : _poll_sys() +
On 06.04.2013 01:02, Jeff Janes wrote:
On Fri, Apr 5, 2013 at 12:27 PM, wrote:
I use a custom base backup script to call pg_start/stop_backup() and make
the backup with rsync.
The restore_command in recovery.conf is never called by PG 9.2.4 during
startup. I confirmed this by adding a "touch /
pg_stat_statements (re-)initializes spinlocks as part of normal
operation. With --disable-spinlock, spinlocks are implemented using
semaphores, and semaphores are expected to be created at postmaster
startup. Hence, you get an assertion failure:
postgres=# select * from pg_stat_statements ;
Th
On 27.03.2013 21:04, Heikki Linnakangas wrote:
On 27.03.2013 20:27, Josh Berkus wrote:
Folks,
So I'm a bit surprised that this bug report hasn't gotten a follow-up.
Does this sound like the known 9.2.2 corruption issue, or is it
potentially something else?
It seems like a new i
On 27.03.2013 20:27, Josh Berkus wrote:
Folks,
So I'm a bit surprised that this bug report hasn't gotten a follow-up.
Does this sound like the known 9.2.2 corruption issue, or is it
potentially something else?
It seems like a new issue. At a quick glance, I think there's a bug in
heap_xlog_up
On 27.03.2013 15:07, roberto.menon...@netspa.it wrote:
after upgrading to version 9.2.3 we having a performance degradation.
We are investigating the matter on several fronts.
We've seen that Postgres (9.2.3) creates ExclusiveLock even with simple
SELECT * From myschema.mytable.
You mean like t
(cleaning up my inbox..)
Did you ever figure out this one?
On 12.12.2012 23:36, dan...@heroku.com wrote:
The following bug has been logged on the website:
Bug reference: 7753
Logged by: Daniel Farina
Email address: dan...@heroku.com
PostgreSQL version: 9.1.6
Operating system
On 23.03.2013 16:39, eshkin...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 7986
Logged by: Sergey Burladyan
Email address: eshkin...@gmail.com
PostgreSQL version: 9.2.3
Operating system: Debian GNU/Linux 7.0 (wheezy)
Description:
I have
On 19.03.2013 10:19, sunny1...@yahoo.com.vn wrote:
I tried this, which will get the list of tables belong to 'XYZ' tablespace.
CREATE TABLESPACE TBS1 OWNER access LOCATION '/u03/tbs';
--> OK
Create table public.SinhVien ( MaSV text, TenSV text, Sodt int ) tablespace
TBS1;
--> OK
Insert
On 01.03.2013 17:15, Jon Nelson wrote:
Using PostgreSQL 8.4.13 on ScientificLinux 6.3 (x86_64), I noticed
that a pg_dump ran out of (local) disk space.
However, the server was still using CPU and disk resources. An strace
clearly showed this pattern:
read() = 8192
sendto(...) = -1 EPIPE
--
On 19.02.2013 00:19, Maciek Sakrejda wrote:
On Mon, Feb 18, 2013 at 12:57 AM, Heikki Linnakangas<
hlinnakan...@vmware.com> wrote:
On 16.02.2013 01:49, Daniel Farina wrote:
I guess that means Ubuntu (and probably Debian?) libpq-dev breaks
PG_VERSION_NUM for PGXS=1.
That obviously ne
On 20.02.2013 16:19, Heikki Linnakangas wrote:
~/pgsql.92stable$ bin/createdb "foo=bar"
~/pgsql.92stable$ bin/pg_dumpall > /dev/null
pg_dump: [archiver (db)] connection to database "(null)" failed: invalid
connection option "foo"
pg_dumpall: pg_dump failed on d
~/pgsql.92stable$ bin/createdb "foo=bar"
~/pgsql.92stable$ bin/pg_dumpall > /dev/null
pg_dump: [archiver (db)] connection to database "(null)" failed: invalid
connection option "foo"
pg_dumpall: pg_dump failed on database "foo=bar", exiting
There are two bugs above:
1. When pg_dumpall passes t
On 19.02.2013 14:31, Rafael Martinez wrote:
In the way pg_rotate_logfile() and log_truncate_on_rotation = on work
today, we have to stop postgres to truncate the log file if an
unexpected situation happens and this is not always possible in a
production system.
If we need to run pg_rotate_logfil
On 16.02.2013 01:49, Daniel Farina wrote:
I guess that means Ubuntu (and probably Debian?) libpq-dev breaks
PG_VERSION_NUM for PGXS=1.
That obviously needs to be fixed in debian. Meanwhile, Maciek, I'd
suggest that you build PostgreSQL from sources, install it to some
temporary location, and
On 15.02.2013 03:49, mac...@heroku.com wrote:
The following bug has been logged on the website:
Bug reference: 7883
Logged by: Maciek Sakrejda
Email address: mac...@heroku.com
PostgreSQL version: 9.1.8
Operating system: Ubuntu 12.04 64-bit
Description:
We ran into a custome
On 11.02.2013 17:34, Matti Aarnio wrote:
} catch (SQLException e) {
int code = e.getErrorCode();
if (code == 2 // Derby
|| code == 23505) {// PostgreSQL, Oracle, ...
System.out.println("Expected SQL duplicate insert indication
status code: "+code)
}
On 09.02.2013 22:25, matti.aar...@methics.fi wrote:
CREATE TABLE example (
a TIMESTAMPNOT NULL,
b VARCHAR(256) NOT NULL,
c VARCHAR(256) NOT NULL,
PRIMARY KEY(a,b,c)
);
Inserting a duplicate record on this is returning an SQL Error, but the
status code is 0 instead of ex
On 22.01.2013 15:31, jan-peter.seif...@gmx.de wrote:
The statement:
'CREATE EXTENSION uuid-ossp'
just gives me a syntax error:
ERROR: syntax error at or near "-"
LINE 1: CREATE EXTENSION uuid-ossp
^
** Fehler **
ERROR: syntax error at or near "-"
On 15.01.2013 21:13, Tom Lane wrote:
Heikki Linnakangas writes:
On 15.01.2013 20:29, Tom Lane wrote:
But you already introduced "none" as a stand-alone (and probably almost
untranslatable without context) string. That's better?
I figured it would be. One little untrans
On 15.01.2013 20:29, Tom Lane wrote:
Heikki Linnakangas writes:
On 15.01.2013 20:10, Tom Lane wrote:
I think that patch could use more thought. As is, it will print
connect to new database (currently "none")
which to me is claiming that we are connected to a database who
On 15.01.2013 20:10, Tom Lane wrote:
Heikki Linnakangas writes:
I committed a local fix to help.c to print "none" as the database name
when not connected.
I think that patch could use more thought. As is, it will print
connect to new database (currently "none&qu
On 15.01.2013 16:18, 1584171...@qq.com wrote:
I give you a description about how to trigger this bug first：
(1) start the server with the command "postgres -D pgdata"
(2) start the client with the command "psql"
(3) close the server
(4) execute a
On 15.01.2013 10:14, Simon Riggs wrote:
On 15 January 2013 05:12, Tomonari Katsumata
wrote:
We added a REPLICATION privelge onto user accounts to control access.
Perhaps we should add a CASCADE privilege as well, so that we can
control whether we can connect to a master and/or a standby.
Sy
On 14.01.2013 16:21, a_ra...@yahoo.com wrote:
In the documentation
(http://www.postgresql.org/docs/9.1/static/functions-math.html) it is
written that the return type is the same as the input, but a query like
'select sign(1::int)' returns a double
It says that the input type is "dp or numeric",
On 14.01.2013 11:37, geryd...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 7805
Logged by: Gery Deft
Email address: geryd...@gmail.com
PostgreSQL version: 9.2.2
Operating system: Windows Server, Windows 7,Ubuntu linux
Description:
Hi,
V
On 11.01.2013 11:19, Simon Riggs wrote:
On 11 January 2013 08:40, Heikki Linnakangas wrote:
This makes me wonder if there should be a GUC to forbid cascading
replication, though. If you don't want to do cascading replication (which is
quite rare, I'd say), you could just disable it
On 11.01.2013 06:09, katsumata.tomon...@po.ntts.co.jp wrote:
The following bug has been logged on the website:
Bug reference: 7803
Logged by: Tomonari Katsumata
Email address: katsumata.tomon...@po.ntts.co.jp
PostgreSQL version: 9.2.2
Operating system: RHEL 5.3 x86_64
Descri
On 28.12.2012 20:55, Phil Sorber wrote:
Postgres 9.0.11 running as a hot standby.
The master was restarted and the standby went into a segmentation
fault loop. A hard stop/start fixed it. Here are pertinent logs with
excess and identifying information removed:
...
If there is any more info I can
On 21.12.2012 15:30, Magnus Hagander wrote:
On Fri, Dec 21, 2012 at 2:28 PM, Heikki Linnakangas
wrote:
When pg_basebackup copies data files, it does basically this:
if (lstat(pathbuf,&statbuf) != 0)
{
if (errno != ENOENT)
ereport(E
When pg_basebackup copies data files, it does basically this:
if (lstat(pathbuf, &statbuf) != 0)
{
if (errno != ENOENT)
ereport(ERROR,
(errcode_for_file_access(),
errmsg("could not stat file or directory \"%
Spotted by accident while working on a patch:
Open psql and do:
CREATE TABLE uctest(f1 int, f2 text);
-- Create a temporary child of the permanent table
CREATE TEMP TABLE ucchild () inherits (uctest);
In another terminal:
pg_ctl stop -m immediate
pg_ctl start
psql (9.3devel)
Type "help" for he
On 28.11.2012 15:47, Andres Freund wrote:
I mean the label read by read_backup_label(). Jeff's mail indicated it
had CHECKPOINT_LOCATION at 1/188D8120 but redo started at 1/CD89E48.
That's correct. The checkpoint was at 1/188D8120, but it's redo pointer
was earlier, at 1/CD89E48, so that's whe
On 28.11.2012 15:26, Andres Freund wrote:
Hm. Are you sure its actually reading your backup file? Its hard to say
without DEBUG1 output but I would tentatively say its not reading it at
all because the the "redo starts at ..." message indicates its not using
the checkpoint location from the backu
On 28.11.2012 06:27, Noah Misch wrote:
On Tue, Nov 27, 2012 at 10:08:12AM -0800, Jeff Janes wrote:
Doing PITR in 9.2.1, the system claims that it reached a consistent
recovery state immediately after redo starts.
This leads to it various mysterious failures, when it should instead
throw a "reque
On 23.11.2012 17:53, Tom Lane wrote:
Euler Taveira writes:
On 22-11-2012 04:27, Pavel Stehule wrote:
significantly larger catalog
Less than 5% of catalog columns? I don't buy your argument.
It's not about count, it's about size. For instance, pg_attribute
currently requires 140 bytes per
On 18.10.2012 22:15, Alvaro Herrera wrote:
Dave Vitek wrote:
Heikki,
It's happy about the overruns. It did flag an issue where the file
descriptor can leak when the various early returns get taken.
This is a common problem with static analysers; they don't realise we
don't care about the le
On 15.10.2012 19:31, Fujii Masao wrote:
On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
wrote:
On 15.10.2012 13:13, Heikki Linnakangas wrote:
Oh, I didn't remember that we've documented the specific structs that we
pass around. It's quite bogus anyway to explain the mess
On 15.10.2012 13:13, Heikki Linnakangas wrote:
On 13.10.2012 19:35, Fujii Masao wrote:
ISTM you need to update the protocol.sgml because you added
the field 'replyRequested' to WalSndrMessage and StandbyReplyMessage.
Oh, I didn't remember that we've documented the spec
On 13.10.2012 19:35, Fujii Masao wrote:
On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas
wrote:
Ok, thanks. Committed.
I found one typo. The attached patch fixes that typo.
Thanks, fixed.
ISTM you need to update the protocol.sgml because you added
the field 'replyRequeste
On 11.10.2012 22:36, Tom Lane wrote:
Heikki Linnakangas writes:
Hmm, starting with 9.3, postmaster can not only create and append to the
end of file, it can also inject a line in the middle, shifting the
following lines forwards. In theory, if a new line is injected into the
middle of the file
On 11.10.2012 20:29, Tom Lane wrote:
Heikki Linnakangas writes:
A straightforward fix would be to just allocate one large-enough buffer
to begin with, e.g 8k, and read the whole file in one go. I'll write up
a patch for that.
This makes the readfile function very usage-specific though.
Forwarding this to pgsql-bugs, since this isn't a security issue, as
pg_ctl can only be called an admin. My replies inline.
Original Message
Subject: [pgsql-security] race in pg_ctl start -w
Date: Thu, 11 Oct 2012 12:39:02 -0400
From: Dave Vitek
To:
Hi,
I don't really thin
On 11.10.2012 13:17, Amit Kapila wrote:
How does this look now?
The Patch is fine and test results are also fine.
Ok, thanks. Committed.
- Heikki
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-b
On 11.10.2012 14:42, Craig Ringer wrote:
On 10/11/2012 06:07 PM, Bo Thorbjørn Jensen wrote:
Self-contained case attached.
No crash here on version() = PostgreSQL 9.1.5 on
x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.0 20120507 (Red Hat
4.7.0-5), 64-bit
I can reproduce this on my Window
default value is 60 seconds.
+
+
+
+
*** a/doc/src/sgml/release-9.1.sgml
--- b/doc/src/sgml/release-9.1.sgml
***
*** 3322,3328
Add
!replication_timeout
setting (Fujii Masao, Heikki Linnakangas)
On 02.10.2012 10:36, Amit kapila wrote:
On Monday, October 01, 2012 4:08 PM Heikki Linnakangas wrote:
So let's think how this should ideally work from a user's point of view.
I think there should be just two settings: walsender_timeout and
walreceiver_timeout. walsender_timeout spe
On 21.09.2012 14:18, Amit kapila wrote:
On Tuesday, September 18, 2012 6:02 PM Fujii Masao wrote:
On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapila wrote:
Approach-2 :
Provide a variable wal_send_status_interval, such that if this is 0, then
the current behavior would prevail and if its non-zero th
On 20.09.2012 00:05, Reinhard Max wrote:
On Wed, 19 Sep 2012 at 12:39, Tom Lane wrote:
reinh...@m4x.de writes:
And what makes /dev/null necessarily the right substitute?
Because it is what virtually all deamons have been doing for the last
3..4 decades?
I don't think we should change this wi
On 15.02.2012 07:09, Andy Grimm wrote:
Sorry that it's been a couple of weeks, but I have gotten around to
working on a patch that address more of these concerns. The attached
patch should
1) allow arbitrary length passwords to be read from a file via initdb --pwfile
2) allow the client to acce
On 18.09.2012 09:46, Craig Ringer wrote:
On 09/18/2012 07:57 AM, Fujii Masao wrote:
If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.
WTF, really?
No. It's enough to bump up max_connections on the standby, and rest
On 12.09.2012 22:03, Fujii Masao wrote:
On Wed, Sep 12, 2012 at 8:47 PM, wrote:
The following bug has been logged on the website:
Bug reference: 7533
Logged by: Amit Kapila
Email address: amit.kap...@huawei.com
PostgreSQL version: 9.2.0
Operating system: Suse
Description:
On 06.09.2012 13:07, Robert Haas wrote:
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 don't see how i
On 15.08.2012 09:50, Heikki Linnakangas wrote:
On 15.08.2012 01:02, Zdeněk Jílovec wrote:
Hello,
I use PostgreSQL 9.2beta3 with PostGIS 2.0.1 and if I try create GIST
index
on column geometry(Point,2065) I get error:
test=> CREATE INDEX places_point ON places USING GIST(def_point);
ER
o me off-list, and I'll take a look.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
uot;[remote rejected]
PRE_9_2 -> PRE_9_2 (non-fast-forward)" error.
However, I succeeded by pushing it in two steps. First, I deleted the
branch with "git push origin :PRE_9_2", and then pushed it again with
"git push origin PRE_9_2". So, it's done
On 13.08.2012 11:39, Dave Page wrote:
On Mon, Aug 13, 2012 at 9:20 AM, Heikki Linnakangas
wrote:
Ok. So, why is pldbgapi.control file not included? It's there in the
repository, and "make install" copies it to share/extension.
If it's there in the repo, then it shoul
On 13.08.2012 10:42, Dave Page wrote:
On Mon, Aug 13, 2012 at 7:22 AM, Heikki Linnakangas
wrote:
On 09.08.2012 17:55, Dave Page wrote:
On Thu, Aug 9, 2012 at 3:51 PM, Heikki Linnakangas
wrote:
Ok, I see. I just downloaded the 9.1.4 installer, and you're right, there
On 09.08.2012 17:55, Dave Page wrote:
On Thu, Aug 9, 2012 at 3:51 PM, Heikki Linnakangas
wrote:
On 09.08.2012 17:07, kargor wrote:
I use the binaries provided on the download page. I have not compiled
anything - I'm a 'stupid' windows user...
Ok, I see. I just downl
e
README.pldebugger file, the version of pldebugger that the installer
includes certainly should include that file.
Dave, is this a packaging issue? Which version of pldebugger was
included in the 9.1.4 installers?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
stall" ?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nder where that came
from.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.
Fixed, thanks for the report!
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
'm not sure what the correct fix is. I suppose we could pfree() the old
value before overwriting it, but I'm not sure if that's safe, or if
there might still be references to the old value somewhere in the executor.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb
On 16.05.2012 13:47, Heikki Linnakangas wrote:
This sounds like a bug in the new page-at-a-time behavior in COPY. Can
you send me a self-contained test, including the test data?
Never mind. After staring at the code for a while, I spotted the bug,
and was able to reproduce with a simpler case
r was lost
==
If I skip the 3rd step(ALTER TABLE(fillfactor)),
I don't have any ERROR.
And It's also OK on PostgreSQL 9.1.3.
Are there any changes about this behavior ?
This sounds like a bug in the new page-at-a-time behavior in COPY. Can
you send me
so-called Olson library. See
http://www.twinsun.com/tz/tz-link.htm. Looking at the upstream library,
this is fixed in the most recent version (tzdata2012c), We will pick up
that change in the next PostgreSQL minor release, ie. 9.0.8 for the 9.0
series.
--
Heikki Linnakangas
EnterpriseDB
On 11.05.2012 18:18, Simon Riggs wrote:
On 11 May 2012 15:14, Heikki Linnakangas
wrote:
On 11.05.2012 16:56, Simon Riggs wrote:
On 11 May 2012 11:07, Heikki Linnakangas
wrote:
I wonder if we should reserve a few of the lwlock "slots" for critical
sections, to make this less
1 - 100 of 661 matches
Mail list logo
