Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
Passes my tests, but I can't really reproduce the requirement to retry,
so I haven't been able to test that part :(
The patch looks sane to me. If you want to test, perhaps reducing the
sleep to 1 msec or so would reproduce the
Alvaro Herrera wrote:
Magnus Hagander wrote:
I didn't mean race condition between backends. I meant against a
potential other thread started by a loaded DLL for initialization.
(Again, things like antivirus are known to do this, and we do see these
issues more often if AV is present for
robertmh...@gmail.com (Robert Haas) writes:
On Mon, May 4, 2009 at 10:10 AM, Andres Freund and...@anarazel.de wrote:
Would a patch adding 'IF EXISTS' support to:
- ALTER TABLE ... DROP COLUMN
- ALTER TABLE ... DROP CONSTRAINT
possibly be accepted?
Having it makes the annoying task of
From time to time we had complains about slow dump of large tables with
bytea columns, people often complaining about a) size and b) duration of
the dump.
That latter occurred recently to me, a customer would like to dump large
tables (approx. 12G in size) with pg_dump, but he was annoyed
Hi,
when i create rule(on insert) on view(select id, name from users), i
will recieve values that were inserted in form of reference words
new.id, new.name.
if i insert into users (id, name) values (null, null);
then new.id = null and new.name = null
if i insert into users (name) values
On Monday 04 May 2009 23:11:22 Archana Sundararam wrote:
I have many views dependent on a table. So whenever I do alter table and
change the column type I have to drop and recreate all the views. Is there
any other easy way to propagate the changes in the table to the views. Any
suggestion is
On Monday 04 May 2009 22:21:10 Chris Browne wrote:
For constraints, it's easy enough to treat that as idempotent; it's no
big deal to drop and re-add a constraint.
Not if the constraint is a primary key, for example.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Chris Browne wrote:
For columns, I'd *much* more frequently be interested in
ALTER TABLE ... ADD COLUMN IF NOT EXISTS ...
We have debated CREATE ... IF NOT EXISTS in the past, and there is no
consensus on what it should do, so we don't have it for any command.
That is quite a
Hi Chris,
On 05/04/2009 09:21 PM, Chris Browne wrote:
robertmh...@gmail.com (Robert Haas) writes:
On Mon, May 4, 2009 at 10:10 AM, Andres Freundand...@anarazel.de wrote:
Would a patch adding 'IF EXISTS' support to:
- ALTER TABLE ... DROP COLUMN
- ALTER TABLE ... DROP CONSTRAINT
possibly be
Bernd Helmle maili...@oopsware.de writes:
From time to time we had complains about slow dump of large tables with
bytea columns, people often complaining about a) size and b) duration of
the dump.
That latter occurred recently to me, a customer would like to dump large
tables (approx. 12G
Bernd Helmle maili...@oopsware.de wrote:
Another approach would be to just dump bytea columns in binary
format only (not sure how doable that is, though).
If that's not doable, perhaps a base64 option for bytea COPY?
-Kevin
--
Sent via pgsql-hackers mailing list
Peter Eisentraut pete...@gmx.net writes:
And this could then also change the return type of foo(), thus changing the
row type of the view and would thus propogate up to other views. And so if
you have many views, as you say, this could become a great mess. You could
probably define and
Tom Lane t...@sss.pgh.pa.us writes:
Bernd Helmle maili...@oopsware.de writes:
That latter occurred recently to me, a customer would like to dump large
tables (approx. 12G in size) with pg_dump, but he was annoyed about the
performance. Using COPY BINARY reduced the time (unsurprisingly) to
Dimitri Fontaine dfonta...@hi-media.com writes:
Still, apart from lack of interest from developpers and/or resources, is
there some reason we don't have a pg_dump --binary option?
It seems rather antithetical to one of the main goals of pg_dump,
which is to provide a dump that can reliably be
Tom Lane t...@sss.pgh.pa.us writes:
It seems rather antithetical to one of the main goals of pg_dump,
which is to provide a dump that can reliably be loaded onto other
machines or newer versions of Postgres.
You're calling for a pg_export/pg_import tool suite, or I have to learn
to read again
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Bernd Helmle maili...@oopsware.de wrote:
Another approach would be to just dump bytea columns in binary
format only (not sure how doable that is, though).
If that's not doable, perhaps a base64 option for bytea COPY?
I'm thinking plain old
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Bernd Helmle maili...@oopsware.de wrote:
Another approach would be to just dump bytea columns in binary
format only (not sure how doable that is, though).
If that's not doable, perhaps a base64 option for bytea COPY?
Bruce Momjian wrote:
bruce wrote:
Has the on-disk format changed for GiST indexes? I know it has for hash
and GIN indexes.
Sorry, I should have clarified: did the GiST index on-disk format change
between Postgres 8.3 and 8.4.
Would someone please answer my question: Did the GiST index
On Tue, May 5, 2009 at 8:56 AM, Andrew Dunstan and...@dunslane.net wrote:
We have debated CREATE ... IF NOT EXISTS in the past, and there is no
consensus on what it should do, so we don't have it for any command. That is
quite a different case from what's being asked for, and the two should not
Hi
I voted for (or registered my use of) Londiste on
http://www.postgresql.org/community/ User survey and the results page
( http://www.postgresql.org/community/survey.61 ) showed 11 for Londiste
after that.
But looking back after an hour, it was Londiste 9 again
Are you perhaps missing a
Hannu Krosing wrote:
Hi
I voted for (or registered my use of) Londiste on
http://www.postgresql.org/community/ User survey and the results page
( http://www.postgresql.org/community/survey.61 ) showed 11 for Londiste
after that.
But looking back after an hour, it was Londiste 9 again
On Tue, May 5, 2009 at 3:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
Hi
I voted for (or registered my use of) Londiste on
http://www.postgresql.org/community/ User survey and the results page
( http://www.postgresql.org/community/survey.61 ) showed 11 for Londiste
after that.
But
--On Dienstag, Mai 05, 2009 10:00:37 -0400 Tom Lane t...@sss.pgh.pa.us
wrote:
Seems like the right response might be some micro-optimization effort on
byteaout.
Hmm looking into profiler statistics seems to second your suspicion:
Normal COPY shows:
% cumulative self self
Robert Haas robertmh...@gmail.com writes:
On Tue, May 5, 2009 at 8:56 AM, Andrew Dunstan and...@dunslane.net wrote:
We have debated CREATE ... IF NOT EXISTS in the past, and there is no
consensus on what it should do, so we don't have it for any command. That is
quite a different case from
Robert Haas wrote:
On Tue, May 5, 2009 at 8:56 AM, Andrew Dunstan and...@dunslane.net wrote:
We have debated CREATE ... IF NOT EXISTS in the past, and there is no
consensus on what it should do, so we don't have it for any command. That is
quite a different case from what's being asked
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The pgsql-admin list has just seen another instance where careless use
of prepared transactions brought down a database, and the DBA (who had
no idea what a prepared transaction even was) had no idea how to fix it.
Just as a followup (and I
Greg Sabino Mullane g...@turnstep.com writes:
Just as a followup (and I already posted this on the pgsql-admin thread),
the check_postgres script now has a specific check for this very case.
It simply checks the age of entries in pg_prepared_xacts and gives
a warning if the number is at or
--On Dienstag, Mai 05, 2009 15:29:15 + Greg Sabino Mullane
g...@turnstep.com wrote:
It simply checks the age of entries in pg_prepared_xacts and gives
a warning if the number is at or over the given threshhold (defaults
to 1 second). I'm still a heavy +1 on making the default Postgres
While discussing potential changes to PostgreSQL documentation of
transaction isolation levels, Emmanuel Cecchet pointed out an
intriguing new paper[1] on a new algorithm to provide true
serializable behavior in a MVCC based database, with no additional
blocking; although, there being no such
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
1 seconds seems a very low default for me. I can imagine that most
distributed transactions are taking longer than this to complete.
One second means it is set by default to catch *all* prepared
transactions. It's simply checking how long
I wrote:
Attached is a proposed patch for the dead man switch idea.
...
Barring objections I'll go ahead and apply this to HEAD. I'm wondering
whether we are sufficiently worried about the Windows task manager issue
to risk back-patching into 8.3 and 8.2 ... comments?
For lack of response,
Tom Lane wrote:
I wrote:
Attached is a proposed patch for the dead man switch idea.
...
Barring objections I'll go ahead and apply this to HEAD. I'm wondering
whether we are sufficiently worried about the Windows task manager issue
to risk back-patching into 8.3 and 8.2 ... comments?
On Mon, May 4, 2009 at 10:41 PM, Joshua Tolley eggyk...@gmail.com wrote:
On Mon, May 04, 2009 at 10:13:31PM -0400, Robert Haas wrote:
nit
+ own analysis indicates otherwie). When set to a negative value,
which
s/otherwie/otherwise
/nit
A question: why does attdistinct become
Robert Haas robertmh...@gmail.com writes:
On Mon, May 4, 2009 at 10:41 PM, Joshua Tolley eggyk...@gmail.com wrote:
A question: why does attdistinct become entry #5 instead of going at the end?
I assume it's because the order here controls the column order, and it makes
sense to have
On Tue, May 5, 2009 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, May 4, 2009 at 10:41 PM, Joshua Tolley eggyk...@gmail.com wrote:
A question: why does attdistinct become entry #5 instead of going at the
end?
I assume it's because the order
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Bernd Helmle maili...@oopsware.de wrote:
Another approach would be to just dump bytea columns in binary
format only (not sure how doable that is, though).
If that's not doable, perhaps a base64 option for
Thanks a lot. I thought I would go with writing a function to Drop the views ,
ALTER table and the recreate the views so as to take care of the column type
changes in the table.
--- On Tue, 5/5/09, Tom Lane t...@sss.pgh.pa.us wrote:
From: Tom Lane t...@sss.pgh.pa.us
Subject: Re: [HACKERS]
Hi,
Here is an example showing the problem:
Welcome to psql 8.3.6, the PostgreSQL interactive terminal.
manu=# create table foo (x int);
CREATE TABLE
manu=# explain select * from foo;
QUERY PLAN
---
Seq Scan on foo
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I'm thinking plain old pairs-of-hex-digits might be the best
tradeoff if conversion speed is the criterion. The main problem
in any case would be to decide how to control the format option.
Yeah. Any ideas on how to do that? I
Emmanuel Cecchet emmanuel.cecc...@asterdata.com writes:
Is this a bug?
No, it's intentional.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
I wrote:
Attached is a proposed patch for the dead man switch idea.
...
Barring objections I'll go ahead and apply this to HEAD. I'm wondering
whether we are sufficiently worried about the Windows task manager issue
to risk back-patching into 8.3 and 8.2 ... comments?
For
From: Tom Lane [...@sss.pgh.pa.us]
Subject: Re: [HACKERS] Wrong stats for empty tables
Emmanuel Cecchet emmanuel.cecc...@asterdata.com writes:
Is this a bug?
No, it's intentional.
So what is the rationale behind not being able to use indexes and optimizing
empty tables as in the following
All,
I was discussing this with a client who experiences this problem on a
weekly basis, and the issue is mainly one of change management.
That is, manually dropping all of the views functions dependant on a
table, changing the table, and recreating the views and functions, is a
major PITA
It has been brought to our attention that many in the PostgreSQL
community are still not aware that we have equipment which has been
donated for community use (e.g. development and testing). As
requested we have set up an additional web page on pgfoundy and a new
mailing list to discuss usage
Josh Berkus j...@agliodbs.com writes:
Incompatible table changes would still require manual drop and
recreation, of course. But most table changes to a production database
are adding fields or changing constraints, which in most cases won't
break dependant views or functions.
... as
On Tuesday 05 May 2009 03:01:05 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 14 April 2009 21:34:51 Peter Eisentraut wrote:
I think we can handle that and the cases Tom presents by erroring out
when the U syntax is used with stdstr off.
Proposed patch for that
Sorry got top-posting -- stupid iphone mail client.
We could eliminate the problem with old dumps by doing something like
\x to indicate a new-style hex dump.
That doesn't make us 100% safe against arbitrary user input but should
be pretty low risk.
--
Greg
On 5 May 2009, at 18:51,
On Tue, May 5, 2009 at 2:17 PM, Josh Berkus j...@agliodbs.com wrote:
Incompatible table changes would still require manual drop and recreation,
of course. But most table changes to a production database are adding
fields or changing constraints, which in most cases won't break dependant
views
Tom Lane t...@sss.pgh.pa.us wrote:
Unless we can think of a more bulletproof format selection mechanism
Would it make any sense to have an option on the COPY command to tell
it to use base64 for bytea columns?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
I'm thinking plain old pairs-of-hex-digits might be the best
tradeoff if conversion speed is the criterion.
That's a lot less space-efficient than base64, though.
Well, base64 could give a 33% savings, but it's
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
I'm thinking plain old pairs-of-hex-digits might be the best
tradeoff if conversion speed is the criterion.
That's a lot less space-efficient than base64, though.
Well,
On Tue, May 5, 2009 at 8:50 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
While discussing potential changes to PostgreSQL documentation of
transaction isolation levels, Emmanuel Cecchet pointed out an
intriguing new paper[1] on a new algorithm to provide true
serializable behavior in
Hello,
I have been doing some testing with pgbench and I realized that it
forces the use of public as its search_path. This is bad if:
* You want to run multiple pgbench instances within the same database
* You don't want to use public (for whatever reason)
This patch removes that ability and
On 5/5/09 9:52 AM, Tom Lane wrote:
Emmanuel Cecchetemmanuel.cecc...@asterdata.com writes:
Is this a bug?
No, it's intentional.
Huh? Why would we want wrong stats?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list
Magnus Hagander mag...@hagander.net writes:
One proposed fix is to allocate a fairly large block of memory in the
postmaster just before we get the shared memory, and then free it right
away. The effect should be to push down the shared memory segment
further in the address space.
I have no
Josh Berkus j...@agliodbs.com writes:
On 5/5/09 9:52 AM, Tom Lane wrote:
No, it's intentional.
Huh? Why would we want wrong stats?
Tables rarely stay empty; and a plan generated on the assumption that a
table is empty is likely to suck much more when the table stops being
empty than a plan
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Bernd Helmle maili...@oopsware.de wrote:
Another approach would be to just dump bytea columns in binary
format only (not sure how doable that is, though).
If that's not doable, perhaps a base64 option for bytea COPY?
I'm
mito wrote:
Hi,
when i create rule(on insert) on view(select id, name from users), i
will recieve values that were inserted in form of reference words
new.id, new.name.
if i insert into users (id, name) values (null, null);
then new.id = null and new.name = null
if i insert into users
On Tue, May 5, 2009 at 2:03 PM, Emmanuel Cecchet
emmanuel.cecc...@asterdata.com wrote:
So what is the rationale behind not being able to use indexes and optimizing
empty tables as in the following example:
manu=# create table father (id int, val int, tex varchar(100), primary
key(id));
Joshua D. Drake j...@commandprompt.com writes:
I have been doing some testing with pgbench and I realized that it
forces the use of public as its search_path. This is bad if:
* You want to run multiple pgbench instances within the same database
* You don't want to use public (for whatever
Neil Conway neil.con...@gmail.com wrote:
Tracking the read sets of each transaction would be very expensive.
Worse still, that information needs to be kept around after
end-of-transaction, which raises questions about where it should be
stored and how it should be cleaned up. Note that the
mito escribió:
is there any way how to determinate in rule that null comes from
explicit insert or from not naming column in insert statment
Not that I know of (and yes, this sucks).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication,
I wrote:
Peter Eisentraut pete...@gmx.net writes:
AFAIR, the only reason that we haven't disallowed this sort of stuff
years and years ago is that people use it; the Japanese in particular.
I don't see what is different now.
What's different now is that 8.4 has already established the
On Tue, May 5, 2009 at 11:10 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, May 5, 2009 at 8:56 AM, Andrew Dunstan and...@dunslane.net wrote:
We have debated CREATE ... IF NOT EXISTS in the past, and there is no
consensus on what it should do, so we
Robert Haas robertmh...@gmail.com writes:
1. Why should it do nothing if the object already exists (as opposed
to any other alternative)?
Answer: Because that's what CREATE IF NOT EXISTS means when
interpreted as English.
The argument was not about whether that is the plain meaning of the
On Tue, May 5, 2009 at 9:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
1. Why should it do nothing if the object already exists (as opposed
to any other alternative)?
Answer: Because that's what CREATE IF NOT EXISTS means when
interpreted as English.
Robert Haas robertmh...@gmail.com writes:
On Tue, May 5, 2009 at 9:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The argument was not about whether that is the plain meaning of the
phrase; it was about whether that is a safe and useful behavior for a
command to have. There is a pretty substantial
It was just yesterday when i wondering why we don't have this feature (i was
trying to use it and it wasn't there :).
The group of people who think it's unsafe should not use the feature.
Clearly this feature would be useful when managing large amounts of servers
and would simplify our release
68 matches
Mail list logo
