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 hank.free...@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 stu...@stuartbishop.net 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
