Re: [BUGS] Errors during PostgreSQL 9.2 and 9.3 installation
Hi Please send the installation log (install-postgresql.log) from the temp. That will help us to know what went wrong. On Wed, Sep 25, 2013 at 2:44 AM, Volberg, Ovsei < ovsei.volb...@scientificgames.com> wrote: > The error message is attached. The computer was Windows 7, 32-bit > machine. Please help. > > Thank you, > > > > *Ovsei Volberg* > > Video Gaming > > Senior Software Engineer > > Scientific Games International > > *1500 Bluegrass Lakes Parkway | Alpharetta, GA 30004* > > (() Direct *770.825.4582* > > (*) *ovsei.volb...@scientificgames.com * > ** > > > > This communication (including any attachments) is intended for the use of > the intended recipient(s) only and may contain information that is > confidential, privileged or legally protected. Any unauthorized use or > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please immediately notify the sender > by return e-mail message and delete all copies of the original > communication. Thank you for your cooperation. > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > > -- Sandeep Thakkar
Re: [BUGS] BUG #8468: Create index on type tstzrange fail
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'::TIMESTAMPTZ, '2010-1-1'::TIMESTAMPTZ, '1min') AS
t1(t);
SELECT 5260321
postgres=# CREATE INDEX ON range_test(tr);
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
The connection to the server was lost. Attempting reset: Failed.
A-ha, the comparison function of range datatypes, range_cmp(), detoasts
its arguments, but fails to free the detoasted copies. Functions are
normally not required to free such temporary copies - the memory is
usually leaked into a short-lived memory context that will be quickly
free'd anyway - but B-tree comparison operators are expected to not leak.
Committed a fix, it will appear in the next minor releases. Thanks for
the report!
- Heikki
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8470: 9.3 locking/subtransaction performance regression
The following bug has been logged on the website: Bug reference: 8470 Logged by: Oskari Saarenmaa Email address: o...@ohmu.fi PostgreSQL version: 9.3.0 Operating system: Linux Description: The following code performs a lot slower on PostgreSQL 9.3.0 than on PostgreSQL 9.2.4: DROP TABLE IF EXISTS tmp; CREATE TABLE tmp (id BIGSERIAL, vals BIGINT[]); DO $$ DECLARE r_id BIGINT; n BIGINT; BEGIN FOR n IN 1..1000 LOOP BEGIN SELECT id INTO r_id FROM tmp WHERE array_length(vals, 1) < 100 LIMIT 1 FOR UPDATE NOWAIT; EXCEPTION WHEN lock_not_available THEN r_id := NULL; END; IF r_id IS NULL THEN INSERT INTO tmp (vals) VALUES (ARRAY[n]::BIGINT[]); ELSE UPDATE tmp SET vals = array_append(vals, n::BIGINT) WHERE id = r_id; END IF; END LOOP; END; $$; PostgreSQL 9.3.0: Time: 7278.910 ms PostgreSQL 9.2.4: Time: 128.008 ms Removing the BEGIN/EXCEPTION/END block and just doing a 'SELECT FOR UPDATE' for a suitable row is significantly slower in 9.3.0 (314.765 ms vs 118.894 ms on 9.2.4). A 'SELECT' without a FOR UPDATE and BEGIN/EXCEPTION/END has the same performance on 9.2.4 and 9.3.0. I'm running 9.2.4 and 9.3.0 packages from apt.postgresql.org on a Debian Squeeze host. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8470: 9.3 locking/subtransaction performance regression
o...@ohmu.fi wrote: > The following code performs a lot slower on PostgreSQL 9.3.0 than on > PostgreSQL 9.2.4: > > DROP TABLE IF EXISTS tmp; > CREATE TABLE tmp (id BIGSERIAL, vals BIGINT[]); > DO $$ > DECLARE > r_id BIGINT; > n BIGINT; > BEGIN > FOR n IN 1..1000 LOOP > BEGIN > SELECT id INTO r_id FROM tmp WHERE array_length(vals, 1) < 100 > LIMIT 1 FOR UPDATE NOWAIT; Most likely, this is caused by the new tuple lock code in 9.3. I can't look at this immediately but I will give it a look as soon as I'm able. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8450: pg_basebackup blocks until WAL archiving successful
On Mon, Sep 23, 2013 at 3:33 PM, Heikki Linnakangas > I can see why you'd want that, but it seems equally problematic to let > pg_basebackup return, when the WAL files haven't been archived yet and you > therefore don't in fact have valid, restorable backup yet. Have you > considered using the --xlog-method=stream option, to include the WAL files > in the backup? That will make your backups somewhat larger, as the WAL files > are included, but in that mode pg_basebackup won't wait for the archival and > the backup will be restorable even if archive_command is failing. I'm supporting PG 9.1 at the moment so cannot rely on --xlog-method=stream. I agree that the current behavior is for most use cases better, and I think that the behavior I want should be explicitly enabled with an option. -- Stuart Bishop http://www.stuartbishop.net/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
