On Sat, Feb 19, 2011 at 10:52 PM, Robert Haas wrote:
> On Sat, Feb 19, 2011 at 3:28 AM, Simon Riggs 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
Heikki Linnakangas 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.
> Another version, rebased ag
Robert Haas wrote:
> On Thu, Sep 23, 2010 at 11:34 PM, Dennis Bj?rklund wrote:
> >> On Wed, Sep 22, 2010 at 6:03 AM, Dennis Bj?rklund
> >> wrote:
> >> But I confess that I'm sort of murky on how ORDER affects the window
> >> frame, or how to rephrase this more sensibly.
> >
> > The rows included
On Sat, Feb 19, 2011 at 11:07 PM, Tom Lane 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 make changes to you
On Sat, Feb 19, 2011 at 3:35 AM, Simon Riggs 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 setting should be t
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 th
On Sat, Feb 19, 2011 at 3:28 AM, Simon Riggs 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,
> even though it is
> 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
PostgreS
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
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,
Peter Eisentraut 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 than has
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. I
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 overhea
Marko Kreen wrote:
> On 9/8/10, Tom Lane wrote:
> > Marko Kreen 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 what you say. To me
On Sat, Feb 19, 2011 at 6:05 PM, Bruce Momjian wrote:
> Marti Raudsepp wrote:
>> On Sat, Feb 19, 2011 at 15:23, Bruce Momjian 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 lon
Marti Raudsepp wrote:
> On Sat, Feb 19, 2011 at 15:23, Bruce Momjian 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 co
On Sat, Feb 19, 2011 at 9:17 PM, Peter Eisentraut 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 never exposed t
> 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 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 script that monit
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.
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,
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
opti
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 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 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 exp
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 *c
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
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 emu
On Fri, Feb 18, 2011 at 20:33, Bruce Momjian 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 to bac
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
> >> http://arc
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 wil
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 un
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
On Fri, 2011-02-18 at 20:45 -0500, Robert Haas wrote:
> On Fri, Feb 18, 2011 at 7:06 PM, Simon Riggs 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, its not long sinc
34 matches
Mail list logo
