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 .
So I would like
On 07/10/2013 07:28 AM, Atri Sharma wrote:
I am not sure if the part you mentioned is inline with the case I am
talking about.
Can you please post an example of such a join removal? I mean a query
before and after the removal. Thanks,
//Tony
--
Sent via pgsql-hackers mailing list
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
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 this is also
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 motivates this. It's
On Wed, Jul 10, 2013 at 1:11 PM, Hannu Krosing ha...@2ndquadrant.com 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
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 to
On Wed, Jul 10, 2013 at 9:25 AM, Craig Ringer cr...@2ndquadrant.com 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:
On Wed, Jul 10, 2013 at 10:25 AM, Craig Ringer cr...@2ndquadrant.com 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:
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
mohsen soodkhah mohammadi mohsensoodk...@gmail.com 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
--
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
On Fri, Jul 5, 2013 at 12:16 PM, Pavel Stehule pavel.steh...@gmail.com 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
On Wed, Jul 10, 2013 at 2:54 AM, ivan babrou ibob...@gmail.com wrote:
On 9 July 2013 19:17, Dmitriy Igrishin dmit...@gmail.com wrote:
2013/7/9 Merlin Moncure mmonc...@gmail.com
On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou ibob...@gmail.com wrote:
Hi, guys! I made a quick patch to support
Yes, I wrote a separate patch for next commitfest.
Dne 10.7.2013 16:54 Josh Kupershmidt schmi...@gmail.com napsal(a):
On Fri, Jul 5, 2013 at 12:16 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am sending a patch that removes strict requirements for DROP IF
EXISTS statements. This
On Tue, Jul 2, 2013 at 5:39 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2013/3/8 Josh Kupershmidt schmi...@gmail.com:
Cool. I think it would also be useful to
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
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
On 9 July 2013 19:17, Dmitriy Igrishin dmit...@gmail.com wrote:
2013/7/9 Merlin Moncure mmonc...@gmail.com
On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou ibob...@gmail.com wrote:
Hi, guys! I made a quick patch to support floating number in
connect_timeout param for libpq. This will treat
On 9 July 2013 18:43, Andres Freund and...@2ndquadrant.com 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
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
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 patch, but only
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
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 Intel(R)
On Wed, Jul 10, 2013 at 10:00 AM, Josh Berkus j...@agliodbs.com 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
On 07/09/2013 01:18 PM, Merlin Moncure wrote:
On Fri, Jul 5, 2013 at 3:01 PM, Josh Berkus j...@agliodbs.com 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
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 on
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 kgri...@ymail.com wrote:
Andres Freund and...@2ndquadrant.com wrote:
Otherwise, could you try applying my git tree so we are
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
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 kgri...@ymail.com wrote:
Andres
On Tue, Jul 2, 2013 at 7:47 AM, Pavel Stehule pavel.steh...@gmail.com 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
Andres Freund and...@2ndquadrant.com wrote:
Kevin Grittner kgri...@ymail.com 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
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
On 2013-07-10 15:14:58 -0700, Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com wrote:
Kevin Grittner kgri...@ymail.com 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
--On 8. Juli 2013 16:04:31 + Dean Rasheed dean.a.rash...@gmail.com
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
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
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 .
So I would
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 asking
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/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 apparently
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 bunch of
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)
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
On Wed, Jul 10, 2013 at 8:42 PM, Prabakaran, Vaishnavi
vaishna...@fast.au.fujitsu.com 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
On Sun, Jul 7, 2013 at 12:49 AM, Robins Tharakan thara...@gmail.com 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.
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
Andres Freund and...@2ndquadrant.com 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
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
On Wed, Jul 10, 2013 at 8:42 PM, Prabakaran, Vaishnavi
vaishna...@fast.au.fujitsu.com 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
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
50 matches
Mail list logo