(2013/03/06 16:50), Heikki Linnakangas wrote:
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
On Tue, Mar 5, 2013 at 5:37 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
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.
On 6 March 2013 14:16, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 5 March 2013 22:02, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, my opinion is that doing anything like this in the planner is
going to be enormously expensive.
As we already said: no MVs =
2013/3/6 Tom Lane t...@sss.pgh.pa.us:
Also, the right way to deal with this desire is to teach the planner in
general, not just FDWs, about pushing expensive calculations down the
plan tree --- basically, resurrecting Joe Hellerstein's thesis work,
which we ripped out more than ten years ago.
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Here's another idea --- have three columns, type, schema (as in the
current patch and as shown above), and a third one for object identity.
For tables and other objects that have simple names, the identity would
be their names. For columns,
On 07.03.2013 10:05, KONDO Mitsumasa wrote:
(2013/03/06 16:50), Heikki Linnakangas wrote:
Yeah. That fix isn't right, though; XLogPageRead() is supposed to
return true on success, and false on error, and the patch makes it
return 'true' on error, if archive recovery was requested but we're
On 2013-03-05 23:26:59 +0200, Heikki Linnakangas wrote:
On 04.03.2013 06:39, Amit Kapila wrote:
The stats look fairly sane. I'm a little concerned about the apparent
trend of falling TPS in the patched vs original tests for the 1-client
test as record size increases, but it's only
David E. Wheeler da...@justatheory.com wrote:
Kevin Grittner kgri...@ymail.com wrote:
I also think that something should be done about the
documentation for indexes. Right now that always refers to a
table. It would clearly be awkward to change that to table
or materialized view
On Thu, Mar 7, 2013 at 8:21 AM, Kevin Grittner kgri...@ymail.com wrote:
Fujii Masao masao.fu...@gmail.com wrote:
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
On Thu, Mar 7, 2013 at 7:19 AM, Andres Freund and...@2ndquadrant.com wrote:
The strange think about hoge_pkey_cct_cct is that it seems to imply
that an invalid index was reindexed concurrently?
But I don't see how it could happen either. Fujii, can you reproduce it?
Yes, I can even with the
On 2013-03-07 09:58:58 +0900, Michael Paquier wrote:
+The recommended recovery method in such cases is to drop the
concurrent
+index and try again to perform commandREINDEX
CONCURRENTLY/.
If an invalid index depends on the constraint like primary key,
drop
Fujii Masao masao.fu...@gmail.com wrote:
Thanks! I confirmed that the problem that I reported has
disappeared in HEAD.
Unfortunately I found another odd behavior. When I accessed the
MV after VACUUM ANALYZE, I got the following error.
ERROR: materialized view hogeview has not been
On Mar 7, 2013, at 7:55 AM, Kevin Grittner kgri...@ymail.com wrote:
If the answer to both those questions is “yes,” I think the term
should remain “table,” with a few mentions that the term includes
materialized views (and excludes foreign tables).
And if the answers are not exactly and
On Fri, Mar 8, 2013 at 1:52 AM, Kevin Grittner kgri...@ymail.com wrote:
Fujii Masao masao.fu...@gmail.com wrote:
Thanks! I confirmed that the problem that I reported has
disappeared in HEAD.
Unfortunately I found another odd behavior. When I accessed the
MV after VACUUM ANALYZE, I got the
Hi,
if I understand things correctly REFRESH MATERIALIZED VIEW locks the
materialized view with an AcessExclusiveLock even if the view already
contains data.
I am pretty sure that will - understandably - confuse users, so I vote
for at least including a note about that in the docs.
This fact imo
Fujii Masao masao.fu...@gmail.com wrote:
I found one typo in the document of MV. Please see the attached
patch.
Pushed. Thanks!
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
Andres Freund and...@2ndquadrant.com wrote:
if I understand things correctly REFRESH MATERIALIZED VIEW locks
the materialized view with an AcessExclusiveLock even if the view
already contains data.
Yeah. At the time I had to make a decision on that, REINDEX
CONCURRENTLY did not seem reliable
On 2013-03-07 09:55:39 -0800, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
if I understand things correctly REFRESH MATERIALIZED VIEW locks
the materialized view with an AcessExclusiveLock even if the view
already contains data.
Yeah. At the time I had to make a
Kevin Grittner kgri...@ymail.com schrieb:
Andres Freund and...@2ndquadrant.com wrote:
if I understand things correctly REFRESH MATERIALIZED VIEW locks
the materialized view with an AcessExclusiveLock even if the view
already contains data.
Yeah. At the time I had to make a decision on
This behavior surprised me a bit:
david=# select '{foo: 1, foo: 2}'::json;
json
--
{foo: 1, foo: 2}
I had expected something more like this:
david=# select '{foo: 1, foo: 2}'::json;
json
{foo: 2}
This
anara...@anarazel.de and...@anarazel.de wrote:
In the ride home I realized that unless - not that unlikely - you
thought about something I didtn't REFRESH will behave similar to
TRUNCATE for repeatable read+ transactions that only access it
after REFRESH finished. That is, they will appear
On 03/07/2013 02:48 PM, David E. Wheeler wrote:
This behavior surprised me a bit:
david=# select '{foo: 1, foo: 2}'::json;
json
--
{foo: 1, foo: 2}
I had expected something more like this:
david=# select '{foo: 1, foo: 2}'::json;
missed a couple things.
Regards,
Jeff Davis
checksums-20130307.patch.gz
Description: GNU Zip compressed data
replace-tli-with-checksums-20130307.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 2013-03-07 11:50:11 -0800, Kevin Grittner wrote:
anara...@anarazel.de and...@anarazel.de wrote:
In the ride home I realized that unless - not that unlikely - you
thought about something I didtn't REFRESH will behave similar to
TRUNCATE for repeatable read+ transactions that only
Andres,
if I understand things correctly REFRESH MATERIALIZED VIEW locks the
materialized view with an AcessExclusiveLock even if the view already
contains data.
I am pretty sure that will - understandably - confuse users, so I vote
for at least including a note about that in the docs.
+1
2013/3/5 Kevin Grittner kgri...@ymail.com:
Perhaps it would be worth looking for anything in the patch that
you think might be painting us into a corner where it would be hard
to do all the other cool things. While it's late enough in the
process that changing anything like that which you
Hi,
On 2013-03-07 15:21:35 -0800, Josh Berkus wrote:
This fact imo reduces the usability of the matviews features as it
stands atm considerably. I think we should be very careful not to
advocate its existance much and document very clearly that its work in
progress.
Working
[Moving to -hackers]
On Sat, Feb 23, 2013 at 2:51 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
so
* --conditional-drops replaced by --if-exists
Thanks for the fixes, I played around with the patch a bit. I was sort
of expecting this example to work (after setting up the regression
Postgres is currently full of fairly innocent-looking commands which
take an unexpected ACCESS EXCLUSIVE lock. For example, DROP CONSTRAINT
takes an accessexclusive lock, but it hasn't stopped people from using
constraints, and isn't particularly high up on our todo list to fix
it.
Thats
On 2013-03-07 15:54:32 -0800, Josh Berkus wrote:
Postgres is currently full of fairly innocent-looking commands which
take an unexpected ACCESS EXCLUSIVE lock. For example, DROP CONSTRAINT
takes an accessexclusive lock, but it hasn't stopped people from using
constraints, and isn't
Hi all,
While testing materialized views, I found the following behavior with
unique indexes:
postgres=# create table aa as select generate_series(1,3) as a;
SELECT 3
postgres=# create materialized view aam as select * from aa;
SELECT 3
postgres=# create unique index aam_ind on aam(a);
CREATE
As expected, the refresh failed, but the error message is not really
user-friendly.
Shouldn't we output instead something like that?
ERROR: could not refresh materialized view because of failure when
rebuilding index
DETAIL: key is duplicated.
Is there a good reason to allow unique indexes
On Fri, Mar 8, 2013 at 11:33 AM, Josh Berkus j...@agliodbs.com wrote:
As expected, the refresh failed, but the error message is not really
user-friendly.
Shouldn't we output instead something like that?
ERROR: could not refresh materialized view because of failure when
rebuilding index
On 03/08/2013 10:55 AM, Michael Paquier wrote:
Also, as it is not mandatory for a unique index to be a constraint, I
think that we should block the creation of unique indexes too to avoid
any problems. Any suggestions?
How much does the planner benefit from the implied constraint of a
unique
On Mon, Mar 4, 2013 at 05:04:27PM -0800, Daniel Farina wrote:
Putting aside the not-so-rosy predictions seen elsewhere in this
thread about the availability of a high performance, reliable
checksumming file system available on common platforms, I'd like to
express what benefit this feature
Craig Ringer cr...@2ndquadrant.com writes:
On 03/08/2013 10:55 AM, Michael Paquier wrote:
Also, as it is not mandatory for a unique index to be a constraint, I
think that we should block the creation of unique indexes too to avoid
any problems. Any suggestions?
How much does the planner
On Fri, Mar 8, 2013 at 12:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 03/08/2013 10:55 AM, Michael Paquier wrote:
Also, as it is not mandatory for a unique index to be a constraint, I
think that we should block the creation of unique indexes too
2013/3/8 Bruce Momjian br...@momjian.us:
On Mon, Mar 4, 2013 at 05:04:27PM -0800, Daniel Farina wrote:
Putting aside the not-so-rosy predictions seen elsewhere in this
thread about the availability of a high performance, reliable
checksumming file system available on common platforms, I'd
On Thu, Mar 7, 2013 at 7:31 PM, Bruce Momjian br...@momjian.us wrote:
On Mon, Mar 4, 2013 at 05:04:27PM -0800, Daniel Farina wrote:
Putting aside the not-so-rosy predictions seen elsewhere in this
thread about the availability of a high performance, reliable
checksumming file system available
(2013/03/07 19:41), Heikki Linnakangas wrote:
On 07.03.2013 10:05, KONDO Mitsumasa wrote:
(2013/03/06 16:50), Heikki Linnakangas wrote:
Yeah. That fix isn't right, though; XLogPageRead() is supposed to
return true on success, and false on error, and the patch makes it
return 'true' on error,
Hello,
Patches can be reviewed by more than one people. It's particularly
useful if they have different things to say. So don't hesitate to
review patches that have already been reviewed by other people.
Thanks for the advice. I was anxious about who among the
reviewers is, and when to make
Everything seems settled up above my head while sleeping..
Sorry for crumsy test script, and thank you for refining it, Mitsumasa.
And thank you for fixing the bug and the detailed explanation, Heikki.
I confirmed that the problem is fixed also for me at origin/REL9_2_STABLE.
I understand
42 matches
Mail list logo
