On Sat, Jan 25, 2014 at 5:10 AM, Heikki Linnakangas
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:
http://www.postgresql.org/mailpref/pgs
On Sat, Jan 25, 2014 at 5:41 AM, Fujii Masao wrote:
> On Thu, Jan 23, 2014 at 4:10 PM, Michael Paquier
> wrote:
>> On Thu, Jan 9, 2014 at 6:36 AM, Gabriele Bartolini
>> 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.
>
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
On Thu, Jan 23, 2014 at 7:45 PM, Tom Lane wrote:
> Andres Freund 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 autovacuum so hard that
>>> it has no cha
On Fri, Jan 24, 2014 at 10:10:00AM -0500, Tom Lane wrote:
> Bruce Momjian 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
Hi Fujita-san,
Thanks for the review.
2014/1/23 Etsuro Fujita :
> 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 UPDATE executed against
On Fri, Jan 24, 2014 at 8:53 PM, Greg Stark wrote:
> On Fri, Jan 24, 2014 at 8:49 PM, Robert Haas wrote:
>> On Fri, Jan 24, 2014 at 6:54 PM, Tom Lane wrote:
>>> Greg Stark writes:
We're finding it more and more common for people to define partitioned
table views with hundreds or thous
On Fri, Jan 24, 2014 at 6:57 AM, Fabrízio de Royes Mello
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 part of the patch if t
On Fri, Jan 24, 2014 at 04:52:55PM -0500, Jaime Casanova wrote:
> On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian 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
On Fri, Jan 24, 2014 at 12:58 PM, Claudio Freire 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 "summary" functions th
On Fri, Jan 24, 2014 at 8:49 PM, Robert Haas wrote:
> On Fri, Jan 24, 2014 at 6:54 PM, Tom Lane wrote:
>> Greg Stark 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 th
On Fri, Jan 24, 2014 at 6:54 PM, Tom Lane wrote:
> Greg Stark 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'v
On Fri, Jan 24, 2014 at 12:49 PM, Andres Freund 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 stuff more manageab
[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 4cba1f6bbf7c8f956c95e72c
Greg Stark 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 pg_dump's ou
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 pg
On Fri, Jan 24, 2014 at 6:54 PM, Tom Lane 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 ruleutils to
> f
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 1
Greg Stark 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 common or
t
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 ind
On Jan24, 2014, at 22:29 , Josh Berkus 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 replication mo
On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian 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 unrelated relations. F
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 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 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 json_to_rec
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 cou
On Thu, Jan 23, 2014 at 4:10 PM, Michael Paquier
wrote:
> On Thu, Jan 9, 2014 at 6:36 AM, Gabriele Bartolini
> 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 is version 4, which removes management of SRF stag
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 Dunstan
On 01/24/2014 01:37 PM, MauMau wrote:
Hi, Heiki-san,
From: "MauMau"
From: "Heikki Linnakangas"
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
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/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
On 01/24/2014 01:58 PM, Alexander Korotkov wrote:
On Thu, Jan 23, 2014 at 8:22 PM, Heikki Linnakangas
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 scanGetItem/keyGetItem looks c
On Fri, Jan 24, 2014 at 2:54 PM, Thom Brown wrote:
> On 24 January 2014 17:53, Alvaro Herrera wrote:
>> Thom Brown wrote:
>>> On 8 November 2013 20:11, Alvaro Herrera wrote:
>>> > Erik Rijkers wrote:
>>> >> On Thu, September 26, 2013 00:34, Erik Rijkers wrote:
>>> >> > On Wed, September 25, 2013
On Fri, Jan 24, 2014 at 2:44 PM, Josh Berkus 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 I/O syst
On 24 January 2014 17:53, Alvaro Herrera wrote:
> Thom Brown wrote:
>> On 8 November 2013 20:11, Alvaro Herrera 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.pa
Thom Brown wrote:
> On 8 November 2013 20:11, Alvaro Herrera 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 w
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 p
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
> > WalSndErrorCleanu
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
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 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 appendre
On Thu, Jan 23, 2014 at 6:32 PM, Andres Freund 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 replication
On 8 November 2013 20:11, Alvaro Herrera 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 ver
On Fri, Jan 24, 2014 at 6:46 AM, Magnus Hagander wrote:
>
> On Thu, Jan 23, 2014 at 2:01 AM, Greg Stark wrote:
>>
>> On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus wrote:
>> > Probably Heroku has some more specific exploit case to be concerned
>> > about here; if so, might I suggest taking it up w
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 resul
Bruce Momjian 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 stated in t
On Thu, Jan 23, 2014 at 2:01 AM, Greg Stark wrote:
> On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus 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 there's a specific vulne
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 earlie
From: "Fujii Masao"
On Fri, Jan 24, 2014 at 9:00 PM, MauMau 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 connection. To
follow that rule, PGco
On Jan24, 2014, at 08:47 , Dean Rasheed 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. Perhaps something lik
From: "Fujii Masao"
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 confirmed that WAL segments
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 p
On Fri, Jan 24, 2014 at 9:00 PM, MauMau wrote:
> From: "Fujii Masao"
>
>> 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
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
From: "Fujii Masao"
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 PQhost(), I think we had b
On Thu, Jan 23, 2014 at 8:22 PM, Heikki Linnakangas 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
> multiple scan
On Fri, Jan 24, 2014 at 6:57 AM, Dimitri Fontaine
wrote:
>
> Sergey Muraviov 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 for
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.
whi
Hi, Heiki-san,
From: "MauMau"
From: "Heikki Linnakangas"
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 want to stop
recovery as early as poss
On Fri, Jan 24, 2014 at 1:19 PM, Heikki Linnakangas 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 | period
On 24 January 2014 09:04, Craig Ringer 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 mutual recursion)
From: "MauMau"
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
Description: Binar
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: "Andrew Dunstan"
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, I added some docu
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 c
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
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,
Sergey Muraviov 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 patch commands rather than
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 dataPlaceToPa
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 me
On 24 January 2014 07:08, Peter Geoghegan wrote:
> On Wed, Jan 15, 2014 at 6:57 AM, Simon Riggs wrote:
>> v15 to fix the above problem.
>
> Minor quibble: I get a compiler warning with the patch applied.
> "relcache.c: In function 'RememberToFreeTupleDescAtEOX':
> relcache.c:2317:3: warning: ISO
On Thu, Jan 23, 2014 at 9:27 AM, Alexander Korotkov wrote:
> 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
>>> the
72 matches
Mail list logo
