On Tue, Feb 10, 2015 at 9:08 AM, Andres Freund and...@2ndquadrant.com 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
Marc Balmer m...@msys.ch 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
2015-02-10 16:21 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Marc Balmer m...@msys.ch 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.
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
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
Ravi Kiran ravi.kolanp...@gmail.com 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
On Tue, Feb 10, 2015 at 5:22 PM, Arthur Silva arthur...@gmail.com 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
On Tue, Feb 10, 2015 at 7:32 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas robertmh...@gmail.com wrote:
Although the patch was described as relatively easy to write, it never
went anywhere, because it *replaced* MD5 authentication with bcrypt,
which
On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva arthur...@gmail.com 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
On 2015-02-10 11:49:58 -0500, Robert Haas wrote:
On Sat, Feb 7, 2015 at 7:20 PM, Andres Freund and...@2ndquadrant.com 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
On Tue, Feb 10, 2015 at 8:49 PM, Mark Wong m...@2ndquadrant.com 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:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Feb 10, 2015 at 11:19 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva arthur...@gmail.com wrote:
I don't think the password storing best practices apply to db
connection
authentication.
Why not?
--
Peter Geoghegan
I assume if the
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=nudibranchbr=HEAD
Regards,
Mark
--
Mark Wong
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 good thing, I
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 PostgreSQL
Peter Eisentraut pete...@gmx.net 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
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.net
On Tue, Feb 10, 2015 at 10:19 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Feb 10, 2015 at 5:14 PM, Arthur Silva arthur...@gmail.com 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
On Tue, Feb 10, 2015 at 6:57 PM, Andres Freund and...@2ndquadrant.com 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:
On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us 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
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 ca
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 that to
Robert Haas robertmh...@gmail.com 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
On Tue, Feb 10, 2015 at 11:25 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Feb 10, 2015 at 5:22 PM, Arthur Silva arthur...@gmail.com 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.
On 2/5/15 10:13 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
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
On Mon, Feb 9, 2015 at 7:02 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao masao.fu...@gmail.com wrote:
MemoryContextAllocExtended() was added, so isn't it time to replace palloc()
with MemoryContextAllocExtended(CurrentMemoryContext,
On Mon, Feb 9, 2015 at 7:54 PM, Amit Langote
langote_amit...@lab.ntt.co.jp 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
On Sat, Feb 7, 2015 at 7:20 PM, Andres Freund and...@2ndquadrant.com 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
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_vacuum
On 2015-02-04 16:49:46 -0800, Peter Geoghegan wrote:
On Tue, Feb 2, 2015 at 01:06 AM, Andres Freund and...@2ndquadrant.com 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
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 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
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
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
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 t...@sss.pgh.pa.us wrote:
Ravi Kiran
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 the for(;;)
On Mon, Feb 9, 2015 at 6:52 PM, Thom Brown t...@linux.com 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.
On Mon, Feb 9, 2015 at 8:29 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
- * Wait for more WAL to arrive. Time out after 5
seconds,
-
On 2015-02-10 22:06:34 +0900, Michael Paquier wrote:
On Tue, Feb 10, 2015 at 9:46 PM, Andres Freund and...@2ndquadrant.com
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
2015-02-10 14:32 GMT+01:00 Marc Balmer m...@msys.ch:
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
***
On Tue, Feb 10, 2015 at 2:48 AM, Andres Freund and...@2ndquadrant.com 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
On Sun, Feb 8, 2015 at 3:56 AM, Shay Rojansky r...@roji.org 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
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 9 February 2015 at 21:17, Stephen Frost sfr...@snowman.net 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
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
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 subquery if
Antonin Houska a...@cybertec.at 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
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!
*
On 2015-02-10 09:23:02 -0500, Robert Haas wrote:
On Tue, Feb 10, 2015 at 9:08 AM, Andres Freund and...@2ndquadrant.com 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
On Mon, Feb 09, 2015 at 12:37:05PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It's going to be complicated and probably buggy, and I think it is heading
in the wrong direction altogether. If you want
On Tue, Feb 10, 2015 at 12:04 AM, Andres Freund and...@2ndquadrant.com 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
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
On 2/10/15 5:19 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com 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
On 2/10/15 6:32 PM, Peter Geoghegan wrote:
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas robertmh...@gmail.com 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
On 2/5/15 10:48 AM, Tom Lane wrote:
Stephen Frostsfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frostsfr...@snowman.net wrote:
And I thought this was about FDW options and not about dblink, really..
The OP is pretty clearly
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
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
[ this is addressing a tangential point ... ]
Stephen Frost sfr...@snowman.net 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
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
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas robertmh...@gmail.com 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
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,
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 reason
Jim Nasby jim.na...@bluetreble.com 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
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
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
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
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,
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 10:32 PM, Peter Geoghegan p...@heroku.com wrote:
On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas robertmh...@gmail.com
wrote:
Although the patch was described as relatively easy to write, it never
went anywhere, because it *replaced* MD5 authentication with bcrypt,
On 2015-02-10 08:52:09 -0500, Robert Haas wrote:
On Tue, Feb 10, 2015 at 2:48 AM, Andres Freund and...@2ndquadrant.com 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.
71 matches
Mail list logo
