Daniel Farina wrote:
On Mon, Mar 4, 2013 at 2:27 PM, Maciek Sakrejda m.sakre...@gmail.com wrote:
On Sun, Mar 3, 2013 at 9:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The real difficulty is that there may be more than one storable value
that corresponds to 1.23456 to six decimal digits. To be
On 3 March 2013 23:39, Tom Lane t...@sss.pgh.pa.us wrote:
Nicolas Barbier nicolas.barb...@gmail.com writes:
2013/3/3 Kevin Grittner kgri...@ymail.com:
Nicolas Barbier nicolas.barb...@gmail.com wrote:
I think that automatically using materialized views even when the
query doesn’t mention them
On 5 March 2013 01:04, Daniel Farina dan...@heroku.com wrote:
Corruption has easily occupied more than one person-month of time last
year for us. This year to date I've burned two weeks, although
admittedly this was probably the result of statistical clustering.
Other colleagues of mine have
Hello, I could cause the behavior and might understand the cause.
The head of origin/REL9_2_STABLE shows the behavior I metioned in
the last message when using the shell script attached. 9.3dev
runs as expected.
In XLogPageRead, when RecPtr goes beyond the last page, the
current xlog file is
On 04.03.2013 09:11, Simon Riggs wrote:
On 3 March 2013 18:24, Greg Smithg...@2ndquadrant.com wrote:
The 16-bit checksum feature seems functional, with two sources of overhead.
There's some CPU time burned to compute checksums when pages enter the
system. And there's extra overhead for WAL
Hi,
Have you benchmarked the toastrelidx removal stuff in any way? If not,
thats fine, but if yes I'd be interested.
On 2013-03-04 22:33:53 +0900, Michael Paquier wrote:
--- a/src/backend/access/heap/tuptoaster.c
+++ b/src/backend/access/heap/tuptoaster.c
@@ -1238,7 +1238,7 @@
Hello,
I think that the only other behavioural glitch I spotted was that it
fails to catch one overflow case, which should generate an out of
ranger error:
select format('|%*s|', -2147483648, 'foo');
Result: |foo|
because -(-2147483648) = 0 in signed 32-bit integers.
Ouch.
Sorry, I sent wrong script.
The head of origin/REL9_2_STABLE shows the behavior I metioned in
the last message when using the shell script attached. 9.3dev
runs as expected.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
#! /bin/sh
pgpath=$HOME/bin/pgsql_924b
echo $PATH |
Hi,
Horiguch's patch does not seem to record minRecoveryPoint in ReadRecord();
Attempt patch records minRecoveryPoint.
[crash recovery - record minRecoveryPoint in control file - archive recovery]
I think that this is an original intention of Heikki's patch.
I also found a bug in latest
Simon Riggs si...@2ndquadrant.com wrote:
On 3 March 2013 23:39, Tom Lane t...@sss.pgh.pa.us wrote:
Nicolas Barbier nicolas.barb...@gmail.com writes:
2013/3/3 Kevin Grittner kgri...@ymail.com:
Nicolas Barbier nicolas.barb...@gmail.com wrote:
I think that automatically using materialized views
I'm getting an assertion failure in HEAD with materialized views, see
below for backtrace.
To reproduce, just run make installcheck, dump the regression database
and then restore it, the server crashes during restore.
(gdb) bt
#0 0x7f283a366425 in raise () from
On Tue, Mar 5, 2013 at 7:36 AM, Kevin Grittner kgri...@ymail.com wrote:
Fujii Masao masao.fu...@gmail.com wrote:
When I accessed the materialized view in the standby server,
I got the following ERROR message. Looks odd to me. Is this a bug?
ERROR: materialized view hogeview has not been
On Mon, Mar 4, 2013 at 11:13 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Another question. If I do ALTER TABLE foo DROP COLUMN bar, do we need
to fire an event trigger for the dropped column? Right now we don't,
ISTM we should. And if we want that, then the above set of three
On Mon, Mar 4, 2013 at 4:59 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Alvaro Herrera escribió:
I think this is mostly ready to go in. I'll look at your docs, and
unless there are more objections will commit later or early tomorrow.
Actually it still needs a bit more work: the error
I spent some more time on this, and came up with the attached patch. It
includes the changes I posted earlier, to use indexes instead of
pointers in the hash table. In addition, it makes the hash table size
variable, depending on the length of the input. This further reduces the
startup cost
On Sun, Mar 3, 2013 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe this is acceptable collateral damage. I don't know. But we
definitely stand a chance of breaking applications if we change
pgstatindex like this. It might be better to invent a differently-named
function to replace
2013/3/5 Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp:
Hello,
I think that the only other behavioural glitch I spotted was that it
fails to catch one overflow case, which should generate an out of
ranger error:
select format('|%*s|', -2147483648, 'foo');
Result: |foo|
Daniel Farina dan...@heroku.com wrote:
This kind of change may have many practical problems that may
make it un-pragmatic to alter at this time (considering the
workaround is to set the extra float digits), but I can't quite
grasp the rationale for well, the only program that cares about
the
On Mon, Mar 4, 2013 at 11:50 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Is that true of all commitfests, or only the last one in a cycle? If the
former, I think the existence of the waiting on author category belies
this point.
The original point of Waiting on Author was that a patch might
Fujii Masao masao.fu...@gmail.com wrote:
And I found another problem. When I ran the following SQLs in the
master, PANIC error occurred in the standby.
CREATE TABLE hoge (i int);
INSERT INTO hoge VALUES (generate_series(1,100));
CREATE MATERIALIZED VIEW hogeview AS SELECT * FROM
Joachim Wieland j...@mcknight.de wrote:
I'm getting an assertion failure in HEAD with materialized views, see
below for backtrace.
To reproduce, just run make installcheck, dump the regression database
and then restore it, the server crashes during restore.
#2 0x00888429 in
On 5 March 2013 13:46, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/5 Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp:
Hello,
I think that the only other behavioural glitch I spotted was that it
fails to catch one overflow case, which should generate an out of
ranger error:
On Tue, Mar 5, 2013 at 10:35 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Thanks for the review. All your comments are addressed and updated patches
are attached.
I got the compile warnings:
tuptoaster.c:1539: warning: format '%s' expects type 'char *', but
argument 3 has type 'Oid'
On 05.03.2013 15:59, Kevin Grittner wrote:
Daniel Farinadan...@heroku.com wrote:
This kind of change may have many practical problems that may
make it un-pragmatic to alter at this time (considering the
workaround is to set the extra float digits), but I can't quite
grasp the rationale for
On 5 March 2013 12:15, Kevin Grittner kgri...@ymail.com wrote:
I don't think I disagree with any of what Simon says other than his
feelings about the planning cost. Imagine that there are ten MVs
that might apply to a complex query, but some of them are mutually
exclusive, so there are a
On 4 March 2013 18:59, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 3, 2013 at 9:27 PM, Josh Berkus j...@agliodbs.com wrote:
Except that the implication of waiting on author is that, if there's
no updates in a couple weeks, we bounce it. And the
2013/3/5 Dean Rasheed dean.a.rash...@gmail.com:
On 5 March 2013 13:46, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/5 Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp:
Hello,
I think that the only other behavioural glitch I spotted was that it
fails to catch one overflow case,
Kyotaro HORIGUCHI escribió:
Umm. sorry,
If you have no problem with this, I'll send this to committer.
I just found that this patch already has a revewer. I've seen
only Status field in patch list..
Patches can be reviewed by more than one people. It's particularly
useful if they have
Robert Haas escribió:
On Mon, Mar 4, 2013 at 4:59 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Alvaro Herrera escribió:
I think this is mostly ready to go in. I'll look at your docs, and
unless there are more objections will commit later or early tomorrow.
Actually it still
On Tue, Mar 5, 2013 at 12:03 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
I don't think that it is about looking nice.
C doesn't promise you more than FLT_DIG or DBL_DIG digits of
precision, so PostgreSQL cannot either.
If you allow more, that would mean that if you store the same
number
On 2013-03-05 22:35:16 +0900, Michael Paquier wrote:
Thanks for the review. All your comments are addressed and updated patches
are attached.
Please see below for the details, and if you find anything else just let me
know.
On Tue, Mar 5, 2013 at 6:27 PM, Andres Freund
HL == Heikki Linnakangas hlinnakan...@vmware.com writes:
HL It would be nice to have a base-2 text format to represent floats.
HL It wouldn't be as human-friendly as base-10, but it could be used
HL when you don't want to lose precision. pg_dump in particular.
hexidecimal notation for floats
Robert Haas escribió:
Or at least move the save/restore logic into something inside the
deletion machinery itself so that new callers don't have to worry
about it?
I don't think that works well; precisely the point of the
initialize/finalize pair of functions is to bracket the drop so
Thank you for the review.
On Tue, 2013-03-05 at 11:35 +0200, Heikki Linnakangas wrote:
If you enable checksums, the free space map never gets updated in a
standby. It will slowly drift to be completely out of sync with reality,
which could lead to significant slowdown and bloat after
Maciek Sakrejda m.sakre...@gmail.com writes:
Thank you: I think this is what I was missing, and what wasn't clear
from the proposed doc patch. But then how can pg_dump assume that it's
always safe to set extra_float_digits = 3?
It's been proven (don't have a link handy, but the paper is at
On Tue, Mar 5, 2013 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Why the discrepancy between
default behavior and what pg_dump gets?
Basically, the default behavior is tuned to the expectations of people
who think that what they put in is what they should get back, ie we
don't want the
Maciek Sakrejda m.sakre...@gmail.com writes:
On Tue, Mar 5, 2013 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Basically, the default behavior is tuned to the expectations of people
who think that what they put in is what they should get back, ie we
don't want the system doing this by
On 13-03-03 08:13 PM, Josh Berkus wrote:
This (creating the extensions) works fine for me on a Ubuntu 10.x system
Now if only we can work out the combinatorics issue ...
The plpython2u extensions worked fine but I haven't been able to get
this to work with plpython3u (python 3.1).
This conversation has moved beyond my ability to be useful but I want to remind
everyone of my original issues in case it helps you improve the docs:
1) Data shown in psql did not match data retrieved by JDBC. I had to debug
pretty deep into the JDBC code to confirm that a value I was staring
Peter mentioned in the submission that the unit tests don't pass with
python3, it doesn't work for meoutside the tests either.
Also, note that the feature is the concept of Transforms, not the
individual transforms which Peter provides. The idea is to enable a new
kind of extension.
--
Simon, Kevin, all:
Actually, there was already an attempt at automated MV query planning as
a prior university project. We could mine that for ideas.
Hmmm. I thought it was on pgfoundry, but it's not. Does anyone have
access to ACM databases etc. so they could search for this?
--
Josh
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 28, 2013 at 3:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Whichever way we go, the resulting patch is likely to be too large and
invasive for me to feel terribly comfortable about back-patching it into
9.2. AFAICT this issue only arises for
Dmitry Koterov dmi...@koterov.ru wrote:
LOG: server process (PID 18705) was terminated by signal 7: Bus error
So far I have only heard of this sort of error when PostgreSQL is
running in a virtual machine and the VM software is buggy. If you
are not running in a VM, my next two suspects would
On Tue, Mar 5, 2013 at 7:15 AM, Kevin Grittner kgri...@ymail.com wrote:
I don't think I disagree with any of what Simon says other than his
feelings about the planning cost. Imagine that there are ten MVs
that might apply to a complex query, but some of them are mutually
exclusive, so there
Josh Berkus j...@agliodbs.com wrote:
There is no shortage of literature on the topic, although any
papers from the ACM could certainly be of interest due to the
general high quality of papers published there. Adding anything
like this to 9.3 is clearly out of the question, though, so I
really
Alvaro Herrera escribió:
Hmm, maybe I should be considering a pair of macros instead --
UTILITY_START_DROP and UTILITY_END_DROP. I'll give this a try. Other
ideas are welcome.
This seems to work. See attached; I like the result because there's no
clutter and it supports all three cases
Robert Haas robertmh...@gmail.com wrote:
All that having been said, it's hard for me to imagine that
anyone really cares about any of this until we have an
incremental update feature, which right now we don't.
These are actually independent of one another, as long as we nail
down how we're
2013/3/5 Robert Haas robertmh...@gmail.com:
All that having been said, it's hard for me to imagine that anyone
really cares about any of this until we have an incremental update
feature, which right now we don't. Actually, I'm betting that's going
to be significantly harder than
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 5, 2013 at 7:15 AM, Kevin Grittner kgri...@ymail.com wrote:
I don't think I disagree with any of what Simon says other than his
feelings about the planning cost.
I'm not sure I agree. Suppose you have a query like SELECT * FROM a
INNER
2013/3/5 Kevin Grittner kgri...@ymail.com:
Exactly. I predict that we will eventually have some special sort
of trigger for maintaining MVs based on base table changes to
handle the ones that are just too expensive (in developer time or
run time) to fully automate. But there is a lot of
Nicolas Barbier nicolas.barb...@gmail.com wrote:
PS. Sorry for having fired off this discussion that obviously
doesn’t really relate to the current patch.
I know it's hard to resist. While I think there will be a number
of people for whom the current patch will be a convenience and will
On 3/3/13 6:14 PM, Josh Berkus wrote:
Currently Peter is punting (as is proper in a new patch) by having a
separate extension for each combination (hstore/plperl, hstore/plpython,
ltree/plpython, etc.). This is obviously not a maintainable approach in
the long run.
There is also a {Perl,
Peter,
There is also a {Perl, Python, Ruby, etc.} binding for {libpq, libmysql,
libpng, libyaml, libssl, libgmp, etc.}, each as a separately
downloadable and buildable package. I don't think anyone has ever
seriously considered a system by which if, say, you have Python and
libyaml
On 03/05/2013 01:09 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
There is no shortage of literature on the topic, although any
papers from the ACM could certainly be of interest due to the
general high quality of papers published there. Adding anything
like this to 9.3 is
Okay, I added a couple of lines to skip reporting dropped temp schemas,
and to skip any objects belonging to any temp schema (not just my own,
note). Not posting a new version because the change is pretty trivial.
Now, one last thing that comes up is what about objects that don't have
straight
Peter,
I'm still getting intermittent linking failures:
postgres=# drop extension plperl cascade;
NOTICE: drop cascades to extension hstore_plperl
DROP EXTENSION
postgres=# create extension plperl;
CREATE EXTENSION
postgres=# create extension hstore_plperl;
ERROR: could not load library
postgres=# create extension plperl;
CREATE EXTENSION
postgres=# create extension hstore_plperl;
ERROR: could not load library
/home/josh/pg93/lib/postgresql/hstore_plperl.so:
/home/josh/pg93/lib/postgresql/hstore_plperl.so: undefined symbol:
hstoreUniquePairs
STATEMENT: create extension
On 03/05/2013 02:52 PM, Josh Berkus wrote:
plperlh=# \c postgres
You are now connected to database postgres as user josh.
postgres=# create extension hstore_plperl;
ERROR: could not load library
/home/josh/pg93/lib/postgresql/hstore_plperl.so:
/home/josh/pg93/lib/postgresql/hstore_plperl.so:
What happens if you set your LD_LIBRARY_PATH to reflect each
installation before you start the database?
No change, at least not setting it to $PGHOME/lib.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Tue, Mar 5, 2013 at 11:22 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Mar 5, 2013 at 10:35 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Thanks for the review. All your comments are addressed and updated
patches
are attached.
I got the compile warnings:
On Tue, Mar 5, 2013 at 9:11 AM, Kevin Grittner kgri...@ymail.com wrote:
Will investigate.
You don't have default_with_oids = on, do you?
No, this was a default install with a default postgresql.conf
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table doesn't necessarily have such a thing. (Oracle has
a rowid that acts a
Tom,
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table doesn't necessarily have such a thing. (Oracle has
a rowid
On Wed, Mar 6, 2013 at 6:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table
Hey
I want to work towards the follwing feature in TODO list:
Prevent index uniqueness checks when UPDATE does not modify the
columnUniqueness
(index) checks are done when updating a column even if the column is not
modified by the UPDATE. However, HOT already short-circuits this in common
cases,
On Tue, Mar 5, 2013 at 3:04 PM, Kevin Grittner kgri...@ymail.com wrote:
Dmitry Koterov dmi...@koterov.ru wrote:
LOG: server process (PID 18705) was terminated by signal 7: Bus error
So far I have only heard of this sort of error when PostgreSQL is
running in a virtual machine and the VM
Kevin Grittner kgri...@ymail.com wrote:
REFRESH MATERIALIZED VIEW name [, ...] WITH [ NO ] DATA
Given the short time, I left out the [, ...]. If people think
that is important to get into this release, a follow-on patch might
be possible.
Barring objections, I will use the above and
Hmm..
Horiguch's patch does not seem to record minRecoveryPoint in
ReadRecord();
Attempt patch records minRecoveryPoint.
[crash recovery - record minRecoveryPoint in control file - archive
recovery]
I think that this is an original intention of Heikki's patch.
It could be. Before that, my
On Tue, Mar 5, 2013 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, the point is not so much about whether it's an improvement as that
9.2's current behavior is a regression from 9.1 and earlier. People may
not like changes in minor releases, but they don't like regressions
either.
On Sun, Mar 3, 2013 at 9:25 PM, Greg Smith g...@2ndquadrant.com wrote:
-Allow a pg_ctl standby and pg_ctl recover command that work similarly
to promote. This should slim down the work needed for the first
replication setup people do.
-Make it obvious when people try to use recovery.conf that
On Mon, 2013-01-14 at 06:37 -0500, Peter Eisentraut wrote:
Here is a patch to add an option -I/--idempotent to pg_ctl, the result
of which is that pg_ctl doesn't error on start or stop if the server is
already running or already stopped.
So apparently, pg_upgrade needs the existing behavior,
Alvaro Herrera escribió:
Now, one last thing that comes up is what about objects that don't have
straight names (such as pg_amop, pg_amproc, pg_default_acl etc etc), the
only thing you get is a catalog OID and an object OID ... but they are
pretty useless because by the time you get to the
On Wed, Mar 6, 2013 at 12:35 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
+1 for adding a new system attribute. We did something similar in
Postgres-XC, though problem there was much simpler because we always
knew that the remote FDW is a Postgres instance running the same
version. So we
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 5, 2013 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If foo OR bar is useful as an indexqual condition in the inner scan,
that's one thing. But if it isn't, the cycles expended to check it in
the inner scan are possibly wasted, because
2013/3/6 Tom Lane t...@sss.pgh.pa.us:
One of the core problems for a writable-foreign-tables feature is how
to identify a previously-fetched row for UPDATE or DELETE actions.
In an ordinary Postgres table, we use the ctid system column for that,
but a remote table doesn't necessarily have such
Thanks for taking time in typing a complete summary of the situation. That
really helps.
On Mon, Mar 4, 2013 at 11:25 AM, Greg Smith g...@2ndquadrant.com wrote:
On 1/23/13 6:36 AM, Michael Paquier wrote:
The only problem I see is if the same parameter is defined in
recovery.conf and
Hi, I suppose the attached patch is close to the solution.
I think that this is an original intention of Heikki's patch.
I noticed that archive recovery will be turned on in
next_record_is_invalid thanks to your patch.
On the other hand, your patch fixes that point but ReadRecord
runs on the
77 matches
Mail list logo
