On 2/5/15 10:48 AM, Tom Lane wrote:
Stephen Frost writes:
>* Robert Haas (robertmh...@gmail.com) wrote:
>>On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frost wrote:
>>>And I thought this was about FDW options and not about dblink, really..
>>The OP is pretty clearly asking about dblink.
>I was
On 2/10/15 6:32 PM, Peter Geoghegan wrote:
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas wrote:
Although the patch was described as relatively easy to write, it never
went anywhere, because it *replaced* MD5 authentication with bcrypt,
which would be a big problem for existing clients. It seems
On 2/10/15 5:19 PM, Tom Lane wrote:
Jim Nasby writes:
Without having read the patch, I think this is great. I've been wishing
for something like this while working on my variant data type.
Are there any cases where we would want to use this on a non-variant?
Perhaps types where we're paying
On Tue, Feb 10, 2015 at 10:19 PM, Peter Geoghegan wrote:
> On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva wrote:
>> I don't think the "password storing best practices" apply to db connection
>> authentication.
>
> Why not?
Usually because handshakes use a random salt on both sides. Not sure
abou
On 2/5/15 10:13 AM, Tom Lane wrote:
> Robert Haas writes:
>> All that having been said, it wouldn't be crazy to try to invent a
>> system to lock this down, but it *would* be complicated. An
>> individual FDW can call its authentication-related options anything it
>> likes; they do not need to be
Robert Haas writes:
> On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane wrote:
>> Another thing we need to keep in mind besides client compatibility
>> is dump/reload compatibility.
> I don't think there's an issue with dump/reload compatibility as far
> as what I proposed, since it only has to do with
On Tue, Feb 10, 2015 at 11:25 PM, Peter Geoghegan wrote:
> On Tue, Feb 10, 2015 at 5:22 PM, Arthur Silva wrote:
> > I assume if the hacker can intercept the server unencrypted traffic
> and/or
> > has access to its hard-drive the database is compromised anyway.
>
> That sounds like an argument a
On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane wrote:
>> 2. We'd have to figure out how to get support for the new algorithms
>> into libpq. This actually seems a good bit harder than doing it on
>> the server-side, because I don't think libpq has any dynamic loading
>> facilities the way the server d
On 2/9/15 3:12 AM, Jeff Davis wrote:
> On Sat, 2015-02-07 at 16:08 -0800, Jeff Davis wrote:
>> I believe Inclusion Constraints will be important for postgres.
>
> I forgot to credit Darren Duncan with the name of this feature:
>
> http://www.postgresql.org/message-id/4f8bb9b0.5090...@darrenduncan
Peter Eisentraut writes:
> On 2/10/15 8:28 PM, Robert Haas wrote:
>> I don't actually care which algorithm we use, and I dowannahafta care.
>> What I do want to do is provide a framework so that, when somebody
>> discovers that X is better than Y because Z, somebody who knows about
>> cryptography
On 2/10/15 3:12 AM, Michael Paquier wrote:
> On Tue, Feb 10, 2015 at 5:03 PM, Tatsuo Ishii wrote:
>>> - The documentation misses some markups for pgbench and VACUUM and did
>>> not respect the 80-character limit.
>>
>> I didn't realize that there's such a style guide. Although I think
>> it's a goo
Robert Haas writes:
> Although the patch was described as relatively easy to write, it never
> went anywhere, because it *replaced* MD5 authentication with bcrypt,
> which would be a big problem for existing clients.
Right. The client end of it is the elephant in the room in any discussion
of im
On 02/10/2015 05:28 PM, Robert Haas wrote:
> I don't actually care which algorithm we use, and I dowannahafta care.
> What I do want to do is provide a framework so that, when somebody
> discovers that X is better than Y because Z, somebody who knows about
> cryptography and not much about PostgreS
On Tue, Feb 10, 2015 at 8:49 PM, Mark Wong wrote:
> I've seen in the archive a call for more architecture coverage so I just
> wanted to send a quick note that there is now Linux on System Z in the
> buildfarm now:
>
> http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=nudibranch&br=HEAD
Nice.
--
On 2015-02-10 11:49:58 -0500, Robert Haas wrote:
> On Sat, Feb 7, 2015 at 7:20 PM, Andres Freund wrote:
> > * Don't like CreateParallelContextForExtension much as a function name -
> > I don't think we normally equate the fact that code is located in a
> > loadable library with the extension m
Hi everyone,
I've seen in the archive a call for more architecture coverage so I just
wanted to send a quick note that there is now Linux on System Z in the
buildfarm now:
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=nudibranch&br=HEAD
Regards,
Mark
--
Mark Wong
On Tue, Feb 10, 2015 at 6:57 PM, Andres Freund wrote:
>> I think one of them could be a fix. Any advice?
>
> I slightly prefer the second form...
I think "it uses" is definitely more standard English usage in this context.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On 2/10/15 8:28 PM, Robert Haas wrote:
> I don't actually care which algorithm we use, and I dowannahafta care.
> What I do want to do is provide a framework so that, when somebody
> discovers that X is better than Y because Z, somebody who knows about
> cryptography and not much about PostgreSQL c
On Tue, Feb 10, 2015 at 7:32 PM, Peter Geoghegan wrote:
> On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas wrote:
>> Although the patch was described as relatively easy to write, it never
>> went anywhere, because it *replaced* MD5 authentication with bcrypt,
>> which would be a big problem for exist
On Tue, Feb 10, 2015 at 5:22 PM, Arthur Silva wrote:
> I assume if the hacker can intercept the server unencrypted traffic and/or
> has access to its hard-drive the database is compromised anyway.
That sounds like an argument against hashing the passwords in general.
--
Peter Geoghegan
--
S
On Tue, Feb 10, 2015 at 11:19 PM, Peter Geoghegan wrote:
> On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva wrote:
> > I don't think the "password storing best practices" apply to db
> connection
> > authentication.
>
> Why not?
>
> --
> Peter Geoghegan
>
I assume if the hacker can intercept the s
On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva wrote:
> I don't think the "password storing best practices" apply to db connection
> authentication.
Why not?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
On 2/10/15 5:15 PM, Andres Freund wrote:
> Hi,
>
> I've repeatedly stared at logs containing PANICs during WAL
> replay. Unfortunately it's rather hard to find out which record actually
> caused the problem as we print the record's contents but not its LSN.
>
> I think it's a no-brainer to add th
On Tue, Feb 10, 2015 at 10:32 PM, Peter Geoghegan wrote:
> On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas
> wrote:
> > Although the patch was described as relatively easy to write, it never
> > went anywhere, because it *replaced* MD5 authentication with bcrypt,
> > which would be a big problem fo
On 02/10/2015 02:46 PM, Andres Freund wrote:
On 2015-02-10 21:20:37 +0900, Michael Paquier wrote:
Using test_decoding on HEAD (cc761b1) I am seeing the following assertion
failure:
TRAP: FailedAssertion("!(!((&RegisteredSnapshots)->ph_root ==
((void*)0)))", File: "snapmgr.c", Line: 677)
Ick. I
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas wrote:
> Although the patch was described as relatively easy to write, it never
> went anywhere, because it *replaced* MD5 authentication with bcrypt,
> which would be a big problem for existing clients. It seems clear
> that we should add something ne
There have been a few previous attempts to wean PostgreSQL off of MD5.
Back in 2012, Heikki proposed using SCRAM for our next-generation
authentication mechanism:
http://www.postgresql.org/message-id/507550bd.2030...@vmware.com
That seems likely to be a good idea, but nobody's come up with a
patc
> Do you want to push this yourself or have me do it?
If ok, could you please push it?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Thanks for understanding Robert, that's more or less what I had in mind, I
was mainly wondering if I were missing some deeper explanation for the
absence of the possibility of requesting 0 rows.
Regardless of all of the above, it's really no big deal. I'll go ahead and
use max_rows=1 for now, hope
Hi,
On 2015-02-11 08:55:12 +0900, Tatsuo Ishii wrote:
> I found a small typo in logicaldecoding.sgml.
Oops.
> I think one of them could be a fix. Any advice?
I slightly prefer the second form...
Do you want to push this yourself or have me do it?
Greetings,
Andres Freund
--
Andres Freund
I found a small typo in logicaldecoding.sgml. I think one of them
could be a fix. Any advice?
diff --git a/doc/src/sgml/logicaldecoding.sgml
b/doc/src/sgml/logicaldecoding.sgml
index 3efe433..3650567 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -299,7
Jim Nasby writes:
> Without having read the patch, I think this is great. I've been wishing
> for something like this while working on my variant data type.
> Are there any cases where we would want to use this on a non-variant?
> Perhaps types where we're paying an alignment penalty?
What do
Without having read the patch, I think this is great. I've been wishing
for something like this while working on my variant data type.
Are there any cases where we would want to use this on a non-variant?
Perhaps types where we're paying an alignment penalty?
On 2/10/15 3:00 PM, Stephen Frost
[ this is addressing a tangential point ... ]
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> * Although I said above that everything owned by a deserialized object
>> has to live in a single memory context, I do have ideas about relaxing
>> that. The core idea would be to inve
Hi,
I've repeatedly stared at logs containing PANICs during WAL
replay. Unfortunately it's rather hard to find out which record actually
caused the problem as we print the record's contents but not its LSN.
I think it's a no-brainer to add that to master. But I'd even argue that
it'd be a good id
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I've now taken this idea as far as building the required infrastructure
> and revamping a couple of array operators to use it. There's a lot yet
> to do, but I've done enough to get some preliminary ideas about
> performance (see below).
Nice!
> * A
On 2015-02-10 09:23:02 -0500, Robert Haas wrote:
> On Tue, Feb 10, 2015 at 9:08 AM, Andres Freund wrote:
> > And good chunk sizes et al depend on higher layers,
> > selectivity estimates and such. And that's planner/executor work, not
> > the physical layer (which heapam.c pretty much is).
>
> If
On Tue, Feb 10, 2015 at 12:04 AM, Andres Freund wrote:
> FWIW, I don't think anything here really should refer to the wiki...
The Wiki pages have done a good job of summarizing things...it
certainly didn't seem that hard for you to get up to speed here. Also,
as you'll know from working on logica
On Mon, Feb 09, 2015 at 12:37:05PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane wrote:
> >> It's going to be complicated and probably buggy, and I think it is heading
> >> in the wrong direction altogether. If you want to partition in some
> >> arbit
I've been fooling around with a design to support computation-oriented,
not-necessarily-contiguous-blobs representations of datatypes in memory,
along the lines I mentioned here:
http://www.postgresql.org/message-id/2355.1382710...@sss.pgh.pa.us
In particular this is meant to reduce the overhead f
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> On 2015/02/10 7:23, Dean Rasheed wrote:
> >Sorry, I didn't have time to look at this properly. My initial thought
> >is that expand_security_qual() needs to request a lock on rows coming
> >from the relation it pushes down into a subqu
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 9 February 2015 at 21:17, Stephen Frost wrote:
> >> > On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
> >> > > I noticed that when updating security barrier views on foreign tables,
> >> > > we fail to give FOR UPDATE to selection queries
On Tue, Feb 10, 2015 at 10:55:07AM -0500, Greg Sabino Mullane wrote:
> Just a little thing that's been bugging me. If one side of the
> pg_upgrade has checksums and the other does not, give a less
> cryptic error message.
OK, sure. Good fix, will apply. This seems to be the day for pg_upgrade
I received a private pg_upgrade bug report related to its affect on the
removal of clog files in the upgraded cluster. The user reported that
an upgraded cluster yielded this error very soon after being started for
the first time:
SELECT * FROM test;
ERROR: could not access statu
On Mon, Feb 9, 2015 at 7:54 PM, Amit Langote
wrote:
>> Well, that's debatable IMO (especially your claim that variable-size
>> partitions would be needed by a majority of users). But in any case,
>> partitioning behavior that is emergent from a bunch of independent pieces
>> of information scatte
On Mon, Feb 9, 2015 at 7:02 AM, Michael Paquier
wrote:
> On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao wrote:
>> MemoryContextAllocExtended() was added, so isn't it time to replace palloc()
>> with MemoryContextAllocExtended(CurrentMemoryContext, MCXT_ALLOC_NO_OOM)
>> in allocate_recordbuf()?
>
> Y
On Sat, Feb 7, 2015 at 7:20 PM, Andres Freund wrote:
> Observations:
> * Some tailing whitespace in the readme. Very nice otherwise.
Fixed. Thanks.
> * Don't like CreateParallelContextForExtension much as a function name -
> I don't think we normally equate the fact that code is located in a
I was reminded today by Greg Mullane's blog post
http://blog.endpoint.com/2015/02/postgres-custom-casts-and-pgdump.html
about how pg_dump fails to dump custom casts if they are casts between
built-in types. Setting aside the wisdom of creating such a cast,
it's definitely annoying that pg_dump mis
Just a little thing that's been bugging me. If one side of the
pg_upgrade has checksums and the other does not, give a less
cryptic error message.
--
Greg Sabino Mullane g...@endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
diff --git a/contrib/pg_upgrade/controldata.c b/contrib/pg_upgra
Ravi Kiran writes:
> yes sir, I did try the pg_ctl reload command, but its still using the hash
> join algorithm and not the nested loop algorithm. I even restarted the
> server, even then its still using the hash join algorithm
Does "show enable_hashjoin" say it's off? If not, I think you must'
2015-02-10 16:21 GMT+01:00 Tom Lane :
> Marc Balmer writes:
> > That is simple indeed. I tend to think, however, that it would be
> > cleaner to return the position as a proper result from a functionn
> > instead of using a "side effect" from a FETCH/MOVE command.
>
> Yeah. For one thing, a com
Marc Balmer writes:
> That is simple indeed. I tend to think, however, that it would be
> cleaner to return the position as a proper result from a functionn
> instead of using a "side effect" from a FETCH/MOVE command.
Yeah. For one thing, a command tag wouldn't help you at all if you
wanted to
Antonin Houska writes:
> The special case is that the path passed to add_path_precheck() has costs
> *equal to* those of the old_path. If pathkeys, outer rells and costs are the
> same, as summarized in the comment above, I expect add_path_precheck() to
> return false. Do I misread anything?
It d
On Tue, Feb 10, 2015 at 9:08 AM, Andres Freund wrote:
> If you make the chunks small enough, and then coordate only the chunk
> distribution, not really.
True, but why do you want to do that in the executor instead of in the heapam?
>> For this case, what I would imagine is that there is one par
On 2015-02-10 08:52:09 -0500, Robert Haas wrote:
> On Tue, Feb 10, 2015 at 2:48 AM, Andres Freund wrote:
> > Note that I'm not saying that Amit's patch is right - I haven't read it
> > - but that I don't think a 'scan this range of pages' heapscan API would
> > not be a bad idea. Not even just for
On Sun, Feb 8, 2015 at 3:56 AM, Shay Rojansky wrote:
> Just to be precise: what is strange to me is that the max_rows feature
> exists
> but has no 0 value. You and Marko are arguing that the whole feature should
> be
> deprecated (i.e. always return all rows).
I think the fact that it has no zer
On Tue, Feb 10, 2015 at 2:48 AM, Andres Freund wrote:
> Note that I'm not saying that Amit's patch is right - I haven't read it
> - but that I don't think a 'scan this range of pages' heapscan API would
> not be a bad idea. Not even just for parallelism, but for a bunch of
> usecases.
We do have
2015-02-10 14:32 GMT+01:00 Marc Balmer :
>
>
> Am 10.02.15 um 09:06 schrieb Pavel Stehule:
> > Hi
> >
> >
> > the patch can be very simple:
> >
> > diff --git a/src/backend/commands/portalcmds.c
> > b/src/backend/commands/portalcmds.c
> > new file mode 100644
> > index 2794537..20b9206
> > *** a/s
On 2015-02-10 22:06:34 +0900, Michael Paquier wrote:
> On Tue, Feb 10, 2015 at 9:46 PM, Andres Freund
> wrote:
>
> > Yea, it really looks like the above commit is to "blame". The new xmin
> > tracking infrastructure doesn't know about the historical snapshot...
> >
>
> I think that we need a bet
On Mon, Feb 9, 2015 at 8:29 PM, Fujii Masao wrote:
> On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
> wrote:
>> On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
>>> - * Wait for more WAL to arrive. Time out after 5
>>> seconds,
>>> - * like when polling
Am 10.02.15 um 09:06 schrieb Pavel Stehule:
> Hi
>
>
> the patch can be very simple:
>
> diff --git a/src/backend/commands/portalcmds.c
> b/src/backend/commands/portalcmds.c
> new file mode 100644
> index 2794537..20b9206
> *** a/src/backend/commands/portalcmds.c
> --- b/src/backend/commands/p
On Tue, Feb 10, 2015 at 9:46 PM, Andres Freund
wrote:
> Yea, it really looks like the above commit is to "blame". The new xmin
> tracking infrastructure doesn't know about the historical snapshot...
>
I think that we need a better regression coverage here... For example, we
could add some tap te
Hi,
On 2015-02-10 21:20:37 +0900, Michael Paquier wrote:
> Using test_decoding on HEAD (cc761b1) I am seeing the following assertion
> failure:
> TRAP: FailedAssertion("!(!((&RegisteredSnapshots)->ph_root ==
> ((void*)0)))", File: "snapmgr.c", Line: 677)
Ick. I guess a revert of 94028691609f8e148
Hi,
15 19:48:23 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20150210.194823.219136034.horiguchi.kyot...@lab.ntt.co.jp>
> Considering pg_basebackup/receivexlog, the loop in receivelog.c
> does not maintain the time value within it, so I think we are
> forced to use feGetCurrentTimeS
On 01/09/2015 10:32 AM, Abhijit Menon-Sen wrote:
2. The sse4.2 patch has only some minor compile fixes.
I have built and tested both patches individually on little-endian
(amd64) and big-endian (ppc) systems. I verified that the _sse is
chosen at startup on the former, and _sb8 on the latter, an
Hi all,
Using test_decoding on HEAD (cc761b1) I am seeing the following assertion
failure:
TRAP: FailedAssertion("!(!((&RegisteredSnapshots)->ph_root ==
((void*)0)))", File: "snapmgr.c", Line: 677)
(lldb) bt
* thread #1: tid = 0x, 0x7fff8b246d46 libsystem_kernel.dylib`__kill
+ 10, stop re
On Mon, Feb 9, 2015 at 6:52 PM, Thom Brown wrote:
>
> Hi all,
>
> Google Summer of Code 2015 is approaching. I'm intending on registering
PostgreSQL again this year.
>
> Before I do that, I'd like to have an idea of how many people are
interested in being either a student or a mentor.
>
I'm inte
Hello,
The attached patch is fix for walreciever not using gettimeofday,
and fix for receivelog using it.
> > XLogWalRcvProcessMsg doesn't send feedback when processing
> > 'w'=WAL record packet. So the same thing as pg_basebackup and
> > pg_receivexlog will occur on walsender.
> >
> > Exiting th
On 02/09/2015 03:20 PM, Abhijit Menon-Sen wrote:
At 2015-02-09 12:52:41 +0200, hlinnakan...@vmware.com wrote:
Do you have access to big-endian hardware to test this on?
Yes, I tested it on a Linux/ppc system. I wasn't speculating when I said
it "does make a noticeable difference", though I'm a
yes sir, I did try the pg_ctl reload command, but its still using the hash
join algorithm and not the nested loop algorithm. I even restarted the
server, even then its still using the hash join algorithm
Thanks
ᐧ
On Tue, Feb 10, 2015 at 5:28 AM, Tom Lane wrote:
> Ravi Kiran writes:
> > I tried
> On Tue, Feb 10, 2015 at 5:03 PM, Tatsuo Ishii wrote:
>>> - The documentation misses some markups for pgbench and VACUUM and did
>>> not respect the 80-character limit.
>>
>> I didn't realize that there's such a style guide. Although I think
>> it's a good thing, I just want to know where such a g
On Tue, Feb 10, 2015 at 5:03 PM, Tatsuo Ishii wrote:
>> - The documentation misses some markups for pgbench and VACUUM and did
>> not respect the 80-character limit.
>
> I didn't realize that there's such a style guide. Although I think
> it's a good thing, I just want to know where such a guide is
Hi
the patch can be very simple:
diff --git a/src/backend/commands/portalcmds.c
b/src/backend/commands/portalcmds.c
new file mode 100644
index 2794537..20b9206
*** a/src/backend/commands/portalcmds.c
--- b/src/backend/commands/portalcmds.c
*** PerformPortalFetch(FetchStmt *stmt,
***
On 2015-02-04 16:49:46 -0800, Peter Geoghegan wrote:
> On Tue, Feb 2, 2015 at 01:06 AM, Andres Freund wrote:
> > Generally the split into the individual commits doesn't seem to make
> > much sense to me.
I think trying to make that possible is a good idea in patches of this
size. It e.g. seems en
> On Mon, Feb 9, 2015 at 2:54 PM, Tatsuo Ishii wrote:
>> Agreed. Here is the patch to implement the idea: -f just implies -n.
>
> Some small comments:
> - is_no_vacuum, as well as is_init_mode, are defined as an integers
> but their use imply that they are boolean switches. This patch sets
> is_no
75 matches
Mail list logo