On Fri, 2011-02-18 at 20:45 -0500, Robert Haas wrote:
On Fri, Feb 18, 2011 at 7:06 PM, Simon Riggs si...@2ndquadrant.com wrote:
The patch is very lite touch on a few areas of code, plus a chunk of
specific code, all on master-side. Pretty straight really. I'm sure
problems will be found,
On Fri, 2011-02-18 at 21:39 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
Most parameters are set on the primary. Set
primary: synchronous_standby_names = 'node1, node2, node3'
which means that whichever of those standbys connect first will
become the main synchronous standby.
On Fri, 2011-02-18 at 20:45 -0500, Robert Haas wrote:
On the other hand, I see no particular
harm in leaving the option in there either, though I definitely think
the default should be changed to -1.
The default setting should be to *not* freeze up if you lose the
standby. That behaviour
Simon Riggs wrote:
On Fri, 2011-02-18 at 21:39 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
Most parameters are set on the primary. Set
primary: synchronous_standby_names = 'node1, node2, node3'
which means that whichever of those standbys connect first will
become the
On ons, 2011-02-09 at 10:09 +0100, Jan Urbański wrote:
On 27/01/11 22:42, Jan Urbański wrote:
On 23/12/10 14:50, Jan Urbański wrote:
Here's a patch implementing properly invalidating functions that have
composite type arguments after the type changes, as mentioned in
On Fri, Feb 18, 2011 at 20:33, Bruce Momjian br...@momjian.us wrote:
Magnus Hagander wrote:
Better late than never (or?), here's the final cleanup of
pg_streamrecv for moving into the main distribution, per discussion
back in late dec or early jan. It also includes the stream logs in
parallel
On Fri, Feb 18, 2011 at 02:35:42PM -0500, Bruce Momjian wrote:
/* Get the OpenSSL structure associated with a connection. Returns NULL for
* unencrypted connections or if any other TLS library is in use. */
extern void *PQgetssl(PGconn *conn);
We are under no compulsion to emulate
On Sat, Feb 19, 2011 at 07:42:20PM +0100, Martijn van Oosterhout wrote:
ODBC uses it as well. It really uses it for communication. As far as
Google Code Search can it's the only one that does.
But if the intention is to do it by adding new functions, we can and
let the ODBC guys sort it out
On 02/19/2011 01:42 PM, Martijn van Oosterhout wrote:
On Fri, Feb 18, 2011 at 02:35:42PM -0500, Bruce Momjian wrote:
/* Get the OpenSSL structure associated with a connection. Returns NULL for
* unencrypted connections or if any other TLS library is in use. */
extern void *PQgetssl(PGconn
On Fri, Feb 18, 2011 at 10:42:20AM -0500, Andrew Dunstan wrote:
Could we provide an abstraction layer over whatever SSL library is in
use with things like read/write/poll? Maybe that's what you had in mind
for the passthrough mode.
The suggested interface was as follows. It basically
On lör, 2011-02-19 at 13:55 -0500, Andrew Dunstan wrote:
If you plug in a libpq that was compiled against, say,
NSS under a psql that's expecting OpenSSL you'll get a null back
instead of a pointer to an SSL object, but then that would be a silly
thing to do.
Not so silly if you consider
On 2/18/11 4:06 PM, Simon Riggs wrote:
v17 implements what I believe to be the final set of features for sync
rep. This one I'm actually fairly happy with. It can be enjoyed best at
DEBUG3.
Yes, but what wine do I serve with it? ;-)
--
-- Josh Berkus
On fre, 2011-02-18 at 16:57 -0300, Alvaro Herrera wrote:
2. is md5 the most appropriate digest for this? If you need a
cryptographically secure hash, do we need something stronger? If not,
why not just use hash_any?
MD5 is probably more appropriate than hash_any, because the latter is
Hacker,
I found two issues in fuzzystrmatch contrib.
1) Incorrect s_data shift in levenshtein calculation with threshold with
multibyte characters. i index was used instead of start_column.
2) Missing dependency of fuzzystrmatch.o on levenshtein.c
Patch is attached.
--
With best regards,
Thanks for feedback on my proposal.
Ok, I'll write it as an separate function. After that I'm going to look if
is there a way to union them without kluge. If I'll not find such way then
I'll propose patch with separate function.
--
With best regards,
Alexander Korotkov.
Heikki Linnakangas wrote:
On 14.02.2011 20:10, Kevin Grittner wrote:
Promotion of the lock granularity on the prior tuple is where we
have problems. If the two tuple versions are in separate pages
then the second UPDATE could miss the conflict. My first thought
was to fix that by
On Sat, Feb 19, 2011 at 15:23, Bruce Momjian br...@momjian.us wrote:
Sorry. I was thinking of allowing a command to alert an administrator
when we switch standby machines, or if we can't do synchronous standby
any longer. I assume we put a message in the logs, and the admin could
have a
On Sat, Feb 19, 2011 at 9:17 PM, Peter Eisentraut pete...@gmx.net wrote:
The only consideration against MD5 might be
that it would make us look quite lame. We should probably provide
builtin SHA1 and SHA2 functions for this and other reasons.
In this particular case however the checksum is
Marti Raudsepp wrote:
On Sat, Feb 19, 2011 at 15:23, Bruce Momjian br...@momjian.us wrote:
Sorry. ?I was thinking of allowing a command to alert an administrator
when we switch standby machines, or if we can't do synchronous standby
any longer. ?I assume we put a message in the logs, and
On Sat, Feb 19, 2011 at 6:05 PM, Bruce Momjian br...@momjian.us wrote:
Marti Raudsepp wrote:
On Sat, Feb 19, 2011 at 15:23, Bruce Momjian br...@momjian.us wrote:
Sorry. ?I was thinking of allowing a command to alert an administrator
when we switch standby machines, or if we can't do
Marko Kreen wrote:
On 9/8/10, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
Although it does seem unnecessary.
The reason I asked for this to be spelled out is that ordinarily,
a backslash escape \nnn is a very low-level thing that will insert
exactly
I've been poking at the FDW stuff and file_fdw, and I find myself
dissatisfied with the way that the EXPLAIN support is designed,
namely that we have to compute a string at plan time to be displayed
by EXPLAIN. There are a couple of problems with that:
1. The explainInfo string is useless
Bruce Momjian wrote:
Can someone update the PostgreSQL shared memory usage table for 9.0?
http://www.postgresql.org/docs/9.0/static/kernel-resources.html#SYSVIPC
Right now it says Approximate shared memory bytes required (as of
8.3).
This documentation still says as of 8.3. If they
Peter Eisentraut pete...@gmx.net writes:
On fre, 2011-02-18 at 16:57 -0300, Alvaro Herrera wrote:
2. is md5 the most appropriate digest for this? If you need a
cryptographically secure hash, do we need something stronger? If not,
why not just use hash_any?
MD5 is probably more appropriate
Excerpts from Tom Lane's message of sáb feb 19 21:26:42 -0300 2011:
However ... IIRC, hash_any gives different results on bigendian and
littleendian machines. I'm not sure if a predictable cross-platform
result is important for this use? If you're hashing data containing
native integers,
Stephen Frost wrote:
-- Start of PGP signed section.
Greetings,
After watching a database import go abysmally slow on a pretty beefy
box with tons of RAM, I got annoyed and went to hunt down why in the
world PG wasn't using but a bit of memory. Turns out to be a well
known and
Is this a TODO? Can we easily fix the tuplesort.c code?
Easily, no. But that's not a reason for it to not be a TODO.
I, too, would like to be able to make use of 32GB of work_mem effectively.
--
-- Josh Berkus
On Sat, Feb 19, 2011 at 3:28 AM, Simon Riggs si...@2ndquadrant.com wrote:
First, we should be clear to explain that you are referring to the fact
that the request
synchronous_commit = off
synchronous_replication = on
makes no sense in the way the replication system is currently designed,
I wrote:
... I think we should drop
FdwPlan.explainInfo and instead define an additional callback function
that is called by EXPLAIN to produce the extra data for EXPLAIN to
display. This function could have access to the EXPLAIN options as well
as (in ANALYZE mode) the final state of the
On Sat, Feb 19, 2011 at 3:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2011-02-18 at 20:45 -0500, Robert Haas wrote:
On the other hand, I see no particular
harm in leaving the option in there either, though I definitely think
the default should be changed to -1.
The default
On Sat, Feb 19, 2011 at 11:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Anybody have an objection to doing it like that?
I don't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Robert Haas wrote:
On Thu, Sep 23, 2010 at 11:34 PM, Dennis Bj?rklund d...@zigo.dhs.org wrote:
On Wed, Sep 22, 2010 at 6:03 AM, Dennis Bj?rklund d...@zigo.dhs.org
wrote:
But I confess that I'm sort of murky on how ORDER affects the window
frame, or how to rephrase this more sensibly.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 11.02.2011 22:50, Heikki Linnakangas wrote:
I spent some more time reviewing this, and working on the PostgreSQL FDW
in tandem. Here's an updated API patch, with a bunch of cosmetic
changes, and a bug fix for FOR SHARE/UPDATE.
On Sat, Feb 19, 2011 at 10:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 19, 2011 at 3:28 AM, Simon Riggs si...@2ndquadrant.com wrote:
First, we should be clear to explain that you are referring to the fact
that the request
synchronous_commit = off
synchronous_replication = on
34 matches
Mail list logo
