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 the
On Sat, Mar 7, 2015 at 10:18 PM, Tatsuo Ishii 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 delay -1945478837
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 DATABA
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 :
>
> Desirability -> Design -> Implement -> Test -> Review -> Commit
>
> This patch has continued in development without getting agreement on
> its Des
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 -1945
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 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 co
* 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
>
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
> t
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
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
Hi Robert,
2015-03-07 2:57 GMT+11:00 Robert Haas :
> 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, Marco is writing a too
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 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?
On that angle, I
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 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 the extra index p
Hi Bruce,
2015-03-08 5:37 GMT+11:00 Bruce Momjian :
>
> 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 until
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 expec
* 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 current
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
* 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,
>
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' confus
* 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 forma
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
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
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 bett
On 22/02/15 12:19, Pavel Stehule wrote:
2015-02-22 3:00 GMT+01:00 Petr Jelinek mailto:p...@2ndquadrant.com>>:
On 28/01/15 08:15, Pavel Stehule wrote:
2015-01-28 0:01 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>>:
On 1/27/15 4:36 AM, Pavel Stehule wrote:
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 o
* 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
* 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
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,
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 05/03/15 09:21, Amit Kapila wrote:
On Tue, Feb 17, 2015 at 3:29 AM, Petr Jelinek 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 heapgetpage (it maps to
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...
>>>
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 3/7/15 12:31 AM, Tom Lane wrote:
> > Peter Eisentraut 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
On 3/7/15 12:31 AM, Tom Lane wrote:
> Peter Eisentraut 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 usecatupd
On Tue, Mar 3, 2015 at 2:40 PM, Michael Paquier
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 provided by
Peter Eisentrau
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
37 matches
Mail list logo
