Tom Lane wrote:
> Magnus Hagander 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 need to go aro
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 presen
robertmh...@gmail.com (Robert Haas) writes:
> On Mon, May 4, 2009 at 10:10 AM, Andres Freund 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 writing/test
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 ab
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 (nul
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
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 m
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 differ
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 Freund wrote:
Would a patch adding 'IF EXISTS' support to:
- ALTER TABLE ... DROP COLUMN
- ALTER TABLE ... DROP CONSTRAINT
possibly be accepted?
Can't spe
Bernd Helmle 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 in size) with p
Bernd Helmle 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 (pgsql-hackers@postgresql.org)
To make chang
Peter Eisentraut 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 implement a s
Tom Lane writes:
> Bernd Helmle 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 a
>> fraction (from 12 minutes
Dimitri Fontaine 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 loaded onto other
mach
Tom Lane 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 :)
> I don't t
"Kevin Grittner" writes:
> Bernd Helmle 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 pairs-of-hex-digits might be the best
tr
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Bernd Helmle 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 pairs-of
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
On Tue, May 5, 2009 at 8:56 AM, Andrew Dunstan 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
> be conflated.
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 "COMM
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 a
On Tue, May 5, 2009 at 3:57 PM, 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 afte
--On Dienstag, Mai 05, 2009 10:00:37 -0400 Tom Lane
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 total
time s
Robert Haas writes:
> On Tue, May 5, 2009 at 8:56 AM, Andrew Dunstan 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 s
Robert Haas wrote:
On Tue, May 5, 2009 at 8:56 AM, Andrew Dunstan 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
-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
"Greg Sabino Mullane" 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 over the given
--On Dienstag, Mai 05, 2009 15:29:15 + Greg Sabino Mullane
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
configuration value 0,
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 thing
-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 t
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 resp
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 wrote:
> On Mon, May 04, 2009 at 10:13:31PM -0400, Robert Haas wrote:
>
>
>> + own analysis indicates otherwie). When set to a negative value,
>> which
> s/otherwie/otherwise
>
>
>
> A question: why does attdistinct become entry #5 instead o
Robert Haas writes:
> On Mon, May 4, 2009 at 10:41 PM, Joshua Tolley 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 attdistinct next to attstattarget, since th
On Tue, May 5, 2009 at 12:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 4, 2009 at 10:41 PM, Joshua Tolley 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
Tom Lane wrote:
"Kevin Grittner" writes:
Bernd Helmle 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 pai
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 wrote:
From: Tom Lane
Subject: Re: [HACKERS] ALTER TABLE should change respective view
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 (cost=
Andrew Dunstan 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 can't think of a
"Emmanuel Cecchet" 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 ... comm
From: Tom Lane [...@sss.pgh.pa.us]
Subject: Re: [HACKERS] Wrong stats for empty tables
"Emmanuel Cecchet" 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 example:
manu=# create table
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 o
Josh Berkus 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 indeed they don't.
On Tuesday 05 May 2009 03:01:05 Tom Lane wrote:
> Peter Eisentraut 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 attac
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, Tom
On Tue, May 5, 2009 at 2:17 PM, Josh Berkus 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 or functions.
Tom Lane 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)
To make changes to
Heikki Linnakangas 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 significantly harder
to encode/d
Tom Lane wrote:
Heikki Linnakangas 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
On Tue, May 5, 2009 at 8:50 AM, Kevin Grittner
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 a MVCC based database
I
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 th
On 5/5/09 9:52 AM, Tom Lane wrote:
"Emmanuel Cecchet" 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 (pgsql-hackers@postgresql.org)
To make changes to your s
Magnus Hagander 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 enthusiasm for do
Josh Berkus 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 generated on th
Tom Lane wrote:
"Kevin Grittner" writes:
Bernd Helmle 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 pairs-of-hex-digits might be
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 (name
On Tue, May 5, 2009 at 2:03 PM, Emmanuel Cecchet
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));
> manu=# create table other (
"Joshua D. Drake" 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 reason)
> This patc
Neil Conway 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 benchmarks in
> th
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, Con
I wrote:
> Peter Eisentraut 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 principle
> th
On Tue, May 5, 2009 at 11:10 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 5, 2009 at 8:56 AM, Andrew Dunstan 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 d
Robert Haas 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
phrase; it was a
On Tue, May 5, 2009 at 9:45 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas writes:
> On Tue, May 5, 2009 at 9:45 PM, Tom Lane 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 group of people who
>> think t
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 proc
On Tue, 5 May 2009, Tom Lane wrote:
I agree that it probably wasn't considered carefully whether pg_bench
should do that; but does anyone see a reason not to change it?
I thought of one pretty weak use-case for not making this change, but
would wager the additional flexibility here is far mor
69 matches
Mail list logo
