On 11 July 2013 00:03, Bernd Helmle wrote:
>
>
> --On 8. Juli 2013 16:04:31 + Dean Rasheed
> wrote:
>
>> * pg_relation_is_updatable is only available in 9.3, whereas psql may
>> connect to older servers, so it needs to guard against that.
>>
>
> Oh of course, i forgot about this. Thanks for p
Hello Tatsuo,
For me, the error message is not quite right, because progress == 0
case is considered error as well in your patch. I sugges you change
the error message something like:
"thread progress delay (-P) must be positive number (%s)\n",
Please find attached a new vers
On Thu, Jul 11, 2013 at 4:20 AM, Alvaro Herrera
wrote:
> I'm having a look at the SSL support code, because one of our customers
> reported it behaves unstably when the network is unreliable. I have yet
> to reproduce the exact problem they're having, but while reading the
> code I notice this i
At 2013-07-10 09:47:34 -0700, j...@agliodbs.com wrote:
>
> Due to the apparent lack of performance testing, I'm setting this back
> to "needs review".
The original submission (i.e. the message linked from the CF page)
includes test results that showed a clear performance improvement.
Here's an exc
On Wed, Jul 10, 2013 at 8:42 PM, Prabakaran, Vaishnavi
wrote:
> Hi Berkus,
>
> Thanks for your time and response.
>
> I do understand that there is no LIKE operator support for integers and it
> would be great if you could help me understand the reason why is it not
> supported.
>
> My intentio
> If the renegotiation fails
AH! Now I remember. SSL clients can optionally renegotiate, it's not
required to renegotiate the session if the other side chooses not to
(almost certainly due to a bug or limitation in the client's connecting
library). By monkeying with the state, you can explicitly f
Andres Freund wrote:
> Any chance there still was an old replication slot around?
It is quite likely that there was.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 07/10/2013 09:04 PM, Josh Berkus wrote:
On 07/04/2013 06:11 AM, Cédric Villemain wrote:
Le mercredi 3 juillet 2013 23:56:42, Josh Berkus a écrit :
Peter, Cedric, etc.:
Where are we on this patch? Seems like discussion died out. Should it
be bounced?
I for myself have been presuaded that
On Sun, Jul 7, 2013 at 12:49 AM, Robins Tharakan wrote:
> Thanks Fabrizio.
>
> Although parallel_schedule was a miss for this specific patch, however, I
> guess I seem to have missed out serial_schedule completely (in all patches)
> and then thanks for pointing this out. Subsequently Robert too n
On Wed, Jul 10, 2013 at 8:42 PM, Prabakaran, Vaishnavi
wrote:
> Hi Berkus,
>
> Thanks for your time and response.
>
> I do understand that there is no LIKE operator support for integers and it
> would be great if you could help me understand the reason why is it not
> supported.
>
> My intention
Hi Berkus,
Thanks for your time and response.
I do understand that there is no LIKE operator support for integers and it
would be great if you could help me understand the reason why is it not
supported.
My intention is to know whether this is not supported because of any technical
limitation
Hi,
These are the relevant bits from Apache2.4's mod_ssl.
SSL_renegotiate(ssl);
SSL_do_handshake(ssl);
if (SSL_get_state(ssl) != SSL_ST_OK) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02225)
"Re-negotiatio
On 07/08/2013 12:00 PM, Josh Berkus wrote:
>>> (b) we can expect maybe a dozen to 18 of them in core based on the data
>>> >> types there, and I hate to clutter up /contrib, and
>> >
>> > Well, that's a matter of opinion. I'd be more happy with 250 contribs
>> > all on the same level versus a bunc
On 07/04/2013 06:11 AM, Cédric Villemain wrote:
> Le mercredi 3 juillet 2013 23:56:42, Josh Berkus a écrit :
>> Peter, Cedric, etc.:
>>
>> Where are we on this patch? Seems like discussion died out. Should it
>> be bounced?
>
> I for myself have been presuaded that it is a good idea. Things appa
> I think it's a waste of code to try to handle bushy trees. A list is
> not a particularly efficient representation of the pending list; this
> will probably be slower than recusing in the common case. I'd suggest
> keeping the logic to handle left-deep trees, which I find rather
> elegant, but
On 07/08/2013 12:51 PM, Josh Berkus wrote:
>
>> I think everything has been committed - as I think the CF app shows. The
>> only thing left in this srea from Cédric is the insallation of headers,
>> which Peter is down to review and is in "Waiting on Author" status.
>
> Yeah, that's the one I'm a
> Hello Tatsuo,
>
>> I have looked into this:
>> https://commitfest.postgresql.org/action/patch_view?id=1105
>> because it's marked as "Ready for committer". However I noticed that
>> you worried about other pgbench patches such as
>> https://commitfest.postgresql.org/action/patch_view?id=1103 .
>
Wow, that was a long time ago... I remember a few things about this
1) I was running in to an issue where every 64KB of transfer (or
something inanely low like that), SSL was being renegotiated. This was
causing performance problems over the wire. I think we settled on once
an hour renegotiatin
--On 8. Juli 2013 16:04:31 + Dean Rasheed
wrote:
* pg_relation_is_updatable is only available in 9.3, whereas psql may
connect to older servers, so it needs to guard against that.
Oh of course, i forgot about this. Thanks for pointing out.
* If we're doing this, I think we should d
On 2013-07-10 15:14:58 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > Kevin Grittner wrote:
>
> >> (2) An initial performance test didn't look very good. I will be
> >> running a more controlled test to confirm but the logical
> >> replication of a benchmark with a lot of UPDATEs of c
I think this block is better written as:
if (ssl_renegotiation_limit && port->count > ssl_renegotiation_limit *
1024L)
{
SSL_set_session_id_context(port->ssl, (void *) &SSL_context,
sizeof(SSL_context));
if (SSL_renego
Andres Freund wrote:
> Kevin Grittner wrote:
>> (2) An initial performance test didn't look very good. I will be
>> running a more controlled test to confirm but the logical
>> replication of a benchmark with a lot of UPDATEs of compressed text
>> values seemed to suffer with the logical repli
On Tue, Jul 2, 2013 at 7:47 AM, Pavel Stehule wrote:
> Hello
>
> remastered patch
>
> still there is a issue with dependencies
Several of the issues from my last review [1] seem to still be present
in this patch, such as review notes #1 and #4.
And as discussed previously, I think that the --cle
On 2013-07-10 12:21:23 -0700, Kevin Grittner wrote:
> Sorry for the delay in reviewing this. I must make sure never to
> take another vacation during a commitfest -- the backlog upon
> return is a killer
Heh. Yes. Been through it before...
> Kevin Grittner wrote:
> > Andres Freund wrote:
>
Hi,
I'm having a look at the SSL support code, because one of our customers
reported it behaves unstably when the network is unreliable. I have yet
to reproduce the exact problem they're having, but while reading the
code I notice this in be-secure.c:secure_write() :
if (ssl_renegotiatio
Sorry for the delay in reviewing this. I must make sure never to
take another vacation during a commitfest -- the backlog upon
return is a killer
Kevin Grittner wrote:
> Andres Freund wrote:
>> Otherwise, could you try applying my git tree so we are sure we
>> test the same thing?
>>
>> $
On 07/10/2013 09:27 AM, Christopher Browne wrote:
> The act of requesting to LISTEN requires doing a sort of update to the
> database. In elder versions, it put tuple(s) into pg_catalog.pg_listener,
> and that's Right Well Disallowed on a WAL-based replica.
>
> I would think that if you're keen o
On 07/09/2013 01:18 PM, Merlin Moncure wrote:
> On Fri, Jul 5, 2013 at 3:01 PM, Josh Berkus wrote:
>> It's fairly common with certain kinds of apps, including Rails and PHP.
>> This is one of the reasons why we've discussed having a kind of
>> stripped-down version of pgbouncer built into Postgre
On Wed, Jul 10, 2013 at 10:00 AM, Josh Berkus wrote:
> On 07/10/2013 09:53 AM, Benedikt Grundmann wrote:
>> Jane Street has a spare server we would like to donate to the postgres
>> community. We originally planed to use it for one of our database clusters
>> and it matches exactly what we use in
On 07/10/2013 09:53 AM, Benedikt Grundmann wrote:
> Jane Street has a spare server we would like to donate to the postgres
> community. We originally planed to use it for one of our database clusters
> and it matches exactly what we use in production at the moment.
>
> Rough specs:
> CPU: 8x Inte
Jane Street has a spare server we would like to donate to the postgres
community. We originally planed to use it for one of our database clusters
and it matches exactly what we use in production at the moment.
Rough specs:
CPU: 8x Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
MEM: 48GB
The ser
On 07/08/2013 10:11 AM, Josh Berkus wrote:
> On 06/23/2013 09:43 PM, Abhijit Menon-Sen wrote:
>> (Cc: to pgsql-performance dropped, pgsql-hackers added.)
>>
>> At 2013-05-06 09:14:01 +0100, si...@2ndquadrant.com wrote:
>>>
>>> New version of patch attached which fixes a few bugs.
>>
>> I read the p
Shouldn't be possible.
The act of requesting to LISTEN requires doing a sort of update to the
database. In elder versions, it put tuple(s) into pg_catalog.pg_listener,
and that's Right Well Disallowed on a WAL-based replica.
I would think that if you're keen on building an "event detection
subst
On 9 July 2013 18:43, Andres Freund wrote:
> On 2013-07-05 21:28:59 +0400, ivan babrou wrote:
>> Hi, guys! I made a quick patch to support floating number in
>> connect_timeout param for libpq. This will treat floating number as
>> seconds so this is backwards-compatible. I don't usually write in
On 9 July 2013 19:17, Dmitriy Igrishin wrote:
>
>
>
> 2013/7/9 Merlin Moncure
>>
>> On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou wrote:
>> > Hi, guys! I made a quick patch to support floating number in
>> > connect_timeout param for libpq. This will treat floating number as
>> > seconds so this
Hi masters of PostgreSQL,
I recently got asked about possibility of listening to notifications on warm
standby.
So question, how hard would that be to implement ?
Is it even possible without major changes to the architecture ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
Hi all,
Is there any reason not to tab-complete the local filename used by the
\lo_import command? Small patch to do so attached.
Josh
tab_complete_lo_import.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Jul 2, 2013 at 5:39 AM, Pavel Stehule wrote:
> 2013/3/8 Josh Kupershmidt :
>> On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule
>> wrote:
>>> 2013/3/8 Josh Kupershmidt :
>>
Cool. I think it would also be useful to check that --clean may only
be used with --format=p to avoid any co
Yes, I wrote a separate patch for next commitfest.
Dne 10.7.2013 16:54 "Josh Kupershmidt" napsal(a):
> On Fri, Jul 5, 2013 at 12:16 PM, Pavel Stehule
> wrote:
>
> > I am sending a patch that removes strict requirements for DROP IF
> > EXISTS statements. This behave is similar to our ALTER IF EXI
On Wed, Jul 10, 2013 at 2:54 AM, ivan babrou wrote:
> On 9 July 2013 19:17, Dmitriy Igrishin wrote:
>>
>>
>>
>> 2013/7/9 Merlin Moncure
>>>
>>> On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou wrote:
>>> > Hi, guys! I made a quick patch to support floating number in
>>> > connect_timeout param for
On Fri, Jul 5, 2013 at 12:16 PM, Pavel Stehule wrote:
> I am sending a patch that removes strict requirements for DROP IF
> EXISTS statements. This behave is similar to our ALTER IF EXISTS
> behave now.
+1 for this idea. But this patch should be treated as a separate issue
from the use of IF EXI
On 10.07.2013 02:54, Josh Berkus wrote:
On 07/08/2013 11:43 PM, Simon Riggs wrote:
1. MOVE SETTINGS
All settings move into the postgresql.conf.
Comment: AFAIK, all agree this.
Good to go then.
+1.
2. RELOCATE RECOVERY PARAMETER FILE(s)
As of 9.2, relocating the postgresql.conf means there
mohsen soodkhah mohammadi wrote:
> what is log switch and when it occur ?
What log are you talking about?
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mail
Hi Tom,
Following example does not work as expected:
-- Should return TRUE but returning FALSE
SELECT 'Programmer' ~ '(\w).*?\1' as t;
-- Should return P, a and er i.e. 3 rows but returning just one row with
-- value Programmer
SELECT REGEXP_SPLIT_TO_TABLE('Programmer','(\w).*?\1');
Initially I
On Wed, Jul 10, 2013 at 10:25 AM, Craig Ringer wrote:
> On 07/09/2013 11:30 PM, Andres Freund wrote:
>> On 2013-07-09 16:24:42 +0100, Greg Stark wrote:
>>> I note that git.postgresql.org's robot.txt refuses permission to crawl
>>> the git repository:
>>>
>>> http://git.postgresql.org/robots.txt
>>
On Wed, Jul 10, 2013 at 9:25 AM, Craig Ringer wrote:
> On 07/09/2013 11:30 PM, Andres Freund wrote:
>> On 2013-07-09 16:24:42 +0100, Greg Stark wrote:
>>> I note that git.postgresql.org's robot.txt refuses permission to crawl
>>> the git repository:
>>>
>>> http://git.postgresql.org/robots.txt
>>>
Peter,
On 07/09/2013 11:04 PM, Peter Eisentraut wrote:
> I think there is an intrinsic conflict here. You have things inside the
> database and outside. When they depend on each other, it gets tricky.
> Extensions were invented to copy with that. They do the job, more or
> less.
I agree. And t
On Wed, Jul 10, 2013 at 1:11 PM, Hannu Krosing wrote:
> On 07/10/2013 09:18 AM, Atri Sharma wrote:
>>> Can you please post an example of such a join removal? I mean a query before
>>> and after the removal. Thanks,
>> Courtesy Robert Haas:
>>
>> SELECT foo.x, foo.y, foo.z FROM foo WHERE foo.x = ba
On 07/09/2013 11:30 PM, Andres Freund wrote:
> On 2013-07-09 16:24:42 +0100, Greg Stark wrote:
>> I note that git.postgresql.org's robot.txt refuses permission to crawl
>> the git repository:
>>
>> http://git.postgresql.org/robots.txt
>>
>> User-agent: *
>> Disallow: /
>>
>>
>> I'm curious what mot
On 07/10/2013 09:18 AM, Atri Sharma wrote:
>> Can you please post an example of such a join removal? I mean a query before
>> and after the removal. Thanks,
> Courtesy Robert Haas:
>
> SELECT foo.x, foo.y, foo.z FROM foo WHERE foo.x = bar.x
>
> Conditions:
>
> 1) foo.x is not null.
I guess that thi
> Can you please post an example of such a join removal? I mean a query before
> and after the removal. Thanks,
Courtesy Robert Haas:
SELECT foo.x, foo.y, foo.z FROM foo WHERE foo.x = bar.x
Conditions:
1) foo.x is not null.
2) foo (x) is a foreign key referencing bar (x).
We can ignore bar co
51 matches
Mail list logo
