Hi,
>> Can someone please explain why we do not reset the expression context
>> if an SRF is involved during execution?
>
> Consider
> srf(foo(col))
> where foo returns a pass-by-reference datatype. Your proposed patch
> would cut the knees out from under argument values that the SRF could
On Thu, May 6, 2010 at 5:53 PM, wrote:
> Quoting Robert Haas :
>
>>
>> I'm not sure I understand how this more convenient than just using
>> xpath() with exists()?
>>
>
> It will save a lot of complexity in WHERE clauses. For example using
> exists() in xpath() you might construct something like:
Joel Jacobson wrote:
> I propose a set of new statistics functions and system views.
>
> I need these functions in order to do automated testing of our system,
> consisting of hundreds of stored procedures in plpgsql.
> My plan is to develop some additional functions to pgTAP, benefiting from
>
Quoting Robert Haas :
I'm not sure I understand how this more convenient than just using
xpath() with exists()?
It will save a lot of complexity in WHERE clauses. For example using
exists() in xpath() you might construct something like:
WHERE array_dims(xpath('exists(/foo/bar)',''::xml)
Greg Smith wrote:
> Bruce Momjian wrote:
> > Remember, delaying wal application just delays making the standby a
> > master and makes the slave data appear staler. We can just tell people
> > that the larger their queries are, the larger this delay will be. If
> > they want to control this, they
On Thu, May 6, 2010 at 3:23 PM, Andrew Dunstan wrote:
> And many places regard "select *" in anything other than throw-away queries
> as bad practice anyway. I have seen people get bitten by it over and over
> again, and I have worked at companies where it is explicitly forbidden in
> coding stand
Bruce Momjian wrote:
Remember, delaying wal application just delays making the standby a
master and makes the slave data appear staler. We can just tell people
that the larger their queries are, the larger this delay will be. If
they want to control this, they can set 'statement_timeout' alread
Josh Berkus wrote:
> All,
>
> We are in Beta1, now, and it's May. Original goal for 9.0 was
> June-July. We cannot be introducing major design revisions to HS/SR at
> this date, or we won't ship until December.
>
> There are at least 10 other major features in 9.0, some of which are
> more impo
On Thu, May 6, 2010 at 8:10 PM, Thom Brown wrote:
> You will call it pg_upgrade. I have spoken.
> Thom
LOL.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Bruce Momjian writes:
> OK, seems people like pg_upgrade, but do we call it "pgupgrade" or
> "pg_upgrade"?
The latter. The former is unreadable.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 6 May 2010 20:55, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > "Joshua D. Drake" writes:
> > > > On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
> > > >> I think it will be confusing if we change the name, so I vote to not
> > > >> change the name.
> > >
> > > >
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Joshua D. Drake" writes:
> > > On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
> > >> I think it will be confusing if we change the name, so I vote to not
> > >> change the name.
> >
> > > Actually, I would vote yes to change the name.
> >
> > I
I was looking for how to undo a CLUSTER call earlier today. Nothing on
the CLUSTER page told me how to do it, or pointed me to the ALTER TABLE
page. I figure a pointer to would help the next person in my situation.
xoxo,
Andy
--
Andy Lester => a...@petdance.com => www.petdance.com => AIM:pet
Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Bruce Momjian's message of jue may 06 11:19:27 -0400 2010:
> >> It seems copying over pg_statistic would require preservation of
> >> pg_class.oid. Right now we only preserve pg_class.relfilenode.
>
> > That could be fixed easily by crea
I couldn't figure out how to get rid of the CLUSTER flag on an index.
Once I got the answer from IRC, I wrote this patch to point future users
to the answer.
xoxo,
Andy
--
Andy Lester => a...@petdance.com => www.petdance.com => AIM:petdance
diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/
Tom Lane wrote:
Joseph Adams writes:
This isn't exactly a bug, but it could be considered unintuitive
behavior.
It's required by the SQL standard.
And many places regard "select *" in anything other than throw-away
queries as bad practice anyway. I ha
On Thu, May 6, 2010 at 3:01 PM, Joseph Adams wrote:
> This isn't exactly a bug, but it could be considered unintuitive
> behavior. Consider this:
by unintuitive you mean: 'explicitly defined in the SQL standard' :-).
I happen to agree with you but that's irrelevant. If you absolutely
require t
Joseph Adams writes:
> This isn't exactly a bug, but it could be considered unintuitive
> behavior.
It's required by the SQL standard.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
All,
We are in Beta1, now, and it's May. Original goal for 9.0 was
June-July. We cannot be introducing major design revisions to HS/SR at
this date, or we won't ship until December.
There are at least 10 other major features in 9.0, some of which are
more important to some of our users than HS/
This isn't exactly a bug, but it could be considered unintuitive
behavior. Consider this:
CREATE VIEW foo AS SELECT * FROM a;
CREATE VIEW foo_v AS SELECT * FROM foo;
ALTER TABLE foo ADD COLUMN b INT;
The ALTER TABLE statement affects VIEW foo, but the column addition
does not propagate to VIEW f
On Thu, May 6, 2010 at 2:47 PM, Josh Berkus wrote:
>
>> Now that I've realized what the real problem is with max_standby_delay
>> (namely, that inactivity on the master can use up the delay), I think
>> we should do what Tom originally suggested here. It's not as good as
>> a really working max_s
> Now that I've realized what the real problem is with max_standby_delay
> (namely, that inactivity on the master can use up the delay), I think
> we should do what Tom originally suggested here. It's not as good as
> a really working max_standby_delay, but we're not going to have that
> for 9.0,
Simon Riggs wrote:
> We don't have a retryable SQLSTATE, so perhaps we should document
> that serialization_failure and deadlock_detected are both
> retryable error conditions. As the above implies HS can throw some
> errors that are non-retyable, so we use ERRCODE_ADMIN_SHUTDOWN.
There is one
Florian Pflug writes:
> Anyway, I was wondering why we need guaranteed uniqueness for FK
> relationships anyway.
It's required by spec, and the semantics aren't terribly sensible
without it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Excerpts from Joel Jacobson's message of jue may 06 09:51:41 -0400 2010:
> Hi,
>
> I propose a set of new statistics functions and system views.
Hi,
Please add your patch to the next commitfest: http://commitfest.postgresql.org
Thanks
--
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On May 6, 2010, at 16:38 , Tom Lane wrote:
> Florian Pflug writes:
>> What lies at the heart of this problem is the lack of multi-table
>> indices and hence multi-table unique constraints in postgres. AFAIK
>> with those in place the rest amounts to the removal of ONLY from the
>> constraint check
Alvaro Herrera writes:
> Excerpts from Bruce Momjian's message of jue may 06 11:19:27 -0400 2010:
>> It seems copying over pg_statistic would require preservation of
>> pg_class.oid. Right now we only preserve pg_class.relfilenode.
> That could be fixed easily by creating a throwaway table which
On Thu, May 6, 2010 at 10:10 AM, Mike Fowler wrote:
> Hi hackers,
>
> Although this is a very small change I figured I'd practice the policy of
> outlining your change before you write the code and attempt a patch
> submission. Essentially I see the function as a convenience function that
> expose
On Mon, May 3, 2010 at 11:37 AM, Tom Lane wrote:
> I'm inclined to think that we should throw away all this logic and just
> have the slave cancel competing queries if the replay process waits
> more than max_standby_delay seconds to acquire a lock. This is simple,
> understandable, and behaves t
Excerpts from Bruce Momjian's message of jue may 06 11:19:27 -0400 2010:
> It seems copying over pg_statistic would require preservation of
> pg_class.oid. Right now we only preserve pg_class.relfilenode.
That could be fixed easily by creating a throwaway table which included the
qualified table
Tom Lane wrote:
> Bruce Momjian writes:
> > Jesper Krogh wrote:
> >> I should have written:
> >> Why isn't statistics copied over or why doesnt pg_migrator run analyze by
> >> itself?
>
> > Yeah, the statistics are part of the system tables, and system tables
> > are fully handled by pg_dumpall -
Tom Lane wrote:
> Bruce Momjian writes:
> > Jesper Krogh wrote:
> >> I should have written:
> >> Why isn't statistics copied over or why doesnt pg_migrator run analyze by
> >> itself?
>
> > Yeah, the statistics are part of the system tables, and system tables
> > are fully handled by pg_dumpall -
On Thu, 2010-05-06 at 17:39 +0300, Heikki Linnakangas wrote:
> Not the same plugin. A hook for stop/resume would need to be called
> before and/or after each record, the one for conflict resolution would
> need to be called at each conflict. Designing a good interface for a
> plugin is hard, you n
Simon Riggs wrote:
> On Thu, 2010-05-06 at 16:09 +0200, Dimitri Fontaine wrote:
>> Simon Riggs writes:
>>> It would be easier to implement a conflict resolution plugin that is
>>> called when a conflict occurs, allowing users to have a customisable
>>> mechanism. Again, I have no objection to that
Simon Riggs wrote:
> On Thu, 2010-05-06 at 16:09 +0200, Dimitri Fontaine wrote:
>> Simon Riggs writes:
>>> It would be easier to implement a conflict resolution plugin that is
>>> called when a conflict occurs, allowing users to have a customisable
>>> mechanism. Again, I have no objection to that
On tor, 2010-05-06 at 09:38 -0400, Tom Lane wrote:
> Funny point here: in the Fedora/RHEL RPMs, I use --disable-rpath
> because "don't use RPATH" is part of the standard packaging guidelines
> for that platform. However, pl/perl has to double back and use rpath
> anyway because libperl.so doesn't
Florian Pflug writes:
> What lies at the heart of this problem is the lack of multi-table
> indices and hence multi-table unique constraints in postgres. AFAIK
> with those in place the rest amounts to the removal of ONLY from the
> constraint check queries plus some code to propagate constraint
>
Nikhil Sontakke writes:
> Can someone please explain why we do not reset the expression context
> if an SRF is involved during execution?
Consider
srf(foo(col))
where foo returns a pass-by-reference datatype. Your proposed patch
would cut the knees out from under argument values that the
On Thu, 2010-05-06 at 16:09 +0200, Dimitri Fontaine wrote:
> Simon Riggs writes:
> > It would be easier to implement a conflict resolution plugin that is
> > called when a conflict occurs, allowing users to have a customisable
> > mechanism. Again, I have no objection to that proposal.
>
> To imp
Bruce Momjian writes:
> Jesper Krogh wrote:
>> I should have written:
>> Why isn't statistics copied over or why doesnt pg_migrator run analyze by
>> itself?
> Yeah, the statistics are part of the system tables, and system tables
> are fully handled by pg_dumpall --schema-only (except for statist
Hi hackers,
Although this is a very small change I figured I'd practice the policy
of outlining your change before you write the code and attempt a patch
submission. Essentially I see the function as a convenience function
that exposes the results of the xpath built in exists() function as a
Simon Riggs writes:
> It would be easier to implement a conflict resolution plugin that is
> called when a conflict occurs, allowing users to have a customisable
> mechanism. Again, I have no objection to that proposal.
To implement, if you say so, no doubt. To use, that means you need to
install
On Thu, 2010-05-06 at 12:08 +0200, Yeb Havinga wrote:
> That's funny because when I was reading this thread, I was thinking the
> exact opposite: having max_standby_delay always set to 0 so I know the
> standby server is as up-to-date as possible. The application that
> accesses the hot standby
On Thu, 2010-05-06 at 12:08 +0200, Yeb Havinga wrote:
> That's funny because when I was reading this thread, I was thinking the
> exact opposite: having max_standby_delay always set to 0 so I know the
> standby server is as up-to-date as possible. The application that
> accesses the hot standby
Hi,
I propose a set of new statistics functions and system views.
I need these functions in order to do automated testing of our system,
consisting of hundreds of stored procedures in plpgsql.
My plan is to develop some additional functions to pgTAP, benefiting from
the new system tables I've add
Andrew Dunstan writes:
> Greg Stark wrote
>> We only set RPATH if the install location isn't part of the default ld
>> library path specified by /etc/ld.so.conf right? Setting it if it is
>> in the default path would be antisocial.
> How are we going to know at build time what is in the ld.soconf
Bruce Momjian wrote:
> > The database (of a reasonable size) is useless until statistics is
> > available.
> >
> > I guess it is because pg_dump/restore doesn't do it either.
>
> Yeah, the statistics are part of the system tables, and system tables
> are fully handled by pg_dumpall --schema-only
Jesper Krogh wrote:
> On 2010-05-06 06:41, Alvaro Herrera wrote:
> > Excerpts from Jesper Krogh's message of jue may 06 00:32:09 -0400 2010:
> >
> >
> >> Q: I read you pdf, why isn't statistics copied over? It seems to be the
> >> last
> >> part missing from doing an upgrade in a few minutes.
Yeb Havinga wrote:
Rob Wultsch wrote:
I can not imagine setting this value to anything other than a bool and
most of the time that bool would be -1.
That's funny because when I was reading this thread, I was thinking
the exact opposite: having max_standby_delay always set to 0 so I know
the st
Greg Stark wrote
We only set RPATH if the install location isn't part of the default ld
library path specified by /etc/ld.so.conf right? Setting it if it is
in the default path would be antisocial.
How are we going to know at build time what is in the ld.soconf of the
installation machin
On Thu, May 6, 2010 at 6:37 AM, Jaime Casanova wrote:
> i would call it a bug, but this is a known issue
>
>>
>> The only solution currently is that the referring table has to be
>> partitioned the same way as the referred table in the FK, and
>> its parent table has to be queried.
>>
>
> no, you
Heikki Linnakangas wrote:
Robert Haas wrote:
I am not convinced it will be unpredictable. The only caveats that
I've seen so far are:
- You need to run ntpd.
- Queries will get cancelled like crazy if you're not using steaming
replication.
And also in situations where the master is i
On Thu, 2010-05-06 at 13:46 +0200, Florian Pflug wrote:
> On May 6, 2010, at 12:48 , Simon Riggs wrote:
> > On Thu, 2010-05-06 at 11:36 +0200, Florian Pflug wrote:
> >> If there was an additional SQL-callable function that returned the
> >> backends the recovery process is currently waiting for, p
> Patch attached with this mail.
>
The previous patch was WIP. Please take a look at this one instead. I
hope this handles the cases where results are not just base datums but
palloc'ed datums like string types too.
Regards,
Nikhils
> The SRF has its own long-lived "SRF multi-call context" anywa
On May 6, 2010, at 12:48 , Simon Riggs wrote:
> On Thu, 2010-05-06 at 11:36 +0200, Florian Pflug wrote:
>> If there was an additional SQL-callable function that returned the backends
>> the recovery process is currently waiting for, plus one that reported that
>> last timestamp seen in the WAL, t
On Thu, 2010-05-06 at 11:36 +0200, Florian Pflug wrote:
> If there was an additional SQL-callable function that returned the backends
> the recovery process is currently waiting for, plus one that reported that
> last timestamp seen in the WAL, than all those different cancellation
> policies c
2010/5/6 Boszormenyi Zoltan :
>
> =# insert into refer (parent_id) values (1);
> ERROR: insert or update on table "refer" violates foreign key
> constraint "refer_parent_id_fkey"
> DETAIL: Key (parent_id)=(1) is not present in table "parent".
>
> The use case for this was there were different new
On tor, 2010-05-06 at 11:20 +0100, Greg Stark wrote:
> We only set RPATH if the install location isn't part of the default ld
> library path specified by /etc/ld.so.conf right?
No. How would you determine that?
> Setting it if it is
> in the default path would be antisocial.
That's why there
On ons, 2010-05-05 at 19:20 -0400, Tom Lane wrote:
> Over at
> http://archives.postgresql.org/pgsql-general/2010-05/msg00091.php
> we have a complaint about "make check" failing when the install is
> intended to overwrite existing libraries (in particular, replacing
> 8.4 with 9.0 libpq). I've don
Hi,
On Thursday 06 May 2010 07:35:49 Heikki Linnakangas wrote:
> Robert Haas wrote:
> > On Wed, May 5, 2010 at 11:52 PM, Bruce Momjian wrote:
> >> I am afraid the current setting is tempting for users to enable, but
> >> will be so unpredictable that it will tarnish the repuation of HS and
> >> P
On Thu, May 6, 2010 at 12:20 AM, Tom Lane wrote:
> Now, pg_regress tries to ensure that the temporary installation
> will work as desired by setting LD_LIBRARY_PATH to point at the
> temp installation's lib/ directory. However, the psql executable
> will by default get built with a DT_RPATH entry
On Thu, May 6, 2010 at 1:35 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Wed, May 5, 2010 at 11:52 PM, Bruce Momjian wrote:
>>> I am afraid the current setting is tempting for users to enable, but
>>> will be so unpredictable that it will tarnish the repuation of HS and
>>> Postgres.
Rob Wultsch wrote:
I manage a bunch of different environments and I am pretty sure that
in any of them if the db started seemingly randomly killing queries I
would have application teams followed quickly by executives coming
after me with torches and pitchforks.
I can not imagine setting this va
Jesper Krogh writes:
> I did go the painful way (dump+restore) at that point in time.
> It was an 8.1 - 8.3 migration. Since then data has grown and the dump
> restore is even less favorable on the 8.3 -> 9.0 migration.
>
> So in general the pg_migrator way seems to be the only way to aviod
> the
On May 6, 2010, at 11:26 , Dimitri Fontaine wrote:
> Greg Smith writes:
>> If you need a script that involves changing a server setting to do
>> something, that translates into "you can't do that" for a typical DBA. The
>> idea of a program regularly changing a server configuration setting on a
>
On May 6, 2010, at 10:52 , Boszormenyi Zoltan wrote:
> =# create table parent (id serial primary key, t text);
> ...
> =# create table child () inherits (parent);
> ...
> =# create table refer (id serial primary key, parent_id integer
> ...
> =# insert into child (t) values ('a') returning id;
> ..
Greg Smith writes:
> If you need a script that involves changing a server setting to do
> something, that translates into "you can't do that" for a typical DBA. The
> idea of a program regularly changing a server configuration setting on a
> production system is one you just can't sell. That mak
Hi,
we came across an interesting problem.
=# create table parent (id serial primary key, t text);
NOTICE: CREATE TABLE will create implicit sequence "parent_id_seq" for
serial column "parent.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"parent_pkey" for table "parent"
CREA
On Wed, 2010-05-05 at 23:15 -0700, Rob Wultsch wrote:
> I manage a bunch of different environments and I am pretty sure that
> in any of them if the db started seemingly randomly killing queries I
> would have application teams followed quickly by executives coming
> after me with torches and pitc
On Wed, 2010-05-05 at 09:12 +0300, Heikki Linnakangas wrote:
> I concur that the idea is that we deal at replay with the fact that the
> snapshot lags behind. At replay, any locks/XIDs in the snapshot that
> have already been committed/aborted are ignored. For any locks/XIDs
> taken just after the
On Thu, 2010-05-06 at 00:47 -0400, Robert Haas wrote:
> That just doesn't sound that bad to me, especially since the proposed
> alternative is:
>
> - Queries will get cancelled like crazy, period.
>
> Or else:
>
> - Replication can fall infinitely far behind and you can write a
> tedious and e
Hi,
Continuing on this:
Can someone please explain why we do not reset the expression context
if an SRF is involved during execution? Once the current result from
the SRF has been consumed, I would think that the
ecxt_per_tuple_memory context should be reset. As its name suggests,
it is supposed
72 matches
Mail list logo
