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 thi
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 ma
(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, i
On Thu, Mar 7, 2013 at 7:31 PM, Bruce Momjian 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 on common
2013/3/8 Bruce Momjian :
> 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
>> ex
On Fri, Mar 8, 2013 at 12:32 PM, Tom Lane wrote:
> Craig Ringer 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
Craig Ringer 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 benefit from the i
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
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 Fri, Mar 8, 2013 at 11:33 AM, Josh Berkus 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"
> > D
> 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 i
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 INDE
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, an
>> 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.
[Moving to -hackers]
On Sat, Feb 23, 2013 at 2:51 PM, Pavel Stehule 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
database with `make install
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 inc
2013/3/5 Kevin Grittner :
> 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 find would be
>
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.
On 2013-03-07 11:50:11 -0800, Kevin Grittner wrote:
> "anara...@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
> >
cksum failure
causes an error or not.
I need to do another self-review after these changes and some more
extensive testing, so I might have missed a couple things.
Regards,
Jeff Davis
checksums-20130307.patch.gz
Description: GNU Zip compressed data
replace-tli-with-checksums-20130307.pa
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}'::js
"anara...@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 empty.
In an
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
{"fo
Kevin Grittner schrieb:
>Andres Freund 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 n
On 2013-03-07 09:55:39 -0800, Kevin Grittner wrote:
> Andres Freund 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 th
Andres Freund 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 with a weaker lock,
Fujii Masao 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 (pgsql-hackers@postgresql.org)
To make changes t
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
On Fri, Mar 8, 2013 at 1:52 AM, Kevin Grittner wrote:
> Fujii Masao 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.
>>
>> E
On Mar 7, 2013, at 7:55 AM, Kevin Grittner 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 "yes"?
I s
Fujii Masao 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 populated
>
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 REINDEX
> >> CONCURRENTLY.
> >> > > >>
> >> > > >> If an invalid index depends on the constraint like
On Thu, Mar 7, 2013 at 7:19 AM, Andres Freund 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 latest version of
On Thu, Mar 7, 2013 at 8:21 AM, Kevin Grittner wrote:
> Fujii Masao wrote:
>> On Tue, Mar 5, 2013 at 7:36 AM, Kevin Grittner wrote:
>>> Fujii Masao wrote:
>>>
When I accessed the materialized view in the standby server,
>>>
I got the following ERROR message. Looks odd to me. Is this a
David E. Wheeler wrote:
> Kevin Grittner 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" everywhere. I wonder if most of th
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 0.0
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
stil
Alvaro Herrera 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, it'd be .. For
> f
2013/3/6 Tom Lane :
> 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. I don't think
On 6 March 2013 14:16, Tom Lane wrote:
> Simon Riggs writes:
>> On 5 March 2013 22:02, Tom Lane 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 => zero overhead => no problem.
>
> Well, in the fi
On Tue, Mar 5, 2013 at 5:37 PM, Alvaro Herrera 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.
>
> Now, one last thing
(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 Heik
42 matches
Mail list logo
