Those code fragment judges the return value from
SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
when SSL_ERROR_WANT_READ. It seems they are not consistent. Comments?
There's no particular reason
On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
umi.tan...@gmail.com writes:
http://www.postgresql.org/docs/9.1/static/spi-spi-execute.html
===
SPI_execute(INSERT INTO foo SELECT * FROM bar, false, 5);
will allow at most 5 rows to be inserted into the table.
===
This
On 2012-04-04 17:10, Tom Lane wrote:
Yeb Havingayebhavi...@gmail.com writes:
Using a cursor argument name equal to another plpgsql variable results
in the error:
cursor .. has no argument named
I think a better way would be to temporarily set
plpgsql_IdentifierLookup to
On Thu, Apr 5, 2012 at 1:23 AM, Robert Haas robertmh...@gmail.com wrote:
I don't think we're micro-optimizing, either. I don't consider
avoiding a 10-second cessation of all database activity to be a
micro-optimization even on a somewhat artificial benchmark.
Robert is not skewing the SLRU
On Thu, Apr 5, 2012 at 12:25 AM, Robert Haas robertmh...@gmail.com wrote:
That seems much smarter. I'm thinking this should be back patched
because it appears to be fairly major, so I'm asking for some more
certainty that every thing you say here is valid. No doubt much of it
is valid, but
Hello
2012/4/4 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 04.04.2012 19:32, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
I don't think I'm getting my point across by explaining, so here's a
modified version of the patch that does what I was
On Thu, Apr 5, 2012 at 5:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
I'm also loathe to back patch. But its not very often we find a
problem that causes all backends to wait behind a single I/O.
You have a point.
Meanwhile, here are the benchmark results you requested. I did half
hour
On Thu, Apr 5, 2012 at 12:56 PM, Robert Haas robertmh...@gmail.com wrote:
Overall tps, first without and then with patch:
tps = 14546.644712 (including connections establishing)
tps = 14550.515173 (including connections establishing)
TPS graphs by second attached.
Again, I'm not that
At 22:11 12/03/28 +0900, Shigeru HANADA wrote:
ANALYZE support for foreign tables is proposed by Fujita-san in current
CF, so I'd like to push it.
I updated the patch to the latest HEAD. Please find attached a patch.
Best regards,
Etsuro Fujita
postgresql-analyze-v7.patch
Description:
Sorry, I sent this email without noticing Hanada-san' earlier email. So,
please look at Hanada-san's post.
Best regards,
Etsuro Fujita
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
Sent: Thursday, April
On 3 April 2012 12:11, Robert Haas robertmh...@gmail.com wrote:
Well, for 9.2, I am asking that you rip all that stuff out of the
patch altogether so we can focus on the stuff that was in the original
patch.
Given how we're pushed for time, I'm inclined to agree that that is
the best course of
On Thu, Apr 5, 2012 at 8:30 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Apr 5, 2012 at 12:56 PM, Robert Haas robertmh...@gmail.com wrote:
Overall tps, first without and then with patch:
tps = 14546.644712 (including connections establishing)
tps = 14550.515173 (including connections
On Thu, Apr 5, 2012 at 2:24 PM, Robert Haas robertmh...@gmail.com wrote:
Sorry, I don't understand specifically what you're looking for. I
provided latency percentiles in the last email; what else do you want?
I think he wants how many waits were there that were between 0 and 1s
how many
On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
The single-user option *sounds* viable, but, iirc, it actually isn't due
to the limitations on what can be done in that mode.
Yeah. IMO the right long-term fix is to be able to run
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
talking to a standalone backend, but nobody's gotten round to making
that possible.
Are you thinking about
Yeb Havinga yebhavi...@gmail.com writes:
On 2012-04-04 17:10, Tom Lane wrote:
I think a better way would be to temporarily set
plpgsql_IdentifierLookup to IDENTIFIER_LOOKUP_DECLARE,
Thank you for looking at it. Attached is a patch that implements your
suggestion.
Oh, sorry, I assumed you'd
On Thu, Apr 5, 2012 at 9:29 AM, Greg Stark st...@mit.edu wrote:
On Thu, Apr 5, 2012 at 2:24 PM, Robert Haas robertmh...@gmail.com wrote:
Sorry, I don't understand specifically what you're looking for. I
provided latency percentiles in the last email; what else do you want?
I think he wants
On Thursday, April 05, 2012 03:46:54 PM Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 4, 2012 at 11:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. IMO the right long-term fix is to be able to run pg_dump and psql
talking to a standalone backend, but nobody's gotten
* Andres Freund (and...@anarazel.de) wrote:
I wonder if it wouldn't be better to pass a named pipe under windows and use
a
AF_UNIX socket everwhere else. Both should be pretty easily usable with the
existing code. PG already seems to use named pipes under windows, so...
I didn't think
On Thursday, April 05, 2012 04:44:11 PM Stephen Frost wrote:
* Andres Freund (and...@anarazel.de) wrote:
I wonder if it wouldn't be better to pass a named pipe under windows and
use a AF_UNIX socket everwhere else. Both should be pretty easily usable
with the existing code. PG already seems
* Andres Freund (and...@anarazel.de) wrote:
Hm. Changing libpq to use two pipes at the same time sounds considerably more
invasive than basically just changing the socket creation and some minor
details.
It's not something we'd back-patch, but I don't believe it'd be very
difficult to
Hi,
Not sure if were just missing each others point?
On Thursday, April 05, 2012 05:20:04 PM Stephen Frost wrote:
Why would pipes be more useful? Its not like you could build useful
pipelines with them.
The point is to avoid the risk that someone else could connect to the
database at
Stephen Frost sfr...@snowman.net writes:
* Andres Freund (and...@anarazel.de) wrote:
Why would pipes be more useful? Its not like you could build useful
pipelines
with them.
The point is to avoid the risk that someone else could connect to the
database at the same time you're doing work
Andres Freund and...@anarazel.de writes:
The point is to avoid the risk that someone else could connect to the
database at the same time you're doing work on it.
I got that. I just fail to see what the advantage of using two pipes instead
of one socket as every other plain connection would
On Tue, Mar 27, 2012 at 8:30 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 27, 2012 at 3:22 PM, Ants Aasma a...@cybertec.at wrote:
On Tue, Mar 27, 2012 at 9:58 PM, Robert Haas robertmh...@gmail.com wrote:
I've committed the core of this. I left out the stats collector
stuff,
On Wed, Mar 28, 2012 at 7:23 AM, Robert Haas robertmh...@gmail.com wrote:
Although I liked the idea of separating this out, I wasn't thinking we
should do it as part of this patch. It seems like an independent
project. At any rate, I strongly agree that counting the number of
strategy
On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
The point is to avoid the risk that someone else could connect to the
database at the same time you're doing work on it.
I got that. I just fail to see what the advantage of using two pipes
Andres Freund and...@anarazel.de writes:
On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote:
Yeah, that would be a small pain in the neck, but it eliminates a huge
pile of practical difficulties, like your blithe assumption that you can
find a private directory somewhere (wrong) or
On Tue, Apr 3, 2012 at 4:15 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Tom Lane t...@sss.pgh.pa.us writes:
On Apr 2, 2012, at 11:24 AM, Peter Eisentraut wrote:
Or an extension could specify itself which version numbering scheme it
uses. This just has to be a reference to a type, which
On Thursday, April 05, 2012 06:12:48 PM Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On Thursday, April 05, 2012 05:39:19 PM Tom Lane wrote:
Yeah, that would be a small pain in the neck, but it eliminates a huge
pile of practical difficulties, like your blithe assumption that
Albe Laurenz laurenz.a...@wien.gv.at writes:
I think that the price of a remote table scan is something
we should be willing to pay for good local statistics.
And there is always the option not to analyze the foreign
table if you are not willing to pay that price.
Maybe the FDW API could be
On Wed, Apr 04, 2012 at 06:41:00PM -0400, Tom Lane wrote:
Marko Kreen mark...@gmail.com writes:
On Wed, Apr 4, 2012 at 10:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Given the lack of consensus around the suspension API, maybe the best
way to get the underlying libpq patch to a committable
On Thu, Apr 5, 2012 at 7:05 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 5, 2012 at 9:29 AM, Greg Stark st...@mit.edu wrote:
On Thu, Apr 5, 2012 at 2:24 PM, Robert Haas robertmh...@gmail.com wrote:
Sorry, I don't understand specifically what you're looking for. I
provided latency
On Thu, Apr 5, 2012 at 3:05 PM, Robert Haas robertmh...@gmail.com wrote:
I'm not sure I find those numbers all that helpful, but there they
are. There are a couple of outliers beyond 12 s on the patched run,
but I wouldn't read anything into that; the absolute worst values
bounce around a lot
Marko Kreen mark...@gmail.com writes:
Minor cleanups:
* Change callback return value to be 'bool': 0 is error.
Currently the accepted return codes are 1 and -1,
which is weird.
No, I did it that way intentionally, with the thought that we might add
back return code zero (or other return
On ons, 2012-03-28 at 01:49 +0300, Alex wrote:
Attached is a gzipped v10, complete with the above fixes and fixes to
bugs found by Heikki. Documentation and code comments are also
finally updated.
The compiler warning is still there:
fe-connect.c: In function ‘conninfo_parse’:
On Thu, Apr 5, 2012 at 17:34, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
* Andres Freund (and...@anarazel.de) wrote:
Why would pipes be more useful? Its not like you could build useful
pipelines
with them.
The point is to avoid the risk that someone else
Robert Haas robertmh...@gmail.com writes:
Examining this thread, I think there is insufficient consensus to push
this patch into 9.2. It's not entirely clear that this patch isn't
what we want, but it's not entirely clear that it is what we want
either, and I think it's too late in the
On Thu, Apr 5, 2012 at 12:30 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I'm not sure I find those numbers all that helpful, but there they
are. There are a couple of outliers beyond 12 s on the patched run,
but I wouldn't read anything into that; the absolute worst values
bounce around a lot
On Thu, Apr 05, 2012 at 12:49:37PM -0400, Tom Lane wrote:
Marko Kreen mark...@gmail.com writes:
Minor cleanups:
* Change callback return value to be 'bool': 0 is error.
Currently the accepted return codes are 1 and -1,
which is weird.
No, I did it that way intentionally, with the
On Thu, Apr 5, 2012 at 12:44 PM, Greg Stark st...@mit.edu wrote:
On Thu, Apr 5, 2012 at 3:05 PM, Robert Haas robertmh...@gmail.com wrote:
I'm not sure I find those numbers all that helpful, but there they
are. There are a couple of outliers beyond 12 s on the patched run,
but I wouldn't read
On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On ons, 2012-03-07 at 17:14 -0500, Tom Lane wrote:
I said it was a reasonable alternative, not that it was the only one
we should consider. The behavior of .nrows() might be accidental,
but
These patches aren't marked with a committer
FK arrays
ECPG fetch
foreign stats
command triggers
check function
parallel pg_dump
Does that mean myself or others should be claiming them for commit/reject?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development,
2012/4/5 Peter Eisentraut pete...@gmx.net
On lör, 2012-03-24 at 16:24 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On ons, 2012-03-07 at 17:14 -0500, Tom Lane wrote:
I said it was a reasonable alternative, not that it was the only one
we should consider. The
Peter Eisentraut pete...@gmx.net writes:
The alternatives are now to introduce a new function like has_rows()
that returns True iff result rows exist and therefore result metadata
can be fetched, or go back to having coltypes() et al. return None when
no metadata exists. I'm in favor of the
On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs si...@2ndquadrant.com wrote:
These patches aren't marked with a committer
FK arrays
ECPG fetch
foreign stats
command triggers
check function
parallel pg_dump
Does that mean myself or others should be claiming them for commit/reject?
I've been
On Thu, Apr 5, 2012 at 9:05 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 3 April 2012 12:11, Robert Haas robertmh...@gmail.com wrote:
Well, for 9.2, I am asking that you rip all that stuff out of the
patch altogether so we can focus on the stuff that was in the original
patch.
Given
On 05.04.2012 21:00, Robert Haas wrote:
Heikki recently produced a revision of the check function patch, but
I'm not sure whether he's planning to commit that or whether it's a
demonstration of a broader rework he wants Pavel (or someone else) to
do. At any rate, I think it's up to him whether
On Wed, Mar 28, 2012 at 12:13 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Wed, Mar 28, 2012 at 8:47 AM, Robert Haas robertmh...@gmail.com wrote:
$ ./pg_archivecleanup -x bz2 /tmp 000100010058
Hmm, but I thought that the idea was that the extension was optional.
Perhaps I'm
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs si...@2ndquadrant.com wrote:
These patches aren't marked with a committer
I think the ECPG fetch patch is about ready to go. Normally Michael
Meskes handles all ECPG patches, but I'm not sure what his
On 4/3/12 11:30 PM, Greg Smith wrote:
On 03/25/2012 04:29 PM, Jim Nasby wrote:
Another $0.02: I don't recall the community using pg_bench much at all to
measure latency... I believe it's something fairly new. I point this out
because I believe there are differences in analysis that you need
On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs si...@2ndquadrant.com wrote:
These patches aren't marked with a committer
FK arrays
ECPG fetch
foreign stats
command triggers
check function
parallel pg_dump
Does that
On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs si...@2ndquadrant.com wrote:
These patches aren't marked with a committer
FK arrays
ECPG fetch
2012/4/5 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 05.04.2012 21:00, Robert Haas wrote:
Heikki recently produced a revision of the check function patch, but
I'm not sure whether he's planning to commit that or whether it's a
demonstration of a broader rework he wants Pavel
On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In fact, for *most* of these patches the fact that they're still here
should give you pause about just committing them.
Um, yeah.
I am not sure what the state of the foreign stats patch is, or FK arrays.
I'm taking the
Excerpts from Simon Riggs's message of jue abr 05 14:28:54 -0300 2012:
These patches aren't marked with a committer
FK arrays
ECPG fetch
foreign stats
command triggers
check function
parallel pg_dump
Does that mean myself or others should be claiming them for commit/reject?
The FK
On Thu, Apr 5, 2012 at 7:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The FK arrays one I'm kind of queasy about. It's a cool-sounding idea
but I'm not convinced that all the corner-case details have been
adequately thought through, and I'm scared of being unable to fix any
such bugs in later
On Thu, Apr 5, 2012 at 2:37 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
The FK locking patch isn't on this list; however, I'm hijacking this
thread to say that some benchmarking runs we tried weren't all that
great, showing 9% performance degradation on stock pgbench -- i.e. a
large
On Thu, Apr 5, 2012 at 7:37 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
The FK locking patch isn't on this list;
We'd agreed you were the assigned committer, hence not on list.
however, I'm hijacking this
thread to say that some benchmarking runs we tried weren't all that
great,
On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote:
On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs si...@2ndquadrant.com wrote:
These patches
On 25 March 2012 09:17, Simon Riggs si...@2ndquadrant.com wrote:
The main thing we're waiting on are the performance tests to confirm
the lack of regression.
I have extensively benchmarked the latest revision of the patch
(tpc-b.sql), which I pulled from Alvaro's github account. The
benchmark
On Thu, Apr 05, 2012 at 02:23:03PM -0400, Tom Lane wrote:
I think the ECPG fetch patch is about ready to go. Normally Michael
Meskes handles all ECPG patches, but I'm not sure what his schedule is
like. I'm not sure what the politics are of someone else touching
that code.
I think we
On Thu, 2012-04-05 at 20:46 +0200, Hannu Krosing wrote:
On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote:
On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs si...@2ndquadrant.com wrote:
...
I think doing so will cause substantial misery for many users. I find
it hard to believe that such a
On 04/05/2012 02:00 PM, Robert Haas wrote:
I think Andrew is working on parallel pg_dump, so I suspect the rest
of us should stay out of the way. I've also looked at it extensively
and will work on it if Andrew isn't, but I don't think it's ready to
commit. A few preliminary pieces could go
On Thu, Apr 5, 2012 at 2:46 PM, Hannu Krosing ha...@krosing.net wrote:
To me it looked like the scope of the patch started to suddenly expand
exponentially a few days ago from a simple COMMAND TRIGGERS, which would
have finally enabled trigger-based or logical replication systems to
do full
On Thu, Apr 5, 2012 at 2:58 PM, Hannu Krosing ha...@krosing.net wrote:
On Thu, 2012-04-05 at 20:46 +0200, Hannu Krosing wrote:
On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote:
On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs si...@2ndquadrant.com wrote:
...
I think doing so will cause
Excerpts from Robert Haas's message of jue abr 05 15:40:17 -0300 2012:
On Thu, Apr 5, 2012 at 2:37 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
The FK locking patch isn't on this list; however, I'm hijacking this
thread to say that some benchmarking runs we tried weren't all that
On Thu, 2012-04-05 at 15:02 -0400, Robert Haas wrote:
On Thu, Apr 5, 2012 at 2:46 PM, Hannu Krosing ha...@krosing.net wrote:
To me it looked like the scope of the patch started to suddenly expand
exponentially a few days ago from a simple COMMAND TRIGGERS, which would
have finally enabled
On Fri, Mar 23, 2012 at 7:41 PM, Marti Raudsepp ma...@juffo.org wrote:
Yeah, I'm still working on addressing the comments from your last email.
Haven't had much time to work on it for the last 2 weeks, but I hope
to finish most of it this weekend.
Since the updated patch seems never to have
On Thu, 2012-04-05 at 15:07 -0400, Robert Haas wrote:
On Thu, Apr 5, 2012 at 2:58 PM, Hannu Krosing ha...@krosing.net wrote:
Would it be possible to put some command trigger hooks in a few
strategic places so that some trigger-like functionality could be loaded
at run time, mainly with a
On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing ha...@krosing.net wrote:
For me it would be enough to know if the trigger is fired by top-level
command or not.
Well, you would have been out of luck, then.
- The patch isn't safe if the triggers try to execute DDL on the
object being modified.
On Thu, 2012-04-05 at 15:30 -0400, Robert Haas wrote:
On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing ha...@krosing.net wrote:
For me it would be enough to know if the trigger is fired by top-level
command or not.
Well, you would have been out of luck, then.
It seemed to me you were coming
On Thu, Apr 5, 2012 at 8:30 PM, Robert Haas robertmh...@gmail.com wrote:
I am speaking up now as this is the first time I am told I have to wait
another year for this feature to arrive.
Really? You've never seen a patch punted to the next release before
because it wasn't robust enough?
On 4/5/12 12:56 PM, Hannu Krosing wrote:
Really? You've never seen a patch punted to the next release before
because it wasn't robust enough? Considering that I see your name
mentioned in the 8.2 release notes, I find that a bit hard to believe.
I must admit I did check it only
On Thu, Apr 5, 2012 at 3:56 PM, Hannu Krosing ha...@krosing.net wrote:
On Thu, 2012-04-05 at 15:30 -0400, Robert Haas wrote:
On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing ha...@krosing.net wrote:
For me it would be enough to know if the trigger is fired by top-level
command or not.
Well,
On Thu, Apr 5, 2012 at 4:38 PM, Josh Berkus j...@agliodbs.com wrote:
On 4/5/12 12:56 PM, Hannu Krosing wrote:
Really? You've never seen a patch punted to the next release before
because it wasn't robust enough? Considering that I see your name
mentioned in the 8.2 release notes, I find
On Thu, Apr 5, 2012 at 1:40 PM, Robert Haas robertmh...@gmail.com wrote:
Yep. I think Tom and I and others were all pretty clear that there
were not enough people reviewing this CommitFest,
Sorry to derail the thread just a little, but I've thought a little
about this and I wonder if part of
Robert Haas robertmh...@gmail.com writes:
I am not interested in relitigating on this thread what has already
been extensively discussed nearby. Dimitri and I agreed on numerous
changes to try to make the behavior sane, and those changes were
suggested and agreed to for good reason. We
On Thu, Apr 5, 2012 at 4:27 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Apr 5, 2012 at 8:30 PM, Robert Haas robertmh...@gmail.com wrote:
I am speaking up now as this is the first time I am told I have to wait
another year for this feature to arrive.
Really? You've never seen a patch
On Thu, Apr 5, 2012 at 08:00, Tatsuo Ishii is...@postgresql.org wrote:
Those code fragment judges the return value from
SSL_read(). secure_read() does retrying when SSL_ERROR_WANT_READ *and*
SSL_ERROR_WANT_WRITE returned. However, pqsecure_read() does not retry
when SSL_ERROR_WANT_READ. It
On Thu, Apr 5, 2012 at 5:04 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Those changes are about done now.
Huh? AFAICS, there are vestiges of the old terminology all over the
patch, although some very incomplete renaming has been done. I'm
pretty sure you haven't made the firing points
Robert Haas robertmh...@gmail.com writes:
Huh? AFAICS, there are vestiges of the old terminology all over the
patch, although some very incomplete renaming has been done. I'm
pretty sure you haven't made the firing points consistent either,
although I'd have to spend more time reviewing to
Excerpts from Peter Eisentraut's message of jue abr 05 13:52:13 -0300 2012:
On ons, 2012-03-28 at 01:49 +0300, Alex wrote:
Attached is a gzipped v10, complete with the above fixes and fixes to
bugs found by Heikki. Documentation and code comments are also
finally updated.
The compiler
Hi,
I attach a patch to correct various system catalog/view definitions in the docs.
Regards
Thom
catalog_doc_fixes.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Fri, 2012-04-06 at 00:02 +0200, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
Huh? AFAICS, there are vestiges of the old terminology all over the
patch, although some very incomplete renaming has been done. I'm
pretty sure you haven't made the firing points
Magnus Hagander mag...@hagander.net writes:
If anything, we should be changing it to TLSv1 in both client and
server, since every client out there now should be using that anyway,
given that the client has been specifying it for a long time.
Huh? libpq isn't every client.
Hi,
I've tried out pg_receivexlog and have noticed that when restarting
the cluster, pg_receivexlog gets cut off... it doesn't keep waiting.
This is surprising as the DBA would have to remember to start
pg_receivexlog up again.
--
Thom
--
Sent via pgsql-hackers mailing list
Why was this code:
#ifdef WIN32
if (parallel_init_done GetCurrentThreadId() != mainThreadId)
ExitThread(code);
#endif
removed from dumputils.c by commit
5e86c61a7eec0fdc6961493a150159fa8fc63b1c? The commit message doesn't
refer to it at all.
I don't understand it
On Thu, Apr 05, 2012 at 02:34:30PM -0400, Robert Haas wrote:
On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The FK arrays one I'm kind of queasy about. ?It's a cool-sounding idea
but I'm not convinced that all the corner-case details have been
adequately thought through,
On 5 April 2012 23:22, Thom Brown t...@linux.com wrote:
Hi,
I attach a patch to correct various system catalog/view definitions in the
docs.
I also found a couple typos in completely different sections. (patch attached)
--
Thom
doc_typo_fixes.patch
Description: Binary data
--
Sent via
On 6 April 2012 01:22, Thom Brown t...@linux.com wrote:
On 5 April 2012 23:22, Thom Brown t...@linux.com wrote:
Hi,
I attach a patch to correct various system catalog/view definitions in the
docs.
I also found a couple typos in completely different sections. (patch attached)
Apologies,
postgres=# select '{}'::integer[] = array[[]]::integer[][];
?column?
--
t
postgres=# select '{}'::integer[] = array[[[]]]::integer[][][];
?column?
--
t
From this point of view, seems N dimensions of empty array all are equivalent.
But the result of array_length of them
On Thu, Apr 5, 2012 at 8:12 PM, Andrew Dunstan and...@dunslane.net wrote:
Why was this code:
#ifdef WIN32
if (parallel_init_done GetCurrentThreadId() != mainThreadId)
ExitThread(code);
#endif
removed from dumputils.c by commit 5e86c61a7eec0fdc6961493a150159fa8fc63b1c?
On Tue, Apr 3, 2012 at 8:28 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Might as well jump in with both feet:
autovacuum_naptime = 1s
autovacuum_vacuum_threshold = 1
autovacuum_vacuum_scale_factor = 0.0
If that smooths the latency peaks and doesn't hurt performance too
much, it's
Thanks, Hanada-san!
Best regards,
Etsuro Fujita
-Original Message-
From: Shigeru HANADA [mailto:shigeru.han...@gmail.com]
Sent: Friday, April 06, 2012 11:41 AM
To: Etsuro Fujita
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] WIP: Collecting statistics on CSV file data
95 matches
Mail list logo
