Hi,
On 2012-12-23 02:36:42 -0500, Greg Smith wrote:
> I'm testing a checkout from a few days ago and trying to complete a day long
> pgbench stress test, with assertions and debugging on. I want to make sure
> the base code works as expected before moving on to testing checksums. It's
> crashing
On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane wrote:
> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
> though, as that seems like it'll guarantee that each session starts out
> with only a minimal amount of entropy.
No, that's actually the right fix - that forces OpenSSL to
On Fri, Dec 21, 2012 at 9:54 PM, Heikki Linnakangas
wrote:
> Yes, this should be backpatched to 9.2. I came up with the attached.
In this patch, if '-X stream' is specified in pg_basebackup, the timeline
history files are not backed up. We should change pg_backup background
process and walsender
On 22 December 2012 20:13, Kevin Grittner wrote:
> I apologize again for coming in so late with strong opinions, but I
> thought I knew what "row level security" meant, and it was just a
> question of how to do it, but I can't reconcile what I thought the
> feature was about with the patch I'm se
On Sat, Dec 22, 2012 at 4:07 AM, Phil Sorber wrote:
>
> Added new version with default verbose and quiet option. Also updated
> docs to reflect changes.
>
Thanks for the updated patches.
Here is the status about the binary patch:
- Code compiles without any warnings
- After testing the patch, it
On Sun, Dec 23, 2012 at 9:29 AM, Michael Paquier
wrote:
>
>
> On Sat, Dec 22, 2012 at 4:07 AM, Phil Sorber wrote:
>>
>>
>> Added new version with default verbose and quiet option. Also updated
>> docs to reflect changes.
>
> Thanks for the updated patches.
>
> Here is the status about the binary
On Fri, Dec 21, 2012 at 1:48 AM, Fujii Masao wrote:
> On Sat, Dec 15, 2012 at 9:36 AM, Fujii Masao wrote:
>> On Sat, Dec 8, 2012 at 12:51 AM, Heikki Linnakangas
>> wrote:
>>> On 06.12.2012 15:39, Amit Kapila wrote:
On Thursday, December 06, 2012 12:53 AM Heikki Linnakangas wrote:
>
On 20 December 2012 14:56, Amit Kapila wrote:
>> > 1. There is no performance change for cloumns that have all valid
>> > values(non- NULLs).
I don't see any tests (at all) that measure this.
I'm particularly interested in lower numbers of columns, so we can
show no regression for the common ca
On Sun, December 23, 2012 15:29, Michael Paquier wrote:
>
> Once the 2 small things I noticed are fixed, this patch can be marked as
> ready for committer.
I wasn't going to complain about it, but if we're going for small things
anyway...
The output is now capitalised:
/tmp:6543 - Accepting Con
On Sun, Dec 23, 2012 at 9:57 AM, Erik Rijkers wrote:
> On Sun, December 23, 2012 15:29, Michael Paquier wrote:
>>
>> Once the 2 small things I noticed are fixed, this patch can be marked as
>> ready for committer.
>
> I wasn't going to complain about it, but if we're going for small things
> anyw
On Sat, Dec 22, 2012 at 5:14 AM, Heikki Linnakangas
wrote:
> On 21.12.2012 21:43, Simon Riggs wrote:
>>
>> On 21 December 2012 19:35, Bruce Momjian wrote:
>>
It's not too complex. You just want that to be true. The original
developer has actually literally gone away, but not because of
On Sun, Dec 23, 2012 at 10:07 AM, Phil Sorber wrote:
> On Sun, Dec 23, 2012 at 9:57 AM, Erik Rijkers wrote:
>> On Sun, December 23, 2012 15:29, Michael Paquier wrote:
>>>
>>> Once the 2 small things I noticed are fixed, this patch can be marked as
>>> ready for committer.
>>
>> I wasn't going to
Simon Riggs writes:
> The lack of any space saving for lower % values is strange and
> somewhat worrying. There should be a 36? byte saving for 300 null
> columns in an 800 column table - how does that not show up at all?
You could only fit about 4 such rows in an 8K page (assuming the columns
ar
On 23 December 2012 17:38, Tom Lane wrote:
> Simon Riggs writes:
>> The lack of any space saving for lower % values is strange and
>> somewhat worrying. There should be a 36? byte saving for 300 null
>> columns in an 800 column table - how does that not show up at all?
>
> You could only fit abou
Andres Freund writes:
>> This is my first test like this against 9.3 development though, so the cause
>> could be an earlier commit. I'm just starting with the most recent work as
>> the first suspect. Next I think I'll try autovacuum=off and see if the
>> crash goes away. Other ideas are welco
2012/12/22 Kevin Grittner :
> Kohei KaiGai wrote:
>
>> RLS entry of wiki has not been updated for long time, I'll try to
>> update the entry for high-level design in a couple of days.
>
> Thanks, I think that is essential for a productive discussion of
> the issue.
>
I tried to update http://wiki.p
On 21 December 2012 16:51, Kevin Grittner wrote:
>> It would be easy enough to include read/write variable clauses by
>> using a function similar to TG_OP for triggers, e.g. StatementType.
>> That would make the security clause that applied only to reads into
>> something like this (StatementType
Simon Riggs writes:
> On 21 December 2012 16:51, Kevin Grittner wrote:
>> If none, and this is strictly an optimization, what are the benchmarks
>> showing?
> AFAIK its well known that a check constraint is much faster than a
> trigger.
I don't believe that that's "well known" at all, at least
On 23 December 2012 19:16, Tom Lane wrote:
> Simon Riggs writes:
>> On 21 December 2012 16:51, Kevin Grittner wrote:
>>> If none, and this is strictly an optimization, what are the benchmarks
>>> showing?
>
>> AFAIK its well known that a check constraint is much faster than a
>> trigger.
>
> I d
On 12/23/12 1:10 PM, Tom Lane wrote:
It might also be interesting to know if there is more than one
still-pinned buffer --- that is, if you're going to hack the code, fix
it to elog(LOG) each pinned buffer and then panic after completing the
loop.
Easy enough; I kept it so the actual source o
Marko Kreen writes:
> On Sat, Dec 22, 2012 at 9:20 PM, Tom Lane wrote:
>> I'm not thrilled with the suggestion to do RAND_cleanup() after forking
>> though, as that seems like it'll guarantee that each session starts out
>> with only a minimal amount of entropy.
> No, that's actually the right f
Noah Misch writes:
> On Sat, Dec 22, 2012 at 02:20:56PM -0500, Tom Lane wrote:
>> I believe that we'd be better off doing something in postmaster.c to
>> positively ensure that each session has a distinct seed value. Notice
>> that BackendRun() already takes measures to ensure that's the case for
Andres Freund writes:
> On 2012-12-22 14:20:56 -0500, Tom Lane wrote:
>> I believe that we'd be better off doing something in postmaster.c to
>> positively ensure that each session has a distinct seed value.
> I am entirely unconvinced that adding in a gettimeofday() provides more
> entropy than
On 23 December 2012 19:42, Greg Smith wrote:
> diff --git a/src/backend/storage/buffer/bufmgr.c
> b/src/backend/storage/buffer/bufmgr.c
> index dddb6c0..df43643 100644
> --- a/src/backend/storage/buffer/bufmgr.c
> +++ b/src/backend/storage/buffer/bufmgr.c
> @@ -1697,11 +1697,21 @@ AtEOXact_Buffer
On Fri, Dec 21, 2012 at 9:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm having a hard time following this. Can you provide a concrete example?
>
> regression=# create table t1 (x int, y int);
> CREATE TABLE
> regression=# create table t2 (x int, z int);
> CREATE TABLE
> regression=# create
On 12/23/12 3:17 PM, Simon Riggs wrote:
If that last change was the cause, then its caused within VACUUM. I'm
running a thrash test with autovacuums set much more frequently but
nothing yet.
I am not very suspicious of that VACUUM change; just pointed it out for
completeness sake.
Are you b
On 23 December 2012 21:52, Greg Smith wrote:
> On 12/23/12 3:17 PM, Simon Riggs wrote:
>>
>> If that last change was the cause, then its caused within VACUUM. I'm
>> running a thrash test with autovacuums set much more frequently but
>> nothing yet.
>
>
> I am not very suspicious of that VACUUM ch
On Fri, Dec 21, 2012 at 11:35 AM, Dimitri Fontaine
wrote:
> It's hard to devise exactly what kind of refactoring we need to do
> before trying to write a patch that benefits from it, in my experience.
> In some cases the refactoring will make things more complex, not less.
Perhaps. I have a feel
In some of my git branches I have
editorialized src/backend/utils/misc/postgresql.conf.sample to contain my
configuration preferences for whatever it is that that branch is for
testing. Then this gets copied to share/postgresql.conf.sample during
install and from there to data/postgresql.conf duri
Hi!
On 22.12.2012 17:15, Alexander Korotkov wrote:
> I'm not saying this is a perfect benchmark, but the differences (of
> querying) are pretty huge. Not sure where this difference comes from,
> but it seems to be quite consistent (I usually get +-10% results, which
> is negligible
On Sun, Dec 23, 2012 at 11:11 PM, Jeff Janes wrote:
> You could say that benchmarks should run long enough to average out such
> changes
I would say any benchmark needs to be run long enough to reach a
steady state before the measurements are taken. The usual practice is
to run a series groups an
On Sun, Dec 23, 2012 at 02:49:08PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Dec 22, 2012 at 02:20:56PM -0500, Tom Lane wrote:
> >> #ifdef USE_SSL
> >> if (EnableSSL)
> >> {
> >>struct timeval tv;
> >>
> >>gettimeofday(&tv, NULL);
> >>RAND_add(&tv, sizeof(tv), 0);
> >> }
On 20.12.2012 12:33, Andres Freund wrote:
> On 2012-12-20 02:54:48 +0100, Tomas Vondra wrote:
>> On 19.12.2012 02:18, Andres Freund wrote:
>>> On 2012-12-17 00:31:00 +0100, Tomas Vondra wrote:
>>>
>>> I think except of the temp buffer issue mentioned below its ready.
>>>
-DropRelFileNodeAllBuf
The following commit is causing some compilation errors.
c504513f83a9ee8dce4a719746ca73102cae9f13
Error:
../../../src/include/catalog/pg_aggregate.h:246: error: previous declaration
of AggregateCreate was here
make: *** [pg_aggregate.o] Error 1
Author: Robert Haas 2012-12-24 04:55
34 matches
Mail list logo
