Tom Lane wrote:
> You should take those out again; if I am the committer I certainly will.
> Such a test will guarantee complete instability of every other
> regression test, and it's not worth it.
I read the original comment was saying to add regression tests for
database-wide vacuums. But I'l
2009/12/7 Caleb Cushing :
>> no -
>>
>> "--" is line comment in SQL - it same like "//" in C++
>
> sorry didn't see this was updated. I know -- is a comment
>
> I mean in sql <> means NOT your function name is emptystr which
> implies it looks for an emptystr and returns true if the string is
> fou
Tom Lane wrote:
> Looks like auto_explain is under the illusion that it need not call
> ExplainBeginOutput/ExplainEndOutput.
They were added by XML formatter; I suppose it worked on 8.4.
Explain{Begin/End}Output are static functions, so we cannot call them
from an external contrib module. Inst
Tom Lane wrote:
> It was written and submitted by one person who did not bother to ask
> first whether anyone else thought it was worthwhile. So its presence
> on the CF list should not be taken as evidence that there's consensus
> for it.
Should we have "Needs Discussion" phase before "Needs
Euler Taveira de Oliveira writes:
> While testing the EXPLAIN BUFFERS patch I found a bug. I'm too tired to
> provide a fix right now but if someone can take it I will appreciate. It seems
> ExplainJSONLineEnding() doesn't expect es->grouping_stack list as a null
> pointer.
Looks like auto_expla
Euler Taveira de Oliveira wrote:
> I'm looking at your patch now... It is almost there but has some issues.
>
> (i) documentation: you have more than three counters and they could be
> mentioned in docs too.
I'll add documentation for all variables.
> (ii) format: why does text output format
Please find attached the latest version of the patch,
with the threading bug corrected and the documentation updated as well.
The origin of the bug was the alarm signal. Once the duration is over, all
the threads have to finish and timer_exceeded is set at true.
A control on this variable in setsh
Itagaki Takahiro writes:
> I added regression tests for database-wide vacuums and check changes
> of relfilenodes in those commands.
> ...
> BTW, I needed to add ORDER BY cluase in select_views test. I didn't modify
> tests in select_views at all, but database-wide vacuum moves tuples in
> select_
Greg Smith writes:
> Given the above, I don't understand why writing this patch was deemed
> worthwhile in the first place,
It was written and submitted by one person who did not bother to ask
first whether anyone else thought it was worthwhile. So its presence
on the CF list should not be take
Greg Smith writes:
> The biggest problem is that all of the places that used to say
> "" when talking about creating a cluster now just say
> "database cluster initialization"--with no link to a section covering
> that topic. That's not a good forward step. The part I'm more
> favorable towa
Hi,
While testing the EXPLAIN BUFFERS patch I found a bug. I'm too tired to
provide a fix right now but if someone can take it I will appreciate. It seems
ExplainJSONLineEnding() doesn't expect es->grouping_stack list as a null
pointer.
eu...@harman $ ./install/bin/psql
psql (8.5devel)
Type "hel
The threading bug appears when a duration is set for pgbench tests.
Instead of a duration, if a number of xacts is set, this error doesn't
happen.
If i understood the problem well, when the alarm signal comes, all the
threads have to disconnect even the ones looking for a setshell parameter at
thi
Itagaki Takahiro escreveu:
> The attached patch is rebased to current CVS.
>
I'm looking at your patch now... It is almost there but has some issues.
(i) documentation: you have more than three counters and they could be
mentioned in docs too.
+Include information on the buffers. Specificall
Jeff Davis writes:
> [ exclusion constraint patch ]
Applied after quite a lot of editorialization. For future reference,
here is a summary of what I did:
* Reworded and renamed stuff to try to be consistent about calling these
things "exclusion constraints". The original code and docs bore qui
Jaime Casanova wrote:
> On Sun, Dec 6, 2009 at 11:19 PM, Greg Smith wrote:
>> I just looked over the latest version of this patch and it seems to satisfy
>> all the issues suggested by the initial review. This looks like it's ready
>> for a committer from a quality perspective and I'm going to ma
Hi,
I took care of making the 3 cases you mentioned working in the new version
of the patch attached. It worked in my case for both shell and setshell
without any problem.
The code has also been reorganized so as to lighten the process in doCustom.
It looks cleaner on this part.
The only remainin
On Sun, Dec 6, 2009 at 11:19 PM, Greg Smith wrote:
> I just looked over the latest version of this patch and it seems to satisfy
> all the issues suggested by the initial review. This looks like it's ready
> for a committer from a quality perspective and I'm going to mark it as such.
>
yes. i ha
Greg Smith wrote:
> I just looked over the latest version of this patch and it seems to
> satisfy all the issues suggested by the initial review. This looks like
> it's ready for a committer from a quality perspective and I'm going to
> mark it as such.
Thanks for your efforts.
> I have a gue
Jeff Davis wrote:
On Mon, 2009-11-30 at 14:14 +0100, Joachim Wieland wrote:
I have a new version that deals with this problem but I need to clean
it up a bit. I am planning to post it this week.
Are planning to send a new version soon?
As it is, we're 12 days from the end of this comm
Magnus Hagander wrote:
On Sun, Nov 29, 2009 at 13:05, Magnus Hagander wrote:
I'll be happy to work on this to get it ready for commit, or do you
want to do the updates?
Here's a patch with my work so far. Major points missing is the
sanitizing of the username and the docs.
It looks
> no -
>
> "--" is line comment in SQL - it same like "//" in C++
sorry didn't see this was updated. I know -- is a comment
I mean in sql <> means NOT your function name is emptystr which
implies it looks for an emptystr and returns true if the string is
found to be empty (at least in my mind). s
I just looked over the latest version of this patch and it seems to
satisfy all the issues suggested by the initial review. This looks like
it's ready for a committer from a quality perspective and I'm going to
mark it as such.
I have a guess what some of the first points of discussion are go
On Sun, Dec 6, 2009 at 2:49 AM, Simon Riggs wrote:
> Proposal is to split out the couple of lines in
> readRecoveryCommandFile() that set important state and make it read in
> an option block that can be used by caller. It would then be called by
> both postmaster (earlier in startup) and again la
Robert Haas wrote:
The main point here for me is that the JSON format is already
parseable by YAML parsers, and can probably be turned into YAML using
a very short Perl script - possibly even using a sed script. I think
that it's overkill to support two formats that are that similar.
It's not
I just noticed that there was an updated patch here that never made its
way onto the CommitFest app listing. I just fixed that and took a quick
look at it. I was in favor of this code change, but I have to say even
I don't really like how it ended up getting documented--and I'm sure
there are
2009/12/7 Greg Smith :
> Which means that views created in the window test could absolutely cause the
> rules test to fail given a bad race condition. Either rules or window needs
> to be moved to another section of the test schedule. (I guess you could cut
> down the scope of "rules" to avoid th
Andrew Gierth wrote:
But what you have in the regression tests _now_ is, as far as I can
tell, only working by chance; with "rules" and "window" being in the
same parallel group, and window.sql creating a view, you have an
obvious race condition, unless I'm missing something.
You're right. ru
Hello there,
I am a graduate student at the University of Washington, Tacoma
(http://www.tacoma.washington.edu/tech/) with an interest in databases
(especially query processing). I am familiar with database theory and in an
earlier life I used to be an application developer and have done a lot o
On Sat, Dec 5, 2009 at 8:18 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > I offered to review it. ?I was going to mostly review the parts that
>> > impacted our existing code, and I wasn't going to be able to do a
>> > thorough job of the SE-Linux-specific files.
>>
>> Review it and commit it
Greg Smith wrote:
> I've marked Simon as the next reviewer and expected committer on this
> patch and have updated it to "Returned with Feedback".
OK. I'll re-submit improved patches in the next commit fest.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-h
> "Hitoshi" == Hitoshi Harada writes:
>> So for this and the regression test problem mentioned in the other
>> mail, I'm setting this back to "waiting on author".
Hitoshi> In my humble opinion, view regression test is not necessary
Hitoshi> in both my patch and yours. At least window tes
On Sun, Dec 6, 2009 at 8:34 PM, Itagaki Takahiro
wrote:
>
> Josh Berkus wrote:
>
>> Having compared the JSON and YAML output formats, I think having YAML as
>> a 2nd human-readable format might be valuable, even though it adds
>> nothing to machine-processing.
>
> Sure. YAML is human readable and
Josh Berkus wrote:
> Having compared the JSON and YAML output formats, I think having YAML as
> a 2nd human-readable format might be valuable, even though it adds
> nothing to machine-processing.
Sure. YAML is human readable and can print more information that is
too verbose in one-line text fo
Simon Riggs wrote:
I will review and eventually commit this, if appropriate, though it is
3rd in my queue and will probably not be done for at least 2 weeks,
possibly 4 weeks.
I've marked Simon as the next reviewer and expected committer on this
patch and have updated it to "Returned with Fee
After getting off to a good start, it looks like this patch is now stuck
waiting for a second review pass from Kevin right now, with no open
items for Andres to correct. Since the only issues on the table seem to
be that of code aesthetics and long-term planning for this style of
implementatio
Itagaki Takahiro wrote:
Greg Smith wrote:
I'm thinking that I should rename this new function
to pg_stat_reset_bgwriter so it's obvious how limited its target is.
I don't think it is a good name because we might have another cluster-level
statictics not related with bgwriter in the f
2009/12/7 Andrew Gierth :
>> "Hitoshi" == Hitoshi Harada writes:
>
> Hitoshi> Attached is updated version. I added AggGetMemoryContext()
> Hitoshi> in executor/nodeAgg.h (though I'm not sure where to go...)
> Hitoshi> and its second argument "iswindowagg" is output parameter to
> Hitoshi>
Next Tuesday was our target date for being finished with the current
CommitFest, and we're a little overdue to start kicking back a lot more
patches that still clearly need a whole additional round of work on
them. Here's how that's going to happen:
This Tuesday 12/8 at noon GMT, I'm going to
Greg Smith wrote:
> I'm thinking that I should rename this new function
> to pg_stat_reset_bgwriter so it's obvious how limited its target is.
I don't think it is a good name because we might have another cluster-level
statictics not related with bgwriter in the future. I hope you will suggest
Itagaki Takahiro wrote:
Greg Smith wrote:
-Not sure if this should be named pg_stat_rest_global (to match the way
these are called "global stats" in the source) or
pg_stat_reset_cluster. Picked the former for V1, not attached to that
decision at all. Might even make sense to use a name
Greg Smith wrote:
> This implements the TODO item "Allow the
> clearing of cluster-level statistics", based on previous discussion
> ending at http://archives.postgresql.org/pgsql-hackers/2009-03/msg00920.php
> -Not sure if this should be named pg_stat_rest_global (to match the way
> these a
On Sun, 2009-12-06 at 17:26 -0500, Robert Haas wrote:
> For what it's worth, this doesn't seem particularly unlikely or
> unusual to me.
I don't know many people who shutdown both nodes of a highly available
application at the same time. If they did, I wouldn't expect them to
complain they couldn
> "Hitoshi" == Hitoshi Harada writes:
Hitoshi> Attached is updated version. I added AggGetMemoryContext()
Hitoshi> in executor/nodeAgg.h (though I'm not sure where to go...)
Hitoshi> and its second argument "iswindowagg" is output parameter to
Hitoshi> know whether the call context is Agg
Le 6 déc. 2009 à 23:26, Robert Haas a écrit :
>>> Consider this scenario:
>>>
>>> 0. You have a master and a standby configured properly, and up and running.
>>> 1. You shut down master for some reason.
>>> 2. You restart standby. For some reason. Maybe by accident, or you want
>>> to upgrade mino
On Sun, Dec 6, 2009 at 3:06 PM, Simon Riggs wrote:
> On Sun, 2009-12-06 at 20:32 +0200, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>> > On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
>> >> 4. Need to handle the case where master is started up with
>> >> wal_standby_info=true, sh
On Sun, 2009-12-06 at 20:32 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
> >> 4. Need to handle the case where master is started up with
> >> wal_standby_info=true, shut down, and restarted with
> >> wal_standby_info=false, w
Jeff Davis writes:
> ... I'll look into doing it as you suggest.
I'm already working with a pretty-heavily-editorialized version.
Don't worry about it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On Sun, 2009-12-06 at 14:06 -0500, Tom Lane wrote:
> It fails for me regardless of which column is actually modified.
> It could be this is a consequence of other changes I've been making,
> but given the way ALTER TABLE works it's hard to see why the specific
> column being modified would matter.
Jeff Davis writes:
> Aha -- I think I see the problem you're having: if you try to rewrite
> one of the columns contained in the exclusion constraint, you get that
> error:
It fails for me regardless of which column is actually modified.
It could be this is a consequence of other changes I've bee
On Sun, 2009-12-06 at 10:46 -0500, Tom Lane wrote:
> This would be bad enough if the restriction were what the message
> alleges, ie, you can't write an ALTER TABLE that both rewrites the heap
> and adds an exclusion constraint. However, actually the error also
> occurs if you issue a rewriting AL
Simon Riggs wrote:
> On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
>
>> - When switching from standby mode to normal operation, we momentarily
>> hold all AccessExclusiveLocks held by prepared xacts twice, needing
>> twice the lock space. You can run out of lock space at that point,
Simon Riggs wrote:
> On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
>> 4. Need to handle the case where master is started up with
>> wal_standby_info=true, shut down, and restarted with
>> wal_standby_info=false, while the standby server runs continuously. And
>> the code in StartupXL
Jonas J wrote:
Buffer
ReadBuffer(Relation reln, BlockNumber blockNum)...
fprintf(fp,"Read Block n: %d\n",(int) blockNum);
The "key" as it were for database blocks read is both of the things
passed into ReadBuffer. You'd need to save both the Relation number
(which turns into the subdirecto
Simon Riggs writes:
> The purpose of this is to give an LOG message with a variable reason
> code. Should I worry about the translatability of something that exists
> for DEBUG,
Probably not. I don't even think you should use ereport, just elog
--- or if there's a good functional reason to use e
On Sun, 2009-12-06 at 10:51 +, Simon Riggs wrote:
> > 5. You removed this comment from KnownAssignedXidsAdd:
> >
> > - /*
> > -* XXX: We should check that we don't exceed maxKnownAssignedXids.
> > -* Even though the hash table might hold a few more entries than that,
> > -* we u
On Sun, 2009-12-06 at 10:26 -0500, Tom Lane wrote:
>
> > + /*
> > + * If we're running a SELECT, allow it. This ensures that a
> > + * write rule such as ON INSERT DO SELECT can be executed in
> > + * a read-only session.
> > + */
> > + if (plannedstmt->commandType == C
I have an ereport() in the HS patch that looks like this
ereport(trace_recovery(DEBUG1),
(errmsg("recovery cancels virtual transaction %u/%u pid %d because of
conflict with %s",
waitlist->backendId,
waitlist->localTransac
Simon Riggs writes:
> On Sun, 2009-12-06 at 10:26 -0500, Tom Lane wrote:
>> How would you "reroute" them without a non-read-only operation happening
>> somewhere along the line?
> I showed how in my example. The non-read-only operation happens on a
> remote server.
That seems awfully dubious fro
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
> - When switching from standby mode to normal operation, we momentarily
> hold all AccessExclusiveLocks held by prepared xacts twice, needing
> twice the lock space. You can run out of lock space at that point,
> causing failover to fai
Hi,
I'm a Computer Science student and I'm currently studying databases buffer
managers. I want to do some experiments and see how the pages access works
in PostgreSQL. (and I also will do some I/O experiments)
So, I want to do a "sniffer" on the Storage Layer of Postgresql. It should
work telli
Jeff Davis writes:
> [ exclusion constraints patch ]
Still working on this patch. I ran into something I didn't like at all:
> + if (newrel != NULL)
> + ereport(ERROR,
> + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> +
On Sun, 2009-12-06 at 10:26 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > I would like to allow RULEs ON INSERT, ON UPDATE and ON DELETE during
> > read only transactions iff they generate only SELECT statements that act
> > INSTEAD OF the actual event.
>
> I don't actually believe there is an
Simon Riggs writes:
> I would like to allow RULEs ON INSERT, ON UPDATE and ON DELETE during
> read only transactions iff they generate only SELECT statements that act
> INSTEAD OF the actual event.
I don't actually believe there is any use case for such a thing.
> This would be a small, but usef
Hannu Krosing writes:
> On Sun, 2009-12-06 at 07:58 +, Simon Riggs wrote:
>> Thanks. Looks like good input. With the further clarification that we
>> use NOTIFY it seems a solution is forming.
> If we use notify, then "the sufficiently smart client" (tm) should
> probably declared that it is
Simon Riggs writes:
> Having a special function that exists only for use in rare occasions
> seems like a great recipe for sporadic corruption, if we are taking the
> "paranoia seems justified" approach.
It used to be called all the time, before some of the more popular
paths got optimized into P
On Sun, 2009-12-06 at 11:20 +, Simon Riggs wrote:
> On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
>
> > 3. The "Out of lock mem killer" in StandbyAcquireAccessExclusiveLock is
> > quite harsh. It aborts all read-only transactions. It should be enough
> > to kill just one random
On Dec 6, 2009, at 2:58 AM, Simon Riggs wrote:
On Sat, 2009-12-05 at 18:13 -0700, James Pye wrote:
On Dec 5, 2009, at 12:25 PM, Simon Riggs wrote:
...
I'm not volunteering here, but having worked with the protocol, I
do have a suggestion:
Thanks. Looks like good input. With the further
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
> 3. The "Out of lock mem killer" in StandbyAcquireAccessExclusiveLock is
> quite harsh. It aborts all read-only transactions. It should be enough
> to kill just one random one, or maybe the one that's holding most locks.
> Also, if ther
Bruce Momjian wrote:
Peter Eisentraut wrote:
On m?n, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote:
I thought one problem was that inline is a suggestion that the compiler
can ignore, while macros have to be implemented as specified.
Sure, but one could argue that a compiler that doesn't supp
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
> 1. The XLogFlush() call you added to dbase_redo doesn't help where it
> is. You need to call XLogFlush() after the *commit* record of the DROP
> DATABASE. The idea is minimize the window where the files have already
> been deleted but t
I would like to allow RULEs ON INSERT, ON UPDATE and ON DELETE during
read only transactions iff they generate only SELECT statements that act
INSTEAD OF the actual event.
CREATE RULE foorah
AS ON INSERT TO foo
DO INSTEAD SELECT remote_insert(NEW.col1, NEW.col2, ...);
The above rule is curre
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
> 2. "Allow RULEs ON INSERT, ON UPDATE and ON DELETE iff they generate
> only SELECT statements that act INSTEAD OF the actual event." This
> affects any read-only transaction, not just hot standby, so I think this
> should be discussed
On Sun, 2009-12-06 at 07:58 +, Simon Riggs wrote:
> On Sat, 2009-12-05 at 18:13 -0700, James Pye wrote:
> > On Dec 5, 2009, at 12:25 PM, Simon Riggs wrote:
> > > ...
> >
> > I'm not volunteering here, but having worked with the protocol, I do have a
> > suggestion:
>
> Thanks. Looks like goo
1. The XLogFlush() call you added to dbase_redo doesn't help where it
is. You need to call XLogFlush() after the *commit* record of the DROP
DATABASE. The idea is minimize the window where the files have already
been deleted but the entry in pg_database is still visible, if someone
kills the standb
Tom Lane wrote:
Kurt Harriman writes:
(Does anybody still use a C compiler that doesn't support
inline functions?)
The question isn't so much that, it's whether the compiler supports
inline functions with the same behavior as gcc.
With this patch, if the compiler doesn't accept the "inli
Just noticed that PageIndexTupleDelete does not check that
pd_special != MAXALIGN(pd_special)
whereas PageIndexMultiDelete() does this. Both routines state that
"paranoia seems justified", so this omission looks like an error.
Looking a little deeper at this...
We only call PageIndexTu
On Sat, 2009-12-05 at 22:56 +0200, Heikki Linnakangas wrote:
> So that RecordKnownAssignedTransactionIds() call needs to be put back.
OK
> BTW, if you want to resurrect the check in KnownAssignedXidsRemove(),
> you also need to not complain before you reach the running-xacts record
> and open up
77 matches
Mail list logo
