On Thu, Jan 23, 2014 at 9:27 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Wed, Jan 22, 2014 at 9:28 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 01/22/2014 02:17 PM, Alexander Korotkov wrote:
We already spent a lot of time with compression. Now we need to figure
out
On 24 January 2014 07:08, Peter Geoghegan p...@heroku.com wrote:
On Wed, Jan 15, 2014 at 6:57 AM, Simon Riggs si...@2ndquadrant.com wrote:
v15 to fix the above problem.
Minor quibble: I get a compiler warning with the patch applied.
relcache.c: In function 'RememberToFreeTupleDescAtEOX':
On 01/24/2014 10:03 AM, Alexander Korotkov wrote:
ITSM I found this bug. ginVacuumPostingTreeLeaf re-encodes only some
segments. Others are not even re-palloced. They are moved left
in dataPlaceToPageLeafRecompress by memcpy. But it's incorrect to with
memcpy, proper solution is memmove. Using
On Fri, Jan 24, 2014 at 12:50 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 01/24/2014 10:03 AM, Alexander Korotkov wrote:
ITSM I found this bug. ginVacuumPostingTreeLeaf re-encodes only some
segments. Others are not even re-palloced. They are moved left
in
Sergey Muraviov sergey.k.murav...@gmail.com writes:
I can't apply the patch.
Did you try using the `patch`(1) command?
The PostgreSQL project policy is to not use the git format when sending
patches to the mailing list, prefering the context diff format. So you
need to resort to using the basic
Hi all
I've hit an interesting wrinkle and am interested in opinions. By
integrating updatable security barrier view support with row-security,
it has become a lot harder to detect and prevent infinite recursion
(including mutual recursion) in row-security policy expansion.
The code is attached,
On 01/24/2014 10:53 AM, Alexander Korotkov wrote:
OK. What about previous fix in assert?
Ah right, fixed that too now.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello,
I started reviewing the patch. Go through the original mail thread to
understand
the need of fix and the actual problem.
http://www.postgresql.org/message-id/20121002155857.ge30...@momjian.us
Patch is using pg_valid_server_encoding() to compare the encoding which
looks
more correct. Did
From: Andrew Dunstan and...@dunslane.net
Is there any reason why pgbench is listed in @client_program_files as
well as @client_contribs? AFAICT it should only be in the latter.
Thank you for reviewing the patch. Yes, you are right. I removed pgbench
from @client_program_files. In addition,
Hello,
My customer reported the following problem on Windows. I'm afraid this is a
serious problem, and I think we should provide a fix in the next minor
release. I've attached a fix, and I would wish it to be back-ported.
[Problem]
The customer is using 64-bit PostgreSQL 9.1.x on Windows
From: MauMau maumau...@gmail.com
OK, I added several lines for this. Please check the attached patch.
I'm sorry, I attached the old patch as v5 in my previous mail. Attached on
this mail is the correct one.
I'll update the CommitFest entry soon.
Regards
MauMau
pg_ctl_eventsrc_v5.patch
On 24 January 2014 09:04, Craig Ringer cr...@2ndquadrant.com wrote:
Hi all
I've hit an interesting wrinkle and am interested in opinions. By
integrating updatable security barrier view support with row-security,
it has become a lot harder to detect and prevent infinite recursion
(including
On Fri, Jan 24, 2014 at 1:19 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 01/24/2014 10:53 AM, Alexander Korotkov wrote:
OK. What about previous fix in assert?
Ah right, fixed that too now.
Good, now my test-suite passed. Results are so.
Time of operations
event
Hi, Heiki-san,
From: MauMau maumau...@gmail.com
From: Heikki Linnakangas hlinnakan...@vmware.com
After some refactoring and fixing bugs in the existing code, I came up
with the attached patch. I called the option simply recovery_target,
with the only allowed value of immediate. IOW, if you
On 01/24/2014 01:20 AM, Marco Atzeri wrote:
AFAICT the regression is in Cygwin. The buildfarm passes because it's
using an oldish Cygwin release, 1.7.7 rather than the current 1.7.27. I
have brought the regression the athe attention of the Cygwin people in
the past, but without response.
On Fri, Jan 24, 2014 at 6:57 AM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Sergey Muraviov sergey.k.murav...@gmail.com writes:
I can't apply the patch.
Did you try using the `patch`(1) command?
The PostgreSQL project policy is to not use the git format when sending
patches to the
On Thu, Jan 23, 2014 at 8:22 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 01/14/2014 05:35 PM, Alexander Korotkov wrote:
Attached version is rebased against last version of packed posting lists.
Thanks!
I think we're missing a trick with multi-key queries. We know that when
From: Fujii Masao masao.fu...@gmail.com
I think that 77035fa8a92d8c39f4c689e54f46813f203f09a8 fixed this problem.
Please check that.
I looked through your patch. I'm fine with the PQhostaddr(). I didn't
notice the problem when hostaddr was passed to psql on Windows.
OTOH, regarding
On 11th June 2013, Markus Wanner wrote:
Agreed. Postgres-R uses a CommitOrderId, which is very similar in
concept, for example.
Do you think having this snapshot scheme would be helpful for
Postgres-R?
Yeah, it could help to reduce patch size, after a rewrite to use such a
CSN.
On Fri, Jan 24, 2014 at 9:00 PM, MauMau maumau...@gmail.com wrote:
From: Fujii Masao masao.fu...@gmail.com
I think that 77035fa8a92d8c39f4c689e54f46813f203f09a8 fixed this problem.
Please check that.
I looked through your patch. I'm fine with the PQhostaddr(). I didn't
notice the problem
On 24/01/2014 12:56, Andrew Dunstan wrote:
On 01/24/2014 01:20 AM, Marco Atzeri wrote:
AFAICT the regression is in Cygwin. The buildfarm passes because it's
using an oldish Cygwin release, 1.7.7 rather than the current 1.7.27. I
have brought the regression the athe attention of the Cygwin
From: Fujii Masao masao.fu...@gmail.com
On Wed, Jan 22, 2014 at 6:37 AM, Heikki Linnakangas
Thanks! The patch looks good to me. Attached is the updated version of
the patch. I added the comments.
Thank you very much. Your comment looks great. I tested some recovery
situations, and
On Jan24, 2014, at 08:47 , Dean Rasheed dean.a.rash...@gmail.com wrote:
I think it should probably be broken up. It might be overly ambitious
to try to get all of this committed during this commitfest, and in any
case, I suspect that the committer would probably choose to commit it
in stages.
From: Fujii Masao masao.fu...@gmail.com
On Fri, Jan 24, 2014 at 9:00 PM, MauMau maumau...@gmail.com wrote:
OTOH, regarding PQhost(), I think we had better take my patch.
connectOptions2() computes and set derived values to PGconn, so that
PGconn's members have values which are actually used for
Am 23.01.14 02:14, schrieb Jim Nasby:
On 1/19/14, 5:51 PM, Dave Chinner wrote:
Postgres is far from being the only application that wants this; many
people resort to tmpfs because of this:
https://lwn.net/Articles/499410/
Yes, we covered the possibility of using tmpfs much earlier in the
On Thu, Jan 23, 2014 at 2:01 AM, Greg Stark st...@mit.edu wrote:
On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus j...@agliodbs.com wrote:
Probably Heroku has some more specific exploit case to be concerned
about here; if so, might I suggest taking it up with the -security list?
I don't think
Bruce Momjian br...@momjian.us writes:
On Thu, Jan 23, 2014 at 10:39:34PM -0500, Tom Lane wrote:
I'm not convinced that this improves anything. The problem might not in
fact be either of the things you mention, in which case the new message
is outright misleading. Also, what of the policy
Rushabh, really sorry I have to re-create the patch and thanks a
lot for looking at it!
Looking at the patch once again, I see that there were at least two
problems. Firstly, I used the equivalent_locale function also on the
encoding values. Even if that should not cause bugs (as it should
On Fri, Jan 24, 2014 at 6:46 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Jan 23, 2014 at 2:01 AM, Greg Stark st...@mit.edu wrote:
On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus j...@agliodbs.com wrote:
Probably Heroku has some more specific exploit case to be concerned
about here;
On 8 November 2013 20:11, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Erik Rijkers wrote:
On Thu, September 26, 2013 00:34, Erik Rijkers wrote:
On Wed, September 25, 2013 22:34, Alvaro Herrera wrote:
[minmax-5.patch]
I have the impression it's not quite working correctly.
Here's a
On Thu, Jan 23, 2014 at 6:32 PM, Andres Freund and...@2ndquadrant.com wrote:
I also wonder if we should use the
terminology attach instead of acquire; that pairs more naturally
with release. Then the message, if we want more than an assert,
might be this backend is already attached to a
On Tue, Jan 14, 2014 at 06:04:47PM +0900, Kyotaro HORIGUCHI wrote:
I proposed 3 types of solution but the one of them - tweaking
Equivalence Class (Type 1)- was dismissed because of
inappropriate manipulation on Equivalence Class. The rest do
essentially the same thing - flattening appendrels
Hi
Now patch applies cleanly and works. :-)
But I have some notes:
1. There is an odd underscore character in functions
find_in_extension_control_path and list_extension_control_paths:
\extension_control__path\
2. If we have several versions of one extension in different directories
(which are
On 01/23/2014 07:22 PM, Alvaro Herrera wrote:
If you ask me, I'd like autovac to know when not to run (or rather
wait a bit, not forever), perhaps by checking load factors or some
other tell-tale of an already-saturated I/O system.
We had a proposed design to tell autovac when not to run (or
On 2014-01-24 12:10:50 -0500, Robert Haas wrote:
Unfortunately not. Inside the walsender there's currently no
LWLockReleaseAll() for ERRORs since commands aren't run inside a
transaction command...
But maybe I should have fixed this by adding the release to
WalSndErrorCleanup()
I wrote:
I agree with doing *something*, but this particular thing seems to violate
our very long-standing policy on how to deal with authentication failures,
as well as being too vague to be really useful.
What would be well within that policy is to log additional information
into the
Thom Brown wrote:
On 8 November 2013 20:11, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Erik Rijkers wrote:
On Thu, September 26, 2013 00:34, Erik Rijkers wrote:
On Wed, September 25, 2013 22:34, Alvaro Herrera wrote:
[minmax-5.patch]
I have the impression it's not quite
On 24 January 2014 17:53, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Thom Brown wrote:
On 8 November 2013 20:11, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Erik Rijkers wrote:
On Thu, September 26, 2013 00:34, Erik Rijkers wrote:
On Wed, September 25, 2013 22:34, Alvaro Herrera
On Fri, Jan 24, 2014 at 2:44 PM, Josh Berkus j...@agliodbs.com wrote:
On 01/23/2014 07:22 PM, Alvaro Herrera wrote:
If you ask me, I'd like autovac to know when not to run (or rather
wait a bit, not forever), perhaps by checking load factors or some
other tell-tale of an already-saturated
On Fri, Jan 24, 2014 at 2:54 PM, Thom Brown t...@linux.com wrote:
On 24 January 2014 17:53, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Thom Brown wrote:
On 8 November 2013 20:11, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Erik Rijkers wrote:
On Thu, September 26, 2013 00:34, Erik
On 01/24/2014 01:58 PM, Alexander Korotkov wrote:
On Thu, Jan 23, 2014 at 8:22 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
In summary, these are fairly small patches, and useful on their, so I
think these should be committed now. But please take a look and see if the
logic in
On 01/22/2014 12:49 PM, Andrew Dunstan wrote:
On 01/21/2014 06:21 PM, Marko Tiikkaja wrote:
Hi Andrew,
On 1/18/14, 10:05 PM, I wrote:
But I'll continue with my review now that this has been sorted out.
Sorry about the delay.
I think the API for the new functions looks good. They are all
It seems CREATE TABLE ... (LIKE INCLUDING CONSTRAINTS) doesn't work
cleanly when there's also regular inheritance; my guess is that attnums
get messed up at some point after the constraints are generated.
Here's a trivial test case:
create table b (b1 int unique check (b1 100));
CREATE TABLE c
On 01/24/2014 01:37 PM, MauMau wrote:
Hi, Heiki-san,
From: MauMau maumau...@gmail.com
From: Heikki Linnakangas hlinnakan...@vmware.com
After some refactoring and fixing bugs in the existing code, I came up
with the attached patch. I called the option simply recovery_target,
with the only
For consistency with the existing json functions (json_each,
json_each_text, etc.) it might be better to add separate
json_to_record_text and json_to_recordset_text functions in place of the
nested_as_text parameter to json_to_record and json_to_recordset.
On 24 January 2014 10:26, Andrew
On Thu, Jan 23, 2014 at 4:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Jan 9, 2014 at 6:36 AM, Gabriele Bartolini
gabriele.bartol...@2ndquadrant.it wrote:
Il 08/01/14 18:42, Simon Riggs ha scritto:
Not sure I see why it needs to be an SRF. It only returns one row.
Attached
ISTM the consensus is that we need better monitoring/administration
interfaces so that people can script the behavior they want in external
tools. Also, a new synchronous apply replication mode would be handy,
but that'd be a whole different patch. We don't have a patch on the
table that we
On 01/24/2014 03:40 PM, Laurence Rowe wrote:
For consistency with the existing json functions (json_each,
json_each_text, etc.) it might be better to add separate
json_to_record_text and json_to_recordset_text functions in place of
the nested_as_text parameter to json_to_record and
On 01/24/2014 12:59 PM, Andrew Dunstan wrote:
On 01/24/2014 03:40 PM, Laurence Rowe wrote:
For consistency with the existing json functions (json_each,
json_each_text, etc.) it might be better to add separate
json_to_record_text and json_to_recordset_text functions in place of
the
On 01/24/2014 12:47 PM, Heikki Linnakangas wrote:
ISTM the consensus is that we need better monitoring/administration
interfaces so that people can script the behavior they want in external
tools. Also, a new synchronous apply replication mode would be handy,
but that'd be a whole different
On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian br...@momjian.us wrote:
Is everyone else OK with this approach? Updated patch attached.
Hi,
I started to look at this patch and i found that it fails an assertion
as soon as you run a VACUUM FULL after a lazy VACUUM even if those are
on
On Jan24, 2014, at 22:29 , Josh Berkus j...@agliodbs.com wrote:
On 01/24/2014 12:47 PM, Heikki Linnakangas wrote:
ISTM the consensus is that we need better monitoring/administration
interfaces so that people can script the behavior they want in external
tools. Also, a new synchronous apply
We're finding it more and more common for people to define partitioned
table views with hundreds or thousands of union branches.
pg_get_viewdefs indents each branch of the union by 8 spaces more than
the previous branch. The net effect is that the size of the output is
O(n^2) bytes just for the
Greg Stark st...@mit.edu writes:
We're finding it more and more common for people to define partitioned
table views with hundreds or thousands of union branches.
Really? Given how poorly the system performs with that many inheritance
children, I've got a hard time believing either that this is
Since the point release we've run into a number of databases that when
we restore from a base backup end up being larger than the primary
database was. Sometimes by a large factor. The data below is from
9.1.11 (both primary and standby) but we've seen the same thing on
9.2.6.
primary$ for i in
On Fri, Jan 24, 2014 at 6:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
pg_get_viewdefs indents each branch of the union by 8 spaces more than
the previous branch.
I think that's because the unions are a nested binary tree so far as the
parsetree representation goes. We could probably teach
Argh. Attached is a plain text file with that query data. I'll be
switching back to Gnus any day now.
daeqck898dvduj= select ev_class::regclass, length(ev_action)
rewrite_len,length(pg_get_viewdef(ev_class,true)) prettyprint_len,
length(pg_get_viewdef(ev_class,false)) non_prettyprint_len from
Greg Stark st...@mit.edu writes:
But it strikes me that pg_dump, at least when not doing an SQL dump,
really has no reason to ask for indentation at all. It's already
asking for non-prettyprinted output, why not make non-prettyprinted
also mean non-indented?
We do go to some effort to make
[restored Cc: list]
On Thu, Jan 09, 2014 at 10:12:28PM -0800, Wim Lewis wrote:
I applied both libpq.tls11plus.diff and the related
psql.conninfo.tlsver.diff patch to postgresql git head.
psql.conninfo.tlsver.diff is not so essential for debugging purposes since
commit
On Fri, Jan 24, 2014 at 12:49 PM, Andres Freund and...@2ndquadrant.com wrote:
But this code is riddled with places where you track a catalog xmin
and a data xmin separately. The only point of doing it that way is to
support a division that hasn't been made yet.
If you think it will make
On Fri, Jan 24, 2014 at 6:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
We're finding it more and more common for people to define partitioned
table views with hundreds or thousands of union branches.
Really? Given how poorly the system performs with that many
On Fri, Jan 24, 2014 at 8:49 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 24, 2014 at 6:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
We're finding it more and more common for people to define partitioned
table views with hundreds or thousands of union
On Fri, Jan 24, 2014 at 12:58 PM, Claudio Freire klaussfre...@gmail.com wrote:
What's the status?
I believe I have more than a use for minmax indexes, and wouldn't mind
lending a hand if it's within my grasp.
I'm also interested in looking at this. Mostly because I have ideas
for other
On Fri, Jan 24, 2014 at 04:52:55PM -0500, Jaime Casanova wrote:
On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian br...@momjian.us wrote:
Is everyone else OK with this approach? Updated patch attached.
Hi,
I started to look at this patch and i found that it fails an assertion
as soon
On Fri, Jan 24, 2014 at 6:57 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
Would be nice if we can use git apply command...
git apply seems to have raised pedantry to an art form. Not only
won't it apply patches in any format other than the one it likes,
it'll fail to apply any
On Fri, Jan 24, 2014 at 8:53 PM, Greg Stark st...@mit.edu wrote:
On Fri, Jan 24, 2014 at 8:49 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 24, 2014 at 6:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
We're finding it more and more common for people to
Hi Fujita-san,
Thanks for the review.
2014/1/23 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
Shigeru Hanada wrote:
Though this would be debatable, in current implementation, constraints
defined on a foreign table (now only NOT NULL and CHECK are supported)
are not enforced during INSERT or
On Fri, Jan 24, 2014 at 10:10:00AM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Jan 23, 2014 at 10:39:34PM -0500, Tom Lane wrote:
I'm not convinced that this improves anything. The problem might not in
fact be either of the things you mention, in which case the new
On Thu, Jan 23, 2014 at 7:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-23 19:29:23 -0500, Tom Lane wrote:
I concur with the other reports that the main problem in this test case is
just that the default cost delay settings throttle
On Sun, Nov 24, 2013 at 02:03:18AM +0100, Vik Fearing wrote:
On 10/15/2013 07:50 AM, David Fetter wrote:
On Mon, Oct 07, 2013 at 11:16:56PM -0700, David Fetter wrote:
Folks,
Please find attached a patch implementing and documenting, to some
extent, $subject. I did this in aid of being
On Sat, Jan 25, 2014 at 5:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 23, 2014 at 4:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Jan 9, 2014 at 6:36 AM, Gabriele Bartolini
gabriele.bartol...@2ndquadrant.it wrote:
Il 08/01/14 18:42, Simon Riggs ha scritto:
On Sat, Jan 25, 2014 at 5:10 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Thanks, committed!
It seems that this patch has not been pushed :)
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
72 matches
Mail list logo
