Hi,
I add checkpoint option to pgbench.
pgbench is simple and useful benchmark for every user. However, result of
benchmark greatly changes by some situations which are in executing checkpoint,
number of dirty buffers in share_buffers, and so on. For such a problem, it is
custom to carry out a ch
On 30/08/13 19:54, KONDO Mitsumasa wrote:
> Hi,
>
> I add checkpoint option to pgbench.
>
> pgbench is simple and useful benchmark for every user. However, result of
> benchmark greatly changes by some situations which are in executing
> checkpoint,
> number of dirty buffers in share_buffers, an
Le jeudi 29 août 2013 18:42:13 Stephen Frost a écrit :
> On Thursday, August 29, 2013, Andres Freund wrote:
> > If you don't want your installation to use it, tell you ops people not
> > to do so. They are superusers, they need to have the ability to follow
> > some rules you make up internally.
>
My patches option difinition is here.
[mitsu-ko@localhost pgbench]$ ./pgbench --help
~
-N, --no-checkpoint do not run CHECKPOINT after initialization
~
In latest commited pgbench, -N is "--skip-some-updates skip updates of
pgbench_tellers and pgbench_branches". But I cannot understand why
On 29/08 21.17, MauMau wrote:
>
> Thanks. I belive PostgreSQL runs successfully on Solaris 10 and later,
> because the binaries are published on the community site:
>
> http://ftp.postgresql.org/pub/binary/v9.3beta2/solaris/
Sorry, I didn't notice this thread earlier. Yes, I am building those
b
On 6 June 2013 17:28, Pavel Stehule wrote:
> 2013/6/6 Thom Brown :
> > Hi,
> >
> > When a statement is cancelled due to it running for long enough for
> > statement_timeout to take effect, it logs a message:
> >
> > ERROR: canceling statement due to statement timeout
> >
> > However, it doesn't
2013/8/29 Josh Berkus :
> Kaigai,
>
>> Although I didn't touch this task by myself, my senior colleague said that we
>> calculated some possible bandwidth of leakage as an evident when we ship
>> supercomputer system with MAC feature for customer who worry about security.
>> I'm not sure how to mea
2013/8/29 David Fetter :
> On Thu, Aug 29, 2013 at 10:05:14AM -0400, Tom Lane wrote:
>> Alexander Korotkov writes:
>> > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote:
>> >> It is out of scope for this feature. We usually calls this type
>> >> of information leakage "covert channel"; that is
2013/8/29 Tom Lane :
> Josh Berkus writes:
>>> That would close only one covert channel. Others were already pointed out
>>> upthread, and I'll bet there are more ...
>
>> Mind you, fundamentally this is no different from allowing INSERT
>> permission on a table but denying SELECT, or denying SEL
Stephen Frost writes:
> The OPs people are the ones that will be upset with this because the DBAs
> will be modifying configs which OPs rightfully claim as theirs.
If that's the problem you want to solve, there's no technical solution
that will put you at ease. That's a people and trust problem.
Hi,
On 2013-08-30 10:20:48 +0200, Cédric Villemain wrote:
> > > The energy wasted in a good part of this massive 550+ messages thread is
> > > truly saddening. We all (c|sh)ould have spent that time making PG more
> > > awesome instead.
> >
> > Perhaps not understood by all, but keeping PG awesom
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > The OPs people are the ones that will be upset with this because the DBAs
> > will be modifying configs which OPs rightfully claim as theirs.
>
> If that's the problem you want to solve, there's no technical solution
>
* Cédric Villemain (ced...@2ndquadrant.com) wrote:
> ALTER ROLE ALL may be good enougth to handle every GUC that we can also
> remove
> from postgresql.conf (I suppose all GUC needing only a reload, not a
> restart).
> It may needs some improvement to handle changing default for ALL and adding
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-08-30 10:20:48 +0200, Cédric Villemain wrote:
> > Grammar can be added later when the feature is stable.
>
> Could you explain the advantages of this? It will require users to get
> used to different interfaces and we will end up maintainin
On 2013-08-30 08:48:21 -0400, Stephen Frost wrote:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> > Stephen Frost writes:
> > > The OPs people are the ones that will be upset with this because the DBAs
> > > will be modifying configs which OPs rightfully claim as theirs.
> >
> > If that's
On 2013-08-29 21:26:48 -0400, Stephen Frost wrote:
> > Sure, you can construct a scenario where this matters. The ops guys
> > have "sudo postgres pg_ctl" access but adminpack isn't installed and
> > they have no other way to modify the configuration file. But that's
> > just bizarre. And if tha
Pavel Stehule writes:
> I was one who sent a bug report - this error is not too dangerous, but it
> is hidden, and difficult to find, if you don't know what can be happen.
> Same as bug with plpgsql and SQL identifier collisions. If you understand,
> then you can protect self well and simply. If
On Thu, Aug 29, 2013 at 9:12 PM, Stephen Frost wrote:
> You will not find me argueing to allow that in normal operation, or most
> direct-catalog hacking. I'd be much happier if we had all the ALTER,
> etc, options necessary to prevent any need to ever touch the catalogs.
> Similairly, it'd be ni
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-08-30 08:48:21 -0400, Stephen Frost wrote:
> > I really just don't buy that- I've already put forward suggestions for
> > how to deal with it, but no one here seems to understand the
> > distinction. Modifying listen_addresses through ALTER
On Fri, Aug 30, 2013 at 03:22:37AM +0300, Ants Aasma wrote:
> On Fri, Aug 30, 2013 at 3:02 AM, Andres Freund wrote:
> > I am not sure "hot cache large buffer performance" is really the
> > interesting case. Most of the XLogInsert()s are pretty small in the
> > common workloads. I vaguely recall tr
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-08-29 21:26:48 -0400, Stephen Frost wrote:
> > It's not the OPs guy that I'm worried about using ALTER SYSTEM- I don't
> > expect them to have any clue about it or care about it, except where it
> > can be used to modify things under /etc wh
wangs...@highgo.com.cn writes:
>In order to achieve enable/disable constraint nameï¼I made ââa
> few
> modifications to the code.
>First, someone used to build the constraints while building
> table. Then inserting data must follow a certain order.
>And people usuall
On 2013-08-30 09:19:42 -0400, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > On 2013-08-30 08:48:21 -0400, Stephen Frost wrote:
> > > I really just don't buy that- I've already put forward suggestions for
> > > how to deal with it, but no one here seems to understand the
On Thu, Aug 29, 2013 at 9:26 PM, Stephen Frost wrote:
>> In the first place, modifying postgresql.conf and not immediately
>> restarting the server to test your changes is probably the single most
>> basic DBA error imaginable.
>
> You're not modifying postgresql.conf with ALTER SYSTEM, now are yo
Tom Lane-2 wrote
> Pavel Stehule <
> pavel.stehule@
> > writes:
>> I was one who sent a bug report - this error is not too dangerous, but it
>> is hidden, and difficult to find, if you don't know what can be happen.
>> Same as bug with plpgsql and SQL identifier collisions. If you
>> understand,
On Fri, Aug 30, 2013 at 8:53 AM, Stephen Frost wrote:
> Yes, one of the issues with the existing system is that you can't
> specify a default to be applied to new roles. Also, there are
> parameters which are not per-role yet which it probably makes sense to
> be in the database and we'd need a w
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-08-30 09:19:42 -0400, Stephen Frost wrote:
> > wal_level and shared_buffers I can buy, but listen_addresses? The most
> > typical change there is going from localhost -> '*', but you've got to
> > be on the box to do that. Anything else an
KONDO Mitsumasa writes:
> My patches option difinition is here.
> [mitsu-ko@localhost pgbench]$ ./pgbench --help
> ~
> -N, --no-checkpoint do not run CHECKPOINT after initialization
> ~
> In latest commited pgbench, -N is "--skip-some-updates skip updates of
> pgbench_tellers and pgbench_bra
On 2013-08-30 09:43:01 -0400, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > On 2013-08-30 09:19:42 -0400, Stephen Frost wrote:
> > > wal_level and shared_buffers I can buy, but listen_addresses? The most
> > > typical change there is going from localhost -> '*', but yo
* Robert Haas (robertmh...@gmail.com) wrote:
> there's a fairly generous but fixed-at-startup-time limit on how many
> segments you can have. In practice I don't think this matters much,
> but it was a sobering reminder that the main shared memory segment,
> with all of its inflexibility, has impo
On Fri, Aug 30, 2013 at 9:19 AM, Stephen Frost wrote:
> You and Robert both seem to be of the opinion that this hack which
> brings postgresql.conf into the database via ALTER SYSTEM is a-ok
> because it's moving us "forward" in someone's mind, but it really is
> developing a system configuration
On 2013-08-30 06:34:47 -0700, David Johnston wrote:
> Tom Lane-2 wrote
> >> I was one who sent a bug report - this error is not too dangerous, but it
> >> is hidden, and difficult to find, if you don't know what can be happen.
> >> Same as bug with plpgsql and SQL identifier collisions. If you
> >>
* Andres Freund (and...@2ndquadrant.com) wrote:
> Technically trivial in the sense that it should be queryable from SQL
> without having to write code in an untrusted PL ;).
hah.
> I guess storing the file modification date along the file/location a GUC
> is originating from would be good enough.
On Fri, Aug 30, 2013 at 9:49 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> there's a fairly generous but fixed-at-startup-time limit on how many
>> segments you can have. In practice I don't think this matters much,
>> but it was a sobering reminder that the main shar
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Aug 30, 2013 at 8:53 AM, Stephen Frost wrote:
> > Yes, one of the issues with the existing system is that you can't
> > specify a default to be applied to new roles. Also, there are
> > parameters which are not per-role yet which it probably
David Johnston writes:
>>> If we alter syntax for mitigation purposes I'd want to consider requiring
>>> parentheses around the columns that belong to the ORDER BY instead of
>>> using the full extended syntax of WITHIN GROUP.
Unfortunately, that ORDER BY syntax is specified by the SQL standard,
Andres Freund-3 wrote
> On 2013-08-30 06:34:47 -0700, David Johnston wrote:
>> Tom Lane-2 wrote
>> >> I was one who sent a bug report - this error is not too dangerous, but
>> it
>> >> is hidden, and difficult to find, if you don't know what can be
>> happen.
>> >> Same as bug with plpgsql and SQL
Tom, all,
I'm not one to give up a fight (I hope that's something ya'll like
about me ;), but in this case I'm gonna have to concede. Clearly, I'm
in the minority about this, at least on the lists and among the active
hackers. Let me just say that I hope all the happy users of this will
* Robert Haas (robertmh...@gmail.com) wrote:
> I think you're getting way too hung up on the fact that the proposed
> auto.conf will be stored as a flat file. From your comments upthread,
> I gather that you'd be rejoicing if it were a table.
I'd be happy if it was a table which managed an *ind
2013/8/30 David Johnston
> Andres Freund-3 wrote
> > On 2013-08-30 06:34:47 -0700, David Johnston wrote:
> >> Tom Lane-2 wrote
> >> >> I was one who sent a bug report - this error is not too dangerous,
> but
> >> it
> >> >> is hidden, and difficult to find, if you don't know what can be
> >> happ
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I think you're getting way too hung up on the fact that the proposed
>> auto.conf will be stored as a flat file. From your comments upthread,
>> I gather that you'd be rejoicing if it were a table.
> I'd be happy if it was
Hi,
For the logical decoding patch I added support for pegging
RecentGlobalXmin (and GetOldestXmin) to a lower value. To avoid causing
undue bloat & cpu overhead (hot pruning is friggin expensive) I split
RecentGlobalXmin into RecentGlobalXmin and RecentGlobalDataXmin where
the latter is the the x
Hi,
I've attached a couple of the preliminary patches to $subject which I've
recently cleaned up in the hope that we can continue improving on those
in a piecemal fashion.
I am preparing submission of a newer version of the major patch but
unfortunately progress on that is slower than I'd like...
Hi,
On 2013-08-28 15:20:57 -0400, Robert Haas wrote:
> > That way any corruption in that area will prevent restarts without
> > reboot unless you use ipcrm, or such, right?
>
> The way I've designed it, no. If what we expect to be the control
> segment doesn't exist or doesn't conform to our exp
On 30.08.2013 19:01, Andres Freund wrote:
For the logical decoding patch I added support for pegging
RecentGlobalXmin (and GetOldestXmin) to a lower value. To avoid causing
undue bloat& cpu overhead (hot pruning is friggin expensive) I split
RecentGlobalXmin into RecentGlobalXmin and RecentGloba
On 30.08.2013 21:07, Heikki Linnakangas wrote:
On 30.08.2013 19:01, Andres Freund wrote:
For the logical decoding patch I added support for pegging
RecentGlobalXmin (and GetOldestXmin) to a lower value. To avoid causing
undue bloat& cpu overhead (hot pruning is friggin expensive) I split
RecentG
On 08/30/2013 03:05 AM, Kohei KaiGai wrote:
>> Surely someone in the security community has discussed this?
>>
> Security community considers covert channel is a hard to solve problem;
> nearly impossible to eliminate.
> Let's see the summary in wikipedia:
> http://en.wikipedia.org/wiki/Covert_c
On 2013-08-30 21:07:04 +0300, Heikki Linnakangas wrote:
> On 30.08.2013 19:01, Andres Freund wrote:
> >For the logical decoding patch I added support for pegging
> >RecentGlobalXmin (and GetOldestXmin) to a lower value. To avoid causing
> >undue bloat& cpu overhead (hot pruning is friggin expensiv
Hi Heikki,
On 2013-08-27 18:56:15 +0300, Heikki Linnakangas wrote:
> Here's an updated patch. The race conditions I mentioned above have been
> fixed.
Thanks for posting the new version!
I have a quick question: The reason I'd asked about the status of the
patch was that I was thinking about the
Uh ... why not just drop the constraint, and re-add it later if you want
it again?
My 0.02€ : maybe because you must keep track of the constraint details to
do so, this it is significantly more error prone than disable / enable
when the bookkeeping is done by the system and if everything is
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> On 08/30/2013 03:05 AM, Kohei KaiGai wrote:
> > Security community considers covert channel is a hard to solve problem;
> > nearly impossible to eliminate.
While impossible to eliminate, we should certainly consider cases like
this where we can do
Stephen Frost writes:
> We have issues with covert channels even without RLS though and holding
> up RLS because it doesn't fix all the covert channels isn't sensible.
I think it's entirely sensible to question whether we should reject (not
"hold up") RLS if it has major covert-channel problems.
On 08/30/2013 12:43 PM, Tom Lane wrote:
> In short, "we can check some check-box" is a really, really bad reason
> to accept a security-related feature. If we're going to put up with
> all the downsides of RLS, I want the end result to be something that's
> actually secure, not something that give
Josh Berkus writes:
> On 08/30/2013 12:43 PM, Tom Lane wrote:
>> In short, "we can check some check-box" is a really, really bad reason
>> to accept a security-related feature. If we're going to put up with
>> all the downsides of RLS, I want the end result to be something that's
>> actually secu
On 08/28/2013 11:44 AM, Josh Berkus wrote:
> Tom,
>
>> Does the backend's memory usage climb, or hold steady? If the former,
>> I'd bet on client failure to release resources, eg not closing the
>> portals when done with them. A memory map from MemoryContextStats
>> would help determine exactly
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > We have issues with covert channels even without RLS though and holding
> > up RLS because it doesn't fix all the covert channels isn't sensible.
>
> I think it's entirely sensible to question whether we should reject (not
> "hold
I noticed this while poking at the variadic-aggregates issue:
regression=# create function nth_value_def(anyelement, integer = 1) returns
anyelement language internal window immutable strict as 'window_nth_value';
CREATE FUNCTION
regression=# SELECT nth_value_def(ten) OVER (PARTITION BY four), te
For many years now, MySQL has a feature called INSERT IGNORE [1];
SQLite has INSERT ON CONFLICT IGNORE [2]; SQL Server has an option
called IGNORE_DUP_KEY and Oracle has a hint called
IGNORE_ROW_ON_DUPKEY_INDEX (they acknowledge that it's a bit odd that
a hint changes the semantics of a DML stateme
On Fri, Aug 30, 2013 at 6:14 PM, Tom Lane wrote:
> I noticed this while poking at the variadic-aggregates issue:
>
> regression=# create function nth_value_def(anyelement, integer = 1) returns
> anyelement language internal window immutable strict as 'window_nth_value';
> CREATE FUNCTION
> regres
On Thu, Aug 29, 2013 at 10:55 PM, Fujii Masao wrote:
> Attached patch adds new GUC parameter 'compress_backup_block'.
I think this is a great idea.
(This is not to disagree with any of the suggestions made on this
thread for further investigation, all of which I think I basically
agree with. Bu
Hackers,
The operator precedence rules seem hard wired to not be able to be
worked around, not matter what. The pain point for me has always been
the division operator -- once in a while I end up in a situation where
I want to override it so that it wraps the divisor with NULLIF. There
is no way
Robert Haas writes:
> On Fri, Aug 30, 2013 at 6:14 PM, Tom Lane wrote:
>> The reason this crashes is that the planner doesn't apply
>> default-insertion to WindowFunc nodes, only to FuncExprs.
> I'm not sure I agree. Under that approach, any functions that have
> already been created like that
On 08/30/2013 03:09 PM, Peter Geoghegan wrote:
> The attached WIP patch implements this for Postgres, with a few
> notable differences:
Thank you for addressing this. If nobody is going to hack out MERGE, we
could really use at least this feature.
> 3) RETURNING is expanded - "RETURNING REJECTS
On Fri, Aug 30, 2013 at 3:40 PM, Josh Berkus wrote:
> Does this work with multiple VALUES rows?
Yes.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Merlin Moncure writes:
> The operator precedence rules seem hard wired to not be able to be
> worked around, not matter what.
That's right. In the first place, bison is incapable of doing anything
other than hard-wired operator precedence. In the second, if we did
try to allow catalog-driven pr
Hi,
On 2013-08-30 17:35:04 -0500, Merlin Moncure wrote:
> "When a schema-qualified operator name is used in the OPERATOR syntax,
> as for example in:
> SELECT 3 OPERATOR(pg_catalog.+) 4;
> the OPERATOR construct is taken to have the default precedence shown
> in Table 4-2 for "any other" operator.
Hi,
This is awesome.
On 2013-08-30 15:09:59 -0700, Peter Geoghegan wrote:
> 1) The patch is only interested in unique index violations
> (specifically, violations of amcanunique access method unique
> indexes); it will not do anything with NULL constraint violations, as
> the MySQL feature does,
On Fri, Aug 30, 2013 at 5:47 PM, Andres Freund wrote:
> This is awesome.
Thanks.
> All that seems sane to me. I very, very much do not want it to deal with
> NOT NULL violations.
Sure. But there's nothing stopping us from doing that as a totally
orthogonal thing. Not that I personally find it t
Uh, the pg_dump part checks for version 80400, shouldn't it be 90400?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
Alvaro Herrera writes:
> Uh, the pg_dump part checks for version 80400, shouldn't it be 90400?
The reasoning there is that 8.4 is where we added
pg_get_function_arguments(), so this dumping code should work against that
server version or later. (Oh, memo to self: test that.) It's true that
pre-
2013/8/30 Josh Berkus :
> On 08/30/2013 03:05 AM, Kohei KaiGai wrote:
>
>>> Surely someone in the security community has discussed this?
>>>
>> Security community considers covert channel is a hard to solve problem;
>> nearly impossible to eliminate.
>> Let's see the summary in wikipedia:
>> http
On Fri, Aug 30, 2013 at 9:15 PM, Andres Freund wrote:
> Hi,
>
> On 2013-08-28 15:20:57 -0400, Robert Haas wrote:
>> > That way any corruption in that area will prevent restarts without
>> > reboot unless you use ipcrm, or such, right?
>>
>> The way I've designed it, no. If what we expect to be th
2013/8/30 Tom Lane :
> Josh Berkus writes:
>> On 08/30/2013 12:43 PM, Tom Lane wrote:
>>> In short, "we can check some check-box" is a really, really bad reason
>>> to accept a security-related feature. If we're going to put up with
>>> all the downsides of RLS, I want the end result to be someth
73 matches
Mail list logo
