Tom Lane wrote:
> Yeah, I think we need to preserve that property. Unexpectedly
> executing query (which may have side-effects) is a very dangerous
> thing. People are used to the idea that ANALYZE == execute, and
> adding random other flags that also cause execution is going to
> burn somebody
On Sat, Dec 24, 2011 at 03:56:58PM +, Simon Riggs wrote:
> > Also, as far as I can see this patch usurps the page version field,
> > which I find unacceptably short-sighted. Do you really think this is
> > the last page layout change we'll ever make?
>
> No, I don't. I hope and expect the nex
On Sun, Dec 25, 2011 at 04:25:19PM +0100, Martijn van Oosterhout wrote:
> On Sat, Dec 24, 2011 at 04:01:02PM +, Simon Riggs wrote:
> > On Sat, Dec 24, 2011 at 3:54 PM, Andres Freund wrote:
> > > Why don't you use the same tricks as the former patch and copy the buffer,
> > > compute the checks
Jeff Janes writes:
> I suspect we will be unwilling to make such a break with the past. In
> that case, I think I prefer the originally proposed semantics, even
> though I agree they are somewhat less natural. ANALYZE is a big flag
> that means "This query will be executed, not just planned". I
On Sat, Feb 04, 2012 at 03:41:27PM -0800, Jeff Davis wrote:
> On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
> > Yeah. Personally I would be sad if initdb got noticeably slower, and
> > I've never seen or heard of a failure that this would fix.
>
> I worked up a patch, and it looks like it do
Matthew Draper writes:
> [ sql-named-param-refs-v2.patch ]
Applied with some editorialization: I switched the behavior for two-part
names as discussed, and did some other mostly-cosmetic code cleanup,
and did some work on the documentation.
> I'm still not sure whether to just revise (almost) al
On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
> Yeah. Personally I would be sad if initdb got noticeably slower, and
> I've never seen or heard of a failure that this would fix.
I worked up a patch, and it looks like it does about 6 file fsync's and
a 7th for the PGDATA directory. That degra
* Tom Lane:
> I wonder whether it wouldn't be sufficient to call sync(2) at the end,
> anyway, rather than cluttering the entire initdb codebase with fsync
> calls.
We tried to do this in the Debian package mananger. It works as
expected on Linux systems, but it can cause a lot of data to hit th
Tom Lane wrote:
> What I was concerned about was the case where GUC is trying to
> re-establish an old value during transaction rollback. For example,
> assume we are superuser to start with, and we do
>
> begin;
> set role unprivileged_user;
> ...
> rollback;
>
> The rollback
On Wed, Feb 1, 2012 at 9:47 AM, Robert Haas wrote:
> On Wed, Jan 25, 2012 at 8:49 AM, Robert Haas wrote:
>> On Tue, Jan 24, 2012 at 4:28 PM, Simon Riggs wrote:
>>> I think we should be working to commit XLogInsert and then Group
>>> Commit, then come back to the discussion.
>>
>> I definitely ag
Hitoshi Harada writes:
> Ping. In case you don't have updates soon, I'll mark Returned with Feedback.
Pong. Sorry about my recent silence.
I've not been in a position to work on this recently, and am done with
those other duties now. I intend to be posting an updated patch soon
now. Please wa
Simon Riggs writes:
> The cause here is data changing underneath the user. Your patch solves
> the most obvious error, but it still allows other problems if applying
> the backup block changes data. If the backup block doesn't do anything
> at all then we don't need to apply it either.
This is no
On Sat, Feb 4, 2012 at 6:37 PM, Simon Riggs wrote:
> Patch to do that attached
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 99a431a
On Fri, Feb 3, 2012 at 6:45 AM, Tom Lane wrote:
> The reason it is relevant
> to our current problem is that even though RestoreBkpBlocks faithfully
> takes exclusive lock on the buffer, *that is not enough to guarantee
> that no one else is touching that buffer*. Another backend that has
> alre
On Sat, Feb 4, 2012 at 10:06 AM, Jeff Janes wrote:
> Attached is a completely uncommitable proof of concept/work in
> progress patch to get around the limitation. It shows a 2 fold
> improvement when indexing an integer column on a 50,000,000 row
> randomly ordered table.
Oops, forgot to say th
On Sat, Jan 21, 2012 at 4:51 PM, Peter Geoghegan wrote:
> On 16 January 2012 00:59, Jeff Janes wrote:
>> I think it would be better to pre-deduct the tape overhead amount we
>> will need if we decide to switch to tape sort from the availMem before
>> we even start reading (and then add it back if
"Kevin Grittner" writes:
> Tom Lane wrote:
>> More to the point, a GUC rollback transition *has to always
>> succeed*. Period.
> [ counterexample showing we should sometimes disallow "RESET" ]
This actually isn't what I was talking about: a RESET statement is a
commanded adoption of a new valu
Tom Lane wrote:
> More to the point, a GUC rollback transition *has to always
> succeed*. Period.
I was about to point out the exception of the transaction_read_only
GUC, which according to the standard must not be changed except at
the beginning of a transaction or a subtransaction, and must
On 01/24/2012 08:58 AM, Robert Haas wrote:
One somewhat odd thing about these numbers is that, on permanent
tables, all of the patches seemed to show regressions vs. master in
single-client throughput. That's a slightly difficult result to
believe, though, so it's probably a testing artifact of
On Fri, Feb 3, 2012 at 4:48 AM, Tom Lane wrote:
> I think saner behavior might only require this change:
>
> /*
> * Any unexpected exit (including FATAL exit) of the startup
> * process is treated as a crash, except that we don't want to
> * reinitia
On Mon, Jan 23, 2012 at 3:06 AM, Hitoshi Harada wrote:
> On Mon, Jan 23, 2012 at 2:00 AM, Dimitri Fontaine
> wrote:
>> Hitoshi Harada writes:
> - What happens if DROP EXTENSION ... CASCADE? Does it work?
It should, what happens when you try? :)
>>>
>>> I just tried DROP EXTENSION n
On Thu, Feb 2, 2012 at 3:19 PM, Tom Lane wrote:
> [ working on this patch now ... ]
>
> Matthew Draper writes:
>> On 25/01/12 18:37, Hitoshi Harada wrote:
>>> Should we throw an error in such ambiguity? Or did you make it happen
>>> intentionally? If latter, we should also mention the rule in the
On 16 January 2012 21:30, Josh Berkus wrote:
> Useful, yes. Harder than it looks, probably. I tried to mock up a
> version of this years ago for a project where I needed it, and ran into
> all kinds of race conditions.
Can you remember any details about those race conditions?
> Anyway, if it
On Sat, Feb 4, 2012 at 09:49, Jaime Casanova wrote:
> i little review...
Thanks! By the way, you should update to the v7 patch.
> first, i notice a change of behaviour... i'm not sure if i can say
> this is good or not.
> if you execute: select *, cached_random() from (select
> generate_series(
24 matches
Mail list logo
