> 4 марта 2015 г., в 19:28, Bruce Momjian написал(а):
>
> On Wed, Mar 4, 2015 at 01:53:47PM +0300, Vladimir Borodin wrote:
>>After running initdb to create the new master, but before running
>>pg_upgrade, modify the new master's postgresql.conf and change wal_level
>>= hot_standby.
On Thu, Mar 5, 2015 at 12:54 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
>> wrote:
>> > Hm, why not. That would remove all inconsistencies between the parser
>> > and the autovacuum code path. Perhaps something like th
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 what do you mean here. Can you
On Thu, Mar 5, 2015 at 1:59 AM, Marco Nenciarini
wrote:
> Hi Fujii,
>
> Il 03/03/15 11:48, Fujii Masao ha scritto:
>> On Tue, Mar 3, 2015 at 12:36 AM, Marco Nenciarini
>> wrote:
>>> Il 02/03/15 14:21, Fujii Masao ha scritto:
On Thu, Feb 12, 2015 at 10:50 PM, Marco Nenciarini
wrote:
>>>
> On Wed, Mar 4, 2015 at 4:41 AM, David Rowley wrote:
> >> This thread mentions "parallel queries" as a use case, but that means
> >> passing data between processes, and that requires being able to
> >> serialize and deserialize the aggregate state somehow. For actual data
> >> types that's not ov
On 03/04/2015 10:37 PM, Peter Eisentraut wrote:
On 2/15/15 6:55 AM, Michael Paquier wrote:
I tested quickly the second patch with MS 2010 and I am getting a
build failure: chkpass cannot complete because of crypt missing. On
master build passes. More details here:
"C:\Users\mpaquier\git\postgre
Peter Eisentraut writes:
> Any other opinions?
> The options are:
> 0) Leave as is.
> 1) Remove catupdate and replace with superuser checks.
> 2) Remove catupdate and rely on regular table permissions on catalogs.
I think I vote for (1). I do not like (2) because of the argument I made
upthread
On 2/15/15 6:55 AM, Michael Paquier wrote:
> I tested quickly the second patch with MS 2010 and I am getting a
> build failure: chkpass cannot complete because of crypt missing. On
> master build passes. More details here:
> "C:\Users\mpaquier\git\postgres\pgsql.sln" (default target) (1) ->
> "C:\U
Peter Eisentraut writes:
> On 2/13/15 10:20 AM, Teodor Sigaev wrote:
>> Some of users of intarray contrib module wish to use its features with
>> another kind of arrays, not only for int4 type. Suggested module
>> generalizes intarray over other (not all) types op pgsql.
> I think this module sho
On 2/15/15 3:41 AM, David G Johnston wrote:
> Otherwise it seems fine but I cannot help but feel that false positives are
> possible; though nothing that doesn't already exist. Mainly, is the change
> going to end up only affect the reset or default value but not the currently
> active value?
I d
On 2/17/15 10:45 AM, Robert Haas wrote:
> You don't really need the "else" here, and in parallel cases:
>
> if (*conf->variable != newval)
> {
> +record->status |= GUC_PENDING_RESTART;
> ereport(elevel,
>
Any other opinions?
The options are:
0) Leave as is.
1) Remove catupdate and replace with superuser checks.
2) Remove catupdate and rely on regular table permissions on catalogs.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 2/13/15 10:20 AM, Teodor Sigaev wrote:
> Some of users of intarray contrib module wish to use its features with
> another kind of arrays, not only for int4 type. Suggested module
> generalizes intarray over other (not all) types op pgsql.
>
> Anyarray also provides a calculation of similarity t
On 2/28/15 10:10 PM, Stephen Frost wrote:
> Adam,
>
> * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
>> I have attached and updated patch for review.
>
> Thanks! I've gone over this and made quite a few documentation and
> comment updates, but not too much else, so I'm prett
On 3/3/15 5:29 PM, Stephen Frost wrote:
> For my part, I understood that we specifically didn't want to allow that
> for the same reason that we didn't want to simply depend on the GRANT
> system for the above functions, but everyone else on these discussions
> so far is advocating for using the GR
On 3/3/15 5:58 PM, Tom Lane wrote:
> Stephen Frost writes:
>> It's not a documented policy but it's certainly what a whole slew of
>> functions *do*. Including pg_start_backup, pg_stop_backup,
>> pg_switch_xlog, pg_rotate_logfile, pg_create_restore_point,
>> pg_xlog_replay_pause, lo_import, lo_ex
On Wed, Mar 4, 2015 at 05:56:25PM -0800, Josh Berkus wrote:
> Catching up here ...
>
> On 03/03/2015 06:01 PM, Bruce Momjian wrote:
> > It feels like MD5 has accumulated enough problems that we need to start
> > looking for another way to store and pass passwords. The MD5 problems
> > are:
> >
On 3/2/15 4:47 PM, Robert Haas wrote:
> On Sat, Feb 28, 2015 at 12:27 AM, Stephen Frost wrote:
>> While this generally "works", the usual expectation is that functions
>> that should be superuser-only have a check in the function rather than
>> depending on the execute privilege. I'm certainly ha
On 3/4/15 5:00 PM, Robert Haas wrote:
>> You can always test the server version number, and you'll have to for
>> the next major release anyway.
>
> That's not really the problem, of course. The problem is you upgrade
> and your app unexpectedly breaks. The complexity of fixing that once
> it's
Catching up here ...
On 03/03/2015 06:01 PM, Bruce Momjian wrote:
> It feels like MD5 has accumulated enough problems that we need to start
> looking for another way to store and pass passwords. The MD5 problems
> are:
>
> 1) MD5 makes users feel uneasy (though our usage is mostly safe)
>
> 2
> Here is v4 patch of Join push-down support for foreign tables. This
> patch requires Custom/Foreign join patch v7 posted by Kaigai-san.
>
Thanks for your efforts,
> In this version I added check about query type which gives up pushing
> down joins when the join is a part of an underlying query
On March 4, 2015 11:08:09 PM Andres Freund wrote:
> Let's get the basic feature (notification of failed reloads) done
> first. That will be required with or without including the error
> message. Then we can get more fancy later, if somebody really wants to
> invest the time.
Except for also fixi
I'm seeing this on a the master branch tip when building at -O2:
pg_conversion.c: In function ‘ConversionCreate’:
pg_conversion.c:53:6: error: variable ‘oid’ set but not used
[-Werror=unused-but-set-variable]
Oid oid;
^
cc1: all warnings being treated as errors
I think that commit a2e35
On Tue, Mar 3, 2015 at 7:14 PM, Peter Geoghegan wrote:
> My patch actually matches Andrew Gierth's datumsort patch, in that it
> also uses this convention, as I believe it should. For that reason,
> I'd prefer to make the comment added in November true, rather than
> changing the comment...I feel
On Wed, Mar 4, 2015 at 04:19:00PM -0500, Stephen Frost wrote:
> > Hm, well, "don't change the wireline protocol" could be another wanna-have
> > ... but if we want to stop using MD5, that's not really a realistic goal
> > is it?
>
> I'm trying to address both sides of the issue- improve the curre
On Wed, Mar 4, 2015 at 03:59:02PM -0500, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Bruce Momjian writes:
> > > Let me update my list of possible improvements:
> >
> > > 1) MD5 makes users feel uneasy (though our usage is mostly safe)
> >
> > > 2) The per-session salt s
On Wed, Mar 4, 2015 at 03:54:09PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Let me update my list of possible improvements:
>
> > 1) MD5 makes users feel uneasy (though our usage is mostly safe)
>
> > 2) The per-session salt sent to the client is only 32-bits, meaning
> > that it is
Hi Tomas and others,
2015-03-02 21:29 GMT+01:00 Tomas Vondra :
> Hi David ;-)
>
> On 2.3.2015 20:19, David Kubečka wrote:
> >
> > The question is why optimizer, or rather the cost estimator,
> > produced so much different estimates upon very small change in input.
> > Moreover it seems that the m
On 01/29/2015 12:28 AM, Peter Geoghegan wrote:
On Mon, Jan 26, 2015 at 11:21 PM, Andreas Karlsson wrote:
Do you also think the SQL functions should be named numeric_int128_sum,
numeric_int128_avg, etc?
Some quick review comments. These apply to int128-agg-v5.patch.
* Why is there no declarat
On 2015-03-04 19:04:02 -0300, Alvaro Herrera wrote:
> This becomes pretty complicated for a PID file, mind you.
Yes.
Let's get the basic feature (notification of failed reloads) done
first. That will be required with or without including the error
message. Then we can get more fancy later, if so
* Robert Haas (robertmh...@gmail.com) wrote:
> So, the server can only authenticate the user with the salts it has
> stored, because those are the only salts for which it knows what the
> response should be?
That's correct- except that it doesn't directly know what the response
is, it only knows
Peter Eisentraut wrote:
> On 3/3/15 7:34 PM, Jim Nasby wrote:
> > Definitely no multi-line. If we keep that restriction, couldn't we just
> > dedicate one entire line to the error message? ISTM that would be safe.
>
> But we have multiline error messages. If we put only the first line in
> the pi
On Wed, Mar 4, 2015 at 4:11 PM, Peter Eisentraut wrote:
> That said, if I understand your test case correctly, this would
> basically be an argument against any semantic corrections in stable
> releases, since user code could expect to continue to work with the
> previous incorrect value.
>
> You
On Wed, Mar 4, 2015 at 10:52 AM, Stephen Frost wrote:
> I've been discussing this with a few folks outside of the PG community
> (Debian and Openwall people specifically) and a few interesting ideas
> have come out of that which might be useful to discuss.
>
> The first is a "don't break anything"
On 3/3/15 7:34 PM, Jim Nasby wrote:
> Definitely no multi-line. If we keep that restriction, couldn't we just
> dedicate one entire line to the error message? ISTM that would be safe.
But we have multiline error messages. If we put only the first line in
the pid file, then all the tools that buil
On 3/3/15 11:11 AM, Bruce Momjian wrote:
> On Tue, Mar 3, 2015 at 10:58:28AM -0500, Bruce Momjian wrote:
>>> Would you suggest removing the automated system completely, or keep it
>>> around
>>> and just make it possible to override it (either by removing the note that
>>> something is a patch, o
On 3/3/15 7:17 PM, Jim Nasby wrote:
> I think we're screwed in that regard anyway, because of the special
> constructs. You'd need different logic to handle things like +role and
> sameuser. We might even end up painted in a corner where we can't change
> it in the future because it'll break everyo
On Wed, Mar 4, 2015 at 2:27 PM, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>> On 03/04/2015 09:51 AM, Robert Haas wrote:
>> >On Wed, Mar 4, 2015 at 9:06 AM, Peter Eisentraut wrote:
>> >>>and make it harder to compare entries by grepping out some common
>> >>>substring.
>> >>Could you give an e
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> What happened to "possession of the contents of pg_authid is sufficient
> >> to log in"? I thought fixing that was one of the objectives here.
>
> > Yes, it certainly was. I think Bruc
Indeed. Here is a v2.
Here is a v3, which (1) activates better error messages from bison
and (2) improves the error reporting from the scanner as well.
sh> ./pgbench -f bad.sql
bad.sql:3: syntax error at column 23 in command "set"
\set aid (1021 * :id) %
^ error fou
On 3/4/15 12:20 PM, Marko Tiikkaja wrote:
> On 3/4/15 6:19 PM, I wrote:
>> On 3/4/15 5:26 PM, Tom Lane wrote:
>>> It was considered to be a bug fix; more, given the few complaints about
>>> the clearly-broken old behavior, we thought it was a fix that would
>>> affect
>>> few people, and them posit
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> What happened to "possession of the contents of pg_authid is sufficient
>> to log in"? I thought fixing that was one of the objectives here.
> Yes, it certainly was. I think Bruce was thinking that we could simply
> hash what goe
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Bruce Momjian writes:
> > Let me update my list of possible improvements:
>
> > 1) MD5 makes users feel uneasy (though our usage is mostly safe)
>
> > 2) The per-session salt sent to the client is only 32-bits, meaning
> > that it is possible to reply a
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 02:46:54PM -0500, Stephen Frost wrote:
> > > Well, passwords are already addressed by certificate authentication, so
> > > what's your point? I think we decided we wanted a way to do passwords
> > > without requiring network encry
Bruce Momjian writes:
> Let me update my list of possible improvements:
> 1) MD5 makes users feel uneasy (though our usage is mostly safe)
> 2) The per-session salt sent to the client is only 32-bits, meaning
> that it is possible to reply an observed MD5 hash in ~16k connection
> attempts.
>
On Wed, Mar 4, 2015 at 02:46:54PM -0500, Stephen Frost wrote:
> > Well, passwords are already addressed by certificate authentication, so
> > what's your point? I think we decided we wanted a way to do passwords
> > without requiring network encryption.
>
> It's completely unclear to me what you
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost wrote:
> > No, I'm not suggesting that OpenSSL or TLS become mandatory but was
> > thinking it might be good alternative as a middle-ground between full
> > client-and-server side certificates and straig
On 3/4/15 9:51 AM, Robert Haas wrote:
> On Wed, Mar 4, 2015 at 9:06 AM, Peter Eisentraut 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?
>
> e.g. grep for a function name and check tha
On Wed, Mar 4, 2015 at 02:21:51PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Wed, Mar 4, 2015 at 01:27:32PM -0500, Stephen Frost wrote:
> > > This further makes what is sent over the network not directly
> > > susceptible to a replay attack because the server h
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 02:21:51PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Wed, Mar 4, 2015 at 01:27:32PM -0500, Stephen Frost wrote:
> > > > This further makes what is sent over the network not directly
> > > >
Andrew Dunstan wrote:
>
> On 03/04/2015 09:51 AM, Robert Haas wrote:
> >On Wed, Mar 4, 2015 at 9:06 AM, Peter Eisentraut 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?
> >e.g. grep fo
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 01:27:32PM -0500, Stephen Frost wrote:
> > This further makes what is sent over the network not directly
> > susceptible to a replay attack because the server has multiple values
> > available to pick for the salt to use and sends
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> I'm not sure how expensive a brute force attack on SRP would be,
> using a stolen backup tape. There doesn't seem to be an iterations
> count similar to SCRAM. But note that SRP's resistance to
> brute-forcing the authentication handshake is of a diff
On 03/04/2015 08:59 PM, Stephen Frost wrote:
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
The big difference between SRP and SCRAM is that if you eavesdrop
the SCRAM handshake, you can use that information to launch a
brute-force or dictionary attack. With SRP, you cannot do that. That
makes it
On Wed, Mar 4, 2015 at 01:27:32PM -0500, Stephen Frost wrote:
> This further makes what is sent over the network not directly
> susceptible to a replay attack because the server has multiple values
> available to pick for the salt to use and sends one at random to the
> client, exactly how our cur
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> The big difference between SRP and SCRAM is that if you eavesdrop
> the SCRAM handshake, you can use that information to launch a
> brute-force or dictionary attack. With SRP, you cannot do that. That
> makes it relatively safe to use weak passwords w
Kyotaro HORIGUCHI wrote:
> The performance which your test shows looks great. The gain might
> comes from removing of buffer locking on _bt_next.
Yeah, I had been hoping that removing some buffer pins and locks
from the common path of scanning forward from one page to the next
might have some di
On Wed, Mar 4, 2015 at 8:26 AM, Robert Haas wrote:
> I think we should commit my patch, and if a future patch needs
> sortKeys set in more places, it can make that change itself. There's
> no reason why it's needed with the code as it is today, and no reason
> to let bits of future changes leak i
On 03/04/2015 06:11 PM, Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost wrote:
No, I'm not suggesting that OpenSSL or TLS become mandatory but was
thinking it might be good alternative as a middle-ground between full
client-and-
On 03/04/2015 04:52 PM, Stephen Frost wrote:
> Bruce, all,
>
> I've been discussing this with a few folks outside of the PG community
> (Debian and Openwall people specifically) and a few interesting ideas
> have come out of that which might be useful to discuss.
>
> The first is a "don't break a
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 12:43:54PM -0500, Stephen Frost wrote:
> > > What does storing multiple hash(password || stoarage_salt) values do for
> > > us that session_salt doesn't already do?
> >
> > By storing a hash of the result of the challenge/response
On Tue, Mar 3, 2015 at 1:42 PM, Josh Berkus wrote:
>>> Sure. Although, do we take (s) for tcp_keepalives_idle? Or only an INT?
>>
>> It's a "time unit", so you can say "10s" or "1ms". If you don't
>> specify a unit, it implies seconds.
>
> So if we're going to make this consistent, let's mak
On Tue, Mar 3, 2015 at 7:57 PM, Tom Lane wrote:
> Now, if we were to change the server so that it *refused* settings that
> didn't have a unit, that argument would become moot. But I'm not going
> to defend the castle against the villagers who will show up if you do
> that.
That might be somethi
On Wed, Mar 4, 2015 at 12:43:54PM -0500, Stephen Frost wrote:
> > What does storing multiple hash(password || stoarage_salt) values do for
> > us that session_salt doesn't already do?
>
> By storing a hash of the result of the challenge/response, we wouldn't
> be susceptible to attacks where the
* Stephen Frost (sfr...@snowman.net) wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:
> > > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > > On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> > > > > * Andres Freund (and.
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:
> > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> > > > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > > > On 2015-03-04 10:
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Mar 4, 2015 at 10:52:30AM -0500, Stephen Frost wrote:
> > The first is a "don't break anything" approach which would move the
> > needle between "network data sensitivity" and "on-disk data sensitivity"
> > a bit back in the direction of making t
On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> > > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > > On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:
> > > > > The firs
On Wed, Mar 4, 2015 at 10:52:30AM -0500, Stephen Frost wrote:
> The first is a "don't break anything" approach which would move the
> needle between "network data sensitivity" and "on-disk data sensitivity"
> a bit back in the direction of making the network data more sensitive.
>
> this approach
On 3/4/15 6:19 PM, I wrote:
On 3/4/15 5:26 PM, Tom Lane wrote:
It was considered to be a bug fix; more, given the few complaints about
the clearly-broken old behavior, we thought it was a fix that would affect
few people, and them positively.
Yeah, but these things usually go the other way. "
On 3/4/15 5:26 PM, Tom Lane wrote:
Robert Haas writes:
On Thu, Feb 19, 2015 at 5:53 AM, Marko Tiikkaja wrote:
I'm not sure how changing behavior like this in a minor release was
considered acceptable.
I'm guessing that the fact that it changes behavior in cases like this
wasn't recognized,
On Wed, Mar 4, 2015 at 01:53:47PM +0300, Vladimir Borodin wrote:
> After running initdb to create the new master, but before running
> pg_upgrade, modify the new master's postgresql.conf and change wal_level
> = hot_standby. (Don't modify pg_hba.conf at this stage.)
>
>
>
> That do
On 2015-03-04 08:41:23 -0800, Jeff Janes wrote:
> Couldn't we just arbitrarily exclude sequence internal states from the
> comparison?
Not sure what you mean? You mean just not dump them? I guess we could by
editing the contents of a custom format dump? A bit annoying to have a
script doing that..
Hi Fujii,
Il 03/03/15 11:48, Fujii Masao ha scritto:
> On Tue, Mar 3, 2015 at 12:36 AM, Marco Nenciarini
> wrote:
>> Il 02/03/15 14:21, Fujii Masao ha scritto:
>>> On Thu, Feb 12, 2015 at 10:50 PM, Marco Nenciarini
>>> wrote:
Hi,
I've attached an updated version of the patch.
>>>
On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas
wrote:
> In the original post on this, you mentioned that the PostGIS guys planned to
> use this to store polygons, as bounding boxes
> (http://www.postgresql.org/message-id/5447b3ff.2080...@sigaev.ru). Any idea
> how would that work?
Poorly, by
On Thu, Feb 19, 2015 at 5:53 AM, Marko Tiikkaja wrote:
> Hi,
>
> Commit 79af9a1d2668c9edc8171f03c39e7fed571eeb98 changed xpath handling
> with regard to namespaces, and it seems to be fixing an actual issue.
> However, it was also backpatched to all branches despite it breaking for
> example code
As I mentioned on the other thread, I'd really like to get this into a
better format, where each error message is on one line. Looking at
that, you can't tell whether you've got one mistake, two mistakes, or
three mistakes.
Indeed. Here is a v2.
sh> ./pgbench -f bad.sql
bad.sql:3: syntax
On Tue, Mar 3, 2015 at 7:49 AM, Andres Freund
wrote:
> Hi,
>
> I've regularly wished we had automated tests that setup HS and then
> compare primary/standby at the end to verify replay worked
> correctly.
>
> Heikki's page comparison tools deals with some of that verification, but
> it's really q
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:
> > > > The first is a "don't break anything" approach which would move the
> > > > needl
Robert Haas writes:
> On Thu, Feb 19, 2015 at 5:53 AM, Marko Tiikkaja wrote:
>> I'm not sure how changing behavior like this in a minor release was
>> considered acceptable.
> I'm guessing that the fact that it changes behavior in cases like this
> wasn't recognized, but I suppose Peter will hav
On Thu, Feb 19, 2015 at 5:53 AM, Marko Tiikkaja wrote:
> Commit 79af9a1d2668c9edc8171f03c39e7fed571eeb98 changed xpath handling with
> regard to namespaces, and it seems to be fixing an actual issue. However, it
> was also backpatched to all branches despite it breaking for example code
> like thi
On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:
> > > The first is a "don't break anything" approach which would move the
> > > needle between "network data sensitivity" and "on-disk data sen
On Wed, Mar 4, 2015 at 4:41 AM, David Rowley wrote:
>> This thread mentions "parallel queries" as a use case, but that means
>> passing data between processes, and that requires being able to
>> serialize and deserialize the aggregate state somehow. For actual data
>> types that's not overly diffi
* Andres Freund (and...@2ndquadrant.com) wrote:
> Hi,
>
> On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:
> > I've been discussing this with a few folks outside of the PG community
> > (Debian and Openwall people specifically) and a few interesting ideas
> > have come out of that which might be
On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost wrote:
> Magnus,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost
> wrote:
> > > A lot of discussion has been going on with SCRAM and SASL, which is all
> > > great, but that means we end up with a
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost wrote:
> > A lot of discussion has been going on with SCRAM and SASL, which is all
> > great, but that means we end up with a dependency on SASL or we have to
> > reimplement SCRAM (which I've b
Hi,
On 2015-03-04 10:52:30 -0500, Stephen Frost wrote:
> I've been discussing this with a few folks outside of the PG community
> (Debian and Openwall people specifically) and a few interesting ideas
> have come out of that which might be useful to discuss.
>
> The first is a "don't break anythin
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
> wrote:
> > Hm, why not. That would remove all inconsistencies between the parser
> > and the autovacuum code path. Perhaps something like the attached
> > makes sense then?
>
> I really don't see this
On Mon, Feb 23, 2015 at 5:59 AM, Andrew Gierth
wrote:
>> "Tomas" == Tomas Vondra writes:
> Tomas> Interesting, but I think Gavin was asking about how much
> Tomas> variation was there for each tested case (e.g. query executed on
> Tomas> the same code / dataset). And in those cases the pad
Bruce, all,
I've been discussing this with a few folks outside of the PG community
(Debian and Openwall people specifically) and a few interesting ideas
have come out of that which might be useful to discuss.
The first is a "don't break anything" approach which would move the
needle between "netw
On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost wrote:
>
> A lot of discussion has been going on with SCRAM and SASL, which is all
> great, but that means we end up with a dependency on SASL or we have to
> reimplement SCRAM (which I've been thinking might not be a bad idea-
> it's actually not tha
On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
wrote:
> Hm, why not. That would remove all inconsistencies between the parser
> and the autovacuum code path. Perhaps something like the attached
> makes sense then?
I really don't see this patch, or any of the previous ones, as solving
any actual
Hi Robert,
On 3/4/15 10:14 AM, Robert Haas wrote:
> On Wed, Feb 25, 2015 at 7:54 PM, David Steele wrote:
>> +1 on 128/256 character names.
>>
>>> /me runs and hides.
>>
>> /stands brazenly in the open and volunteers to try it if I don't get
>> clobbered within seconds.
>
> I think the question i
Robert Haas writes:
> Another advantage of this is that it would probably make git less
> likely to fumble a rebase. If there are lots of places in the file
> where we have the same 10 lines in a row with occasional variations,
> rebasing a patch could easily pick the the wrong place to reapply t
On Mon, Mar 2, 2015 at 2:19 PM, David Kubečka wrote:
> The question is why optimizer, or rather the cost estimator, produced so
> much different estimates upon very small change in input. Moreover it seems
> that the main culprit of bad estimates isn't actually directly related to
> outer table, b
On Wed, Mar 4, 2015 at 10:04 AM, Andrew Dunstan wrote:
> Is it necessarily an all or nothing deal?
>
> Taking a previous example, we could have something like:
>
> {
> oid => 2249, oiddefine => 'CSTRINGOID', typname => 'cstring',
> typlen => -2, typbyval => 1,
> ..
On 2015-03-04 09:55:01 -0500, Robert Haas wrote:
> On Wed, Mar 4, 2015 at 9:42 AM, Tom Lane wrote:
> I wonder if we should have a tool in our repository to help people
> edit the file. So instead of going in there yourself and changing
> things by hand, or writing your own script, you can do:
>
On Wed, Feb 25, 2015 at 7:54 PM, David Steele wrote:
> +1 on 128/256 character names.
>
>> /me runs and hides.
>
> /stands brazenly in the open and volunteers to try it if I don't get
> clobbered within seconds.
I think the question is whether making lots of rows in system catalogs
better is goin
On Wed, Feb 25, 2015 at 5:06 PM, Jim Nasby wrote:
> Could the large allocation[2] for the dead tuple array in lazy_space_alloc
> cause problems with linux OOM? [1] and some other things I've read indicate
> that a large mmap will count towards total system memory, including
> producing a failure i
On 03/04/2015 09:51 AM, Robert Haas wrote:
On Wed, Mar 4, 2015 at 9:06 AM, Peter Eisentraut 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?
e.g. grep for a function name and check that all the
1 - 100 of 136 matches
Mail list logo
