On Sat, Mar 7, 2015 at 12:52:15PM -0500, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
On Fri, Mar 6, 2015 at 07:00:10PM -0500, Stephen Frost wrote:
suggested to me as one change we could make that would reduce the risk
of disk-based attacks while trading that off for a
On Sat, Mar 7, 2015 at 12:49:15PM -0500, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
On Fri, Mar 6, 2015 at 07:02:36PM -0500, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
I think the best solution to this would be to introduce a per-cluster
salt
* Bruce Momjian (br...@momjian.us) wrote:
On Fri, Mar 6, 2015 at 07:02:36PM -0500, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
I think the best solution to this would be to introduce a per-cluster
salt that is used for every password hash. That way, you could not
On 04/03/15 23:51, Andreas Karlsson wrote:
On 01/29/2015 12:28 AM, Peter Geoghegan wrote:
* I'm not sure about the idea of polymorphic catalog functions (that
return the type internal, but the actual struct returned varying
based on build settings).
I tend to think that things would be better
On Thu, Mar 5, 2015 at 11:10:08AM -0500, Robert Haas wrote:
But I agree with Fujii to the extent that I see little value in
committing this patch in the form proposed. Being smart enough to use
the LSN to identify changed blocks, but then sending the entirety of
every file anyway because you
* Bruce Momjian (br...@momjian.us) wrote:
On Sat, Mar 7, 2015 at 12:49:15PM -0500, Stephen Frost wrote:
Ok, this is the incremented counter approach you brought up previously.
Using the term 'cluster-wide salt' confused me as I thought you were
referring to changing the on-disk format
On Fri, Mar 6, 2015 at 07:02:36PM -0500, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
On Fri, Mar 6, 2015 at 12:50:14PM -0800, Josh Berkus wrote:
On 03/06/2015 08:19 AM, Stephen Frost wrote:
Well, server-side, we already have that- have pgbouncer run on the
On Fri, Mar 6, 2015 at 07:00:10PM -0500, Stephen Frost wrote:
I'm also worried about both, but if the admin is worried about sniffing
in their environment, they're much more likely to use TLS than to set up
client side certificates, kerberos, or some other strong auth mechanism,
* Bruce Momjian (br...@momjian.us) wrote:
On Fri, Mar 6, 2015 at 07:00:10PM -0500, Stephen Frost wrote:
suggested to me as one change we could make that would reduce the risk
of disk-based attacks while trading that off for a higher risk on the
side of network-based attacks while not
On 05/03/15 09:21, Amit Kapila wrote:
On Tue, Feb 17, 2015 at 3:29 AM, Petr Jelinek p...@2ndquadrant.com
mailto:p...@2ndquadrant.com wrote:
I didn't add the whole page visibility caching as the tuple ids we
get from sampling methods don't map well to the visibility info we get
from
On 22/02/15 12:19, Pavel Stehule wrote:
2015-02-22 3:00 GMT+01:00 Petr Jelinek p...@2ndquadrant.com
mailto:p...@2ndquadrant.com:
On 28/01/15 08:15, Pavel Stehule wrote:
2015-01-28 0:01 GMT+01:00 Jim Nasby jim.na...@bluetreble.com
mailto:jim.na...@bluetreble.com:
* Peter Eisentraut (pete...@gmx.net) wrote:
On 3/7/15 12:31 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 12/29/14 7:16 PM, Adam Brightwell wrote:
Given this discussion, I have attached a patch that removes CATUPDATE
for review/discussion.
committed this version
Here is a v3, which (1) activates better error messages from bison
and (2) improves the error reporting from the scanner as well.
v4.
While adding a basic function call syntax to expressions, a noticed that
it would be useful to access the detail field of syntax errors so as to
report the
On 3/7/15 12:31 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 12/29/14 7:16 PM, Adam Brightwell wrote:
Given this discussion, I have attached a patch that removes CATUPDATE
for review/discussion.
committed this version
Hmm .. I'm not sure that summarily removing
Il 05/03/15 05:42, Bruce Momjian ha scritto:
On Thu, Mar 5, 2015 at 01:25:13PM +0900, Fujii Masao wrote:
Yeah, it might make the situation better than today. But I'm afraid that
many users might get disappointed about that behavior of an incremental
backup after the release...
I don't get
On Tue, Mar 3, 2015 at 2:40 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Those patches are really simple, but then perhaps there are better or
simpler ways than what is attached, so feel free to comment if you
have any ideas.
Attached are new patches somewhat based on the comments
On 3/7/15 12:48 AM, Noah Misch wrote:
On Sat, Mar 07, 2015 at 12:46:42AM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
On Thu, Mar 05, 2015 at 03:28:12PM -0600, Jim Nasby wrote:
I was thinking the simpler route of just repalloc'ing... the memcpy would
suck, but much less so than
On Sat, Mar 7, 2015 at 03:15:46PM -0500, Bruce Momjian wrote:
Gave me 9.15s, or ~0.00915s per connection on a single thread. That
times 16k is 146s or about two and a half minutes. Of course, I'm
comparing this against what we currently do since, well, that's what we
currently do.
On 2015-03-05 15:28:12 -0600, Jim Nasby wrote:
I was thinking the simpler route of just repalloc'ing... the memcpy would
suck, but much less so than the extra index pass. 64M gets us 11M tuples,
which probably isn't very common.
That has the chance of considerably increasing the peak memory
On 2015-03-07 16:43:15 -0600, Jim Nasby wrote:
Semi-related... if we put some special handling in some places for bootstrap
mode, couldn't most catalog objects be created using SQL, once we got
pg_class, pg_attributes and pg_type created? That would theoretically allow
us to drive much more of
On 3/7/15 4:49 PM, Andres Freund wrote:
On 2015-03-05 15:28:12 -0600, Jim Nasby wrote:
I was thinking the simpler route of just repalloc'ing... the memcpy would
suck, but much less so than the extra index pass. 64M gets us 11M tuples,
which probably isn't very common.
That has the chance of
Peter, all,
* Peter Eisentraut (pete...@gmx.net) wrote:
Why are we not using roles and function execute privileges for this?
Alright, I've got an initial patch to do this for pg_start/stop_backup,
pg_switch_xlog, and pg_create_restore_point. The actual backend changes
are quite small, as
* Bruce Momjian (br...@momjian.us) wrote:
On Sat, Mar 7, 2015 at 01:56:51PM -0500, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
Yes, I used the term cluster-wide salt in two cases: first,
cluster-wide counter for the MD5 session salt improvement, and second,
* Bruce Momjian (br...@momjian.us) wrote:
On Sat, Mar 7, 2015 at 03:15:46PM -0500, Bruce Momjian wrote:
Gave me 9.15s, or ~0.00915s per connection on a single thread. That
times 16k is 146s or about two and a half minutes. Of course, I'm
comparing this against what we currently do
On 3/4/15 9:07 AM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Mar 4, 2015 at 9:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
and make it harder to compare entries by grepping out some common
substring.
Could you give an example of the sort of thing you wish to do?
* Andrew Dunstan (and...@dunslane.net) wrote:
On 03/07/2015 05:46 PM, Andres Freund wrote:
On 2015-03-07 16:43:15 -0600, Jim Nasby wrote:
Semi-related... if we put some special handling in some places for bootstrap
mode, couldn't most catalog objects be created using SQL, once we got
On 3/7/15 6:02 PM, Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
On 03/07/2015 05:46 PM, Andres Freund wrote:
On 2015-03-07 16:43:15 -0600, Jim Nasby wrote:
Semi-related... if we put some special handling in some places for bootstrap
mode, couldn't most catalog objects be
On Sat, Mar 7, 2015 at 01:56:51PM -0500, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
On Sat, Mar 7, 2015 at 12:49:15PM -0500, Stephen Frost wrote:
Ok, this is the incremented counter approach you brought up previously.
Using the term 'cluster-wide salt' confused me as
Hi Bruce,
2015-03-08 5:37 GMT+11:00 Bruce Momjian br...@momjian.us:
Desirability - Design - Implement - Test - Review - Commit
This patch has continued in development without getting agreement on
its Desirability or Design, meaning we are going to continue going back
to those points
Hi Robert,
2015-03-07 2:57 GMT+11:00 Robert Haas robertmh...@gmail.com:
By the way, unless I'm missing something, this patch only seems to
include the code to construct an incremental backup, but no tools
whatsoever to do anything useful with it once you've got it.
As stated previously,
On 03/07/2015 05:46 PM, Andres Freund wrote:
On 2015-03-07 16:43:15 -0600, Jim Nasby wrote:
Semi-related... if we put some special handling in some places for bootstrap
mode, couldn't most catalog objects be created using SQL, once we got
pg_class, pg_attributes and pg_type created? That would
All,
pg_shadow, pg_user and pg_group were added when role support was added,
specifically for backwards compatibility. I don't believe there was
ever discussion about keeping them because filtering pg_roles based on
rolcanlogin was too onerous. That said, we already decided recently
that
When I set log_min_messages to debug5 and looked into walreciver log,
I saw this:
3600 2015-03-08 09:47:38 JST DEBUG: sendtime 2015-03-08 09:47:38.31493+09
receipttime 2015-03-08 09:47:38.315027+09 replication apply delay -1945478837
ms tran sfer latency 0 ms
The replication apply delay
On Sun, Mar 8, 2015 at 09:26:38AM +1100, Gabriele Bartolini wrote:
Hi Bruce,
2015-03-08 5:37 GMT+11:00 Bruce Momjian br...@momjian.us:
Desirability - Design - Implement - Test - Review - Commit
This patch has continued in development without getting agreement on
its
Hi,
I got wrong error message when I did REINDEX SYSTEM command in
transaction as follows.
It should say ERROR: REINDEX SYSTEM cannot run inside a transaction block
Attached patch fixes it.
[postgres][5432](1)=# begin;
BEGIN
[postgres][5432](1)=# reindex system postgres;
ERROR: REINDEX
On Sat, Mar 7, 2015 at 10:18 PM, Tatsuo Ishii is...@postgresql.org wrote:
When I set log_min_messages to debug5 and looked into walreciver log,
I saw this:
3600 2015-03-08 09:47:38 JST DEBUG: sendtime 2015-03-08
09:47:38.31493+09 receipttime 2015-03-08 09:47:38.315027+09 replication
apply
On 02/11/2015 07:34 PM, Emre Hasegeli wrote:
The current code compiles but the brin test suite fails.
Now, only a test in .
Yeah, there is still a test which fails in opr_sanity.
Yes but they were also required by this patch. This version adds more
functions and operators. I can split
37 matches
Mail list logo
