On Wed, Feb 25, 2015 at 7:54 PM, David Steele da...@pgmasters.net 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
Robert Haas robertmh...@gmail.com 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
Hi Robert,
On 3/4/15 10:14 AM, Robert Haas wrote:
On Wed, Feb 25, 2015 at 7:54 PM, David Steele da...@pgmasters.net 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
On Mon, Mar 2, 2015 at 2:19 PM, David Kubečka kubecka@gmail.com 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
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 anything
On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost sfr...@snowman.net wrote:
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost sfr...@snowman.net
wrote:
A lot of discussion has been going on with SCRAM and SASL, which is all
great, but
On Thu, Feb 19, 2015 at 5:53 AM, Marko Tiikkaja ma...@joh.to 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
On Wed, Mar 4, 2015 at 4:41 AM, David Rowley dgrowle...@gmail.com 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
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 sensitivity
a
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 19, 2015 at 5:53 AM, Marko Tiikkaja ma...@joh.to 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 Tue, Mar 3, 2015 at 7:49 AM, Andres Freund and...@2ndquadrant.com
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
On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost sfr...@snowman.net 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
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
On Mon, Feb 23, 2015 at 5:59 AM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Tomas == Tomas Vondra tomas.von...@2ndquadrant.com 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
* 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
needle between
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 2015-03-04 09:55:01 -0500, Robert Haas wrote:
On Wed, Mar 4, 2015 at 9:42 AM, Tom Lane t...@sss.pgh.pa.us 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,
* Robert Haas (robertmh...@gmail.com) wrote:
On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
michael.paqu...@gmail.com 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
* 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 useful
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 Thu, Feb 19, 2015 at 5:53 AM, Marko Tiikkaja ma...@joh.to 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
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 does not
On 3/4/15 5:26 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 19, 2015 at 5:53 AM, Marko Tiikkaja ma...@joh.to 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
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 looks
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...
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 first is a don't
On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
* 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 the network
On Tue, Mar 3, 2015 at 7:57 PM, Tom Lane t...@sss.pgh.pa.us 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
* 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:52:30 -0500,
Hi Fujii,
Il 03/03/15 11:48, Fujii Masao ha scritto:
On Tue, Mar 3, 2015 at 12:36 AM, Marco Nenciarini
marco.nenciar...@2ndquadrant.it wrote:
Il 02/03/15 14:21, Fujii Masao ha scritto:
On Thu, Feb 12, 2015 at 10:50 PM, Marco Nenciarini
marco.nenciar...@2ndquadrant.it wrote:
Hi,
I've
* 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
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 user
On Tue, Mar 3, 2015 at 1:42 PM, Josh Berkus j...@agliodbs.com 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
* 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
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 anything
On Wed, Mar 4, 2015 at 8:26 AM, Robert Haas robertmh...@gmail.com 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
* 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 with
* 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 one at
Andrew Dunstan wrote:
On 03/04/2015 09:51 AM, Robert Haas wrote:
On Wed, Mar 4, 2015 at 9:06 AM, Peter Eisentraut pete...@gmx.net 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
* 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
susceptible
* 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, we
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 sfr...@snowman.net wrote:
No, I'm not suggesting that OpenSSL or TLS become mandatory but was
thinking it might be good alternative as a middle-ground
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp 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
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
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 has
On Wed, Mar 4, 2015 at 2:27 PM, Alvaro Herrera alvhe...@2ndquadrant.com 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 pete...@gmx.net wrote:
and make it harder to compare entries by grepping out some common
substring.
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
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, or by making
* 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 encryption.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Bruce Momjian br...@momjian.us 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
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 positively.
Yeah,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
On Wed, Mar 4, 2015 at 10:04 AM, Andrew Dunstan and...@dunslane.net 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 Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
michael.paqu...@gmail.com 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,
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
On Wed, Mar 4, 2015 at 4:52 PM, Stephen Frost sfr...@snowman.net 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
* Magnus Hagander (mag...@hagander.net) wrote:
On Wed, Mar 4, 2015 at 5:03 PM, Stephen Frost sfr...@snowman.net 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
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 mean
On 3/4/15 9:51 AM, Robert Haas wrote:
On Wed, Mar 4, 2015 at 9:06 AM, Peter Eisentraut pete...@gmx.net 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
Bruce Momjian br...@momjian.us 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
Stephen Frost sfr...@snowman.net 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
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 found
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
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 build
On Wed, Mar 4, 2015 at 10:52 AM, Stephen Frost sfr...@snowman.net 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
* 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
On Wed, Mar 4, 2015 at 4:11 PM, Peter Eisentraut pete...@gmx.net 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
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 pid file,
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
On 01/29/2015 12:28 AM, Peter Geoghegan wrote:
On Mon, Jan 26, 2015 at 11:21 PM, Andreas Karlsson andr...@proxel.se 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
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 pretty happy
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 two
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
Hi Tomas and others,
2015-03-02 21:29 GMT+01:00 Tomas Vondra tomas.von...@2ndquadrant.com:
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
On Wed, Mar 4, 2015 at 03:59:02PM -0500, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Bruce Momjian br...@momjian.us 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
On 3/3/15 5:58 PM, Tom Lane wrote:
Stephen Frost sfr...@snowman.net 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,
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
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 GRANT
On Wed, Mar 4, 2015 at 03:54:09PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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
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) The
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:
1) MD5
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,
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 current
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 of
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
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 fixing
On 3/2/15 4:47 PM, Robert Haas wrote:
On Sat, Feb 28, 2015 at 12:27 AM, Stephen Frost sfr...@snowman.net 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
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:
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:
4 марта 2015 г., в 19:28, Bruce Momjian br...@momjian.us написал(а):
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
=
On Wed, Mar 4, 2015 at 4:41 AM, David Rowley dgrowle...@gmail.com 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
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 elaborate
On Thu, Mar 5, 2015 at 12:54 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Sun, Mar 1, 2015 at 6:58 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Hm, why not. That would remove all inconsistencies between the parser
and the autovacuum
On Tue, Mar 3, 2015 at 7:14 PM, Peter Geoghegan p...@heroku.com 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
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) -
On Thu, Mar 5, 2015 at 1:59 AM, Marco Nenciarini
marco.nenciar...@2ndquadrant.it wrote:
Hi Fujii,
Il 03/03/15 11:48, Fujii Masao ha scritto:
On Tue, Mar 3, 2015 at 12:36 AM, Marco Nenciarini
marco.nenciar...@2ndquadrant.it wrote:
Il 02/03/15 14:21, Fujii Masao ha scritto:
On Thu, Feb 12,
Hello,
It looks like the remaining performance regression was indeed a
result of code alignment. I found two paranoia assignments I had
accidentally failed to put back with the rest of the mark/restore
optimization; after that trivial change the patched version is
ever-so-slightly faster
On 2015/03/03 21:34, Shigeru Hanada wrote:
I rebased join push-down patch onto Kaigai-san's Custom/Foreign Join
v6 patch.
Thanks for the work, Hanada-san and KaiGai-san!
Maybe I'm missing something, but did we agree to take this approach, ie,
join push-down on top of custom join? There is a
1 - 100 of 136 matches
Mail list logo
