On Thu, Jul 4, 2013 at 2:18 AM, Hitoshi Harada wrote:
> For now, that's it. I'm going to dig more later.
>
After looking into rest of the change,
- TYPTYPE_DOMAIN is not supported. Why did you specifically disallow it?
- ParseFuncOrColumn now prohibits to find function returning internal,
but
My main point here is researching how difficult it is to add
functionality in the planner to allow it to to detect and make
decisions on foreign keys present in the outer relation.
I think that if this is added, rest of the work would be much easier.
I amy be completely wrong,though.
Thoughts/Com
On 5 July 2013 19:49, Josh Berkus wrote:
> Robert, Simon, All,
>
> On 04/01/2013 04:51 AM, Robert Haas wrote:> On Thu, Mar 28, 2013 at
> 11:48 AM, Simon Riggs wrote:
>>> a) recovery parameters are made into GUCs (for which we have a patch
>>> from Fujii)
>>> b) all processes automatically read
On Mon, Jul 8, 2013 at 11:33 PM, Andres Freund wrote:
> That's for outer joins tho.
Oh, right - I spoke too soon. Looks like I missed the whole discussion
on inner join removal.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Tue, Jul 9, 2013 at 12:01 PM, Peter Geoghegan wrote:
> On Mon, Jul 8, 2013 at 11:20 PM, Atri Sharma wrote:
>> Where are we with that functionality atm? Do we have plans to move forward?
>
> PostgreSQL has had this capability for some time. See:
>
> http://git.postgresql.org/gitweb/?p=postgresq
On 2013-07-08 23:31:15 -0700, Peter Geoghegan wrote:
> On Mon, Jul 8, 2013 at 11:20 PM, Atri Sharma wrote:
> > Where are we with that functionality atm? Do we have plans to move forward?
> PostgreSQL has had this capability for some time. See:
> http://git.postgresql.org/gitweb/?p=postgresql.git
On Mon, Jul 8, 2013 at 11:20 PM, Atri Sharma wrote:
> Where are we with that functionality atm? Do we have plans to move forward?
PostgreSQL has had this capability for some time. See:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=488d70ab46311386801c10691196ec8d755f2283
--
Pe
Hi all,
I was reading about the plans to add functionality to the planner to
remove redundant inner joins where there is no member of the inner
relation present in the target list and the inner relation is only
used for the join clause. Also, we have a foreign key in the outer
relation to the inne
On Sun, Jul 7, 2013 at 12:06 PM, Peter Eisentraut wrote:
> On Thu, 2013-07-04 at 02:18 -0700, Hitoshi Harada wrote:
>> as someone suggested in the previous thread, it might be a variant of
>> CAST. CREATE CAST (hstore AS plpython2u) ? Or CREATE LANGUAGE TRANSFORM
>> might sound better. In eithe
On Mon, Jul 8, 2013 at 7:25 PM, Craig Ringer wrote:
> On 07/09/2013 08:35 AM, Josh Berkus wrote:
>> Since these are cloud servers, they won't work well for performance
>> testing.
>
> I did some work on that a while ago, and found that I was able to get
> _astonishingly_ stable performance results
On Tue, Jul 9, 2013 at 6:55 AM, Peter Geoghegan wrote:
> When rebasing a patch that I'm working on, I occasionally forget to
> update the oid of any pg_proc.h entries I may have created. Of course
> this isn't a real problem; when I go to initdb, I immediately
> recognize what has happened. All th
On 07/09/2013 11:03 AM, Peter Geoghegan wrote:
> On Mon, Jul 8, 2013 at 7:59 PM, Peter Eisentraut wrote:
>> I don't think rewriting it in Perl is necessary or even desirable. I
>> don't see anything particularly unportable in that script as it is.
>
> I was under the impression that the final pa
On Tuesday, July 09, 2013 2:52 AM Mike Blackwell wrote:
> I can't comment on further direction for the patch, but since it was marked
> as Needs Review in the CF app I took a quick look at it.
Thanks for looking into it.
Last time Heikki has found test scenario's where the original patch wa
On Mon, Jul 8, 2013 at 7:59 PM, Peter Eisentraut wrote:
> I don't think rewriting it in Perl is necessary or even desirable. I
> don't see anything particularly unportable in that script as it is.
I was under the impression that the final patch ought to work on
Windows too. However, I suppose th
On Mon, 2013-07-08 at 19:38 -0700, Peter Geoghegan wrote:
> On Mon, Jul 8, 2013 at 6:33 PM, Tom Lane wrote:
> > This would require a rather higher standard of portability than
> > duplicate_oids has heretofore been held to.
>
> Ah, yes. I suppose that making this happen would necessitate rewritin
On Jul 8, 2013, at 1:31 PM, ivan babrou wrote:
> On 8 July 2013 20:40, David E. Wheeler wrote:
>> On Jul 8, 2013, at 7:44 AM, ivan babrou wrote:
>>
Can you tell me why having ability to specify more accurate connect
timeout is a bad idea?
>>>
>>> Nobody answered my question yet.
>>
On Mon, Jul 8, 2013 at 6:33 PM, Tom Lane wrote:
> This would require a rather higher standard of portability than
> duplicate_oids has heretofore been held to.
Ah, yes. I suppose that making this happen would necessitate rewriting
the script in highly portable Perl. Unfortunately, I'm not a likel
On 07/09/2013 08:35 AM, Josh Berkus wrote:
> Since these are cloud servers, they won't work well for performance
> testing.
I did some work on that a while ago, and found that I was able to get
_astonishingly_ stable performance results out of EC2 EBS instances
using provisioned IOPS volumes. Run
Peter Geoghegan writes:
> ... All the same, it seems like there is a
> case to be made for having this run automatically at build time, and
> having the build fail on the basis of there being a duplicate
This would require a rather higher standard of portability than
duplicate_oids has heretofore
Hey,
New patch attached. I've moved from using a boolean to an enum trivalue.
Let me know what you think.
Cheers,
James
James Sewell
PostgreSQL Team Lead / Solutions Architect
_
[image:
http://www.lisasoft.com/sites/lisasoft/files/u1/2013hieghtslogan_0.png]
When rebasing a patch that I'm working on, I occasionally forget to
update the oid of any pg_proc.h entries I may have created. Of course
this isn't a real problem; when I go to initdb, I immediately
recognize what has happened. All the same, it seems like there is a
case to be made for having this
Reviewer, Testers:
As part of an ongoing effort to encourage patch review for the
PostgreSQL project, we will be funding cloud servers for patch reviewers
and testers who need them for CommitFests. That is, if you want to help
with reviewing or testing a patch for a CommitFest, and don't have you
Alvaro Herrera writes:
> Well, Tom opined in
> http://www.postgresql.org/message-id/23249.1370878...@sss.pgh.pa.us that
> the current patch is okay. I have a mild opinion that it should instead
> print only SHR_LOCK when both bits are set, and one of the others when
> only one of them is set. Bu
On Mon, Jul 8, 2013 at 6:16 PM, Heikki Linnakangas
wrote:
> Ok, I've committed this patch now. Finally, phew!
+1. Great patch!
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/08/2013 02:21 PM, Mike Blackwell wrote:
> I can't comment on further direction for the patch, but since it was marked
> as Needs Review in the CF app I took a quick look at it.
>
> It patches and compiles clean against the current Git HEAD, and 'make
> check' runs successfully.
>
> Does it
I can't comment on further direction for the patch, but since it was marked
as Needs Review in the CF app I took a quick look at it.
It patches and compiles clean against the current Git HEAD, and 'make
check' runs successfully.
Does it need documentation for the GUC variable
'wal_update_compress
From: "Tom Lane"
"MauMau" writes:
If the directory specified by stats_temp_directory becomes inaccessible
to
postgres, enormous amount of WARNING messages are output.
Well, yeah, because all of that functionality just broke. Not warning
about it doesn't seem like a good idea. AFAICT, your
Jeff Janes escribió:
> For 9.3 and 9.4, all the interesting stuff was moved from htup.h to
> htup_details.h (c219d9b0a55bcdf81b00da6b) , but the docs for the
> pageinspect extension were not updated correspondingly.
>
> Attached patch to change the docs.
Applied, thanks.
--
Álvaro Herrera
For 9.3 and 9.4, all the interesting stuff was moved from htup.h to
htup_details.h (c219d9b0a55bcdf81b00da6b) , but the docs for the
pageinspect extension were not updated correspondingly.
Attached patch to change the docs.
Cheers,
Jeff
pageinspect_doc_v1.patch
Description: Binary data
--
Se
On 2013/07/09, at 4:09, Josh Berkus wrote:
> On 07/05/2013 10:09 PM, Michael Paquier wrote:
>> Yeah, it would be good to revive this thread now, which is the
>> beginning of the development cycle. As of now, just to recall
>> everybody, an agreement on this patch still needs to be found... Simon
On Jul 8, 2013, at 1:34 PM, Josh Berkus wrote:
> On 07/03/2013 11:59 AM, Robert Haas wrote:
>> Yeah. I think the system columns that we have today are pretty much
>> crap. I wonder if we couldn't throw them out and replace them with
>> some kind of functions that you can pass a row to. That wou
On Jul 8, 2013, at 4:16 AM, Heikki Linnakangas wrote:
> Ok, I've committed this patch now. Finally, phew!
Woohoo!
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello
updated patch
+ more precious validity check
Regards
Pavel
2013/7/3 Pavel Stehule :
> Hello
>
>
>> So my vote is for make_time(hour int, min int, sec float8).
>>
>
> so here is a patch
>
> Regards
>
> Pavel
>
>
>
>> regards, tom lane
make_date-v2.patch
Descripti
On Mon, Jul 08, 2013 at 03:21:09PM +0900, kenji uno wrote:
> Hi.
>
> Ok, ok thanks.
>
> My problem is to shorten time of searching full text stored in text field.
Ok, your explanation of your problem really helps, thanks.
> However the following query is very slow! 9,400ms. It uses "Seq Scan" l
> 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 about. is that going to get done in the
next
On 07/08/2013 03:40 PM, Josh Berkus wrote:
On 07/04/2013 06:18 AM, Andrew Dunstan wrote:
On 07/04/2013 09:14 AM, Cédric Villemain wrote:
ah yes, good catch, I though .control file were unique per contrib,
but there aren't.
It's already been fixed.
Does it look like this patch will get into
On 07/04/2013 06:18 AM, Andrew Dunstan wrote:
>
> On 07/04/2013 09:14 AM, Cédric Villemain wrote:
>> ah yes, good catch, I though .control file were unique per contrib,
>> but there aren't.
>>
>>
>
> It's already been fixed.
Does it look like this patch will get into committable shape in the nex
On 8 July 2013 20:40, David E. Wheeler wrote:
> On Jul 8, 2013, at 7:44 AM, ivan babrou wrote:
>
>>> Can you tell me why having ability to specify more accurate connect
>>> timeout is a bad idea?
>>
>> Nobody answered my question yet.
>
> From an earlier post by Tom:
>
>> What exactly is the use
Hello Dimitri,
On 07/08/2013 11:49 AM, Dimitri Fontaine wrote:
> Please find attached to this mail version 9 of the Extension Templates
> patch with fixes for the review up to now.
Thanks, cool.
> Markus Wanner writes:
>>> I still think that we shouldn't allow creating a template for an
>>> ext
On 07/03/2013 12:51 AM, Kyotaro HORIGUCHI wrote:
> It is tough to decide how to modify there. Currently I decided to
> preserve vac_estimate_reltuples as possible as it is. For that
> objective, I picked up old_rel_tuples as intermediate variable
> for the aid to 'deceive' the function. This can be
On 06/24/2013 06:55 AM, Tom Lane wrote:
> Andres Freund writes:
>> What about simply not using a keyword at that location at all? Something
>> like the attached hack?
> Generally speaking, I agree with Robert's objection. The patch in
> itself adds only one unnecessary keyword, which probably wou
On 07/05/2013 10:09 PM, Michael Paquier wrote:
> Yeah, it would be good to revive this thread now, which is the
> beginning of the development cycle. As of now, just to recall
> everybody, an agreement on this patch still needs to be found... Simon
> is concerned with backward compatibility. Greg p
On Mon, Jul 8, 2013 at 11:52 AM, Alvaro Herrera
wrote:
> Well, Tom opined in
> http://www.postgresql.org/message-id/23249.1370878...@sss.pgh.pa.us that
> the current patch is okay. I have a mild opinion that it should instead
> print only SHR_LOCK when both bits are set, and one of the others whe
Peter,
On 07/07/2013 12:06 PM, Peter Eisentraut wrote:
> Good point. My original patch allowed func(sql_type) -> internal, but I
> took that out because people had security concerns.
>
> I'd be OK with restricting transform creation to superusers in the first
> cut.
Have we added the ability of
With the current HEAD and v3 patch I'm seeing the following error with
"make check".
--
== creating temporary installation==
== initializing database system ==
pg_regress: initdb failed
Examine /usr/local/src/postgres.patched.v
Peter Geoghegan escribió:
> On Mon, Jul 8, 2013 at 10:28 AM, Jeff Davis wrote:
> > I see this patch is still "waiting on author" in the CF. Is there
> > something else needed from me, or should we move this to "ready for
> > committer"?
>
> Well, obviously someone still needs to think through the
On 06/29/2013 04:11 PM, Greg Smith wrote:
> I need to catch up with revisions done to this feature since I started
> instrumenting my copy more heavily. I hope I can get this ready for
> commit by Monday. I've certainly beaten on the feature for long enough
> now.
Greg, any progress? Haven't se
On 07/08/2013 12:59 AM, Kyotaro HORIGUCHI wrote:
> I'll come again with the first implementation of it. And as for
> pg_freespacemap, I'll keep the current direction - adding column
> to present output records format of pg_freespace(). And
> documentation, if possible.
Do you think you'll be fixin
On 07/03/2013 11:28 AM, Peter Eisentraut wrote:
> On 6/6/13 4:09 PM, Heikki Linnakangas wrote:
> I don't understand what this patch, by itself, will accomplish in terms
> of the originally stated goals of making checkpoint_segments easier to
> tune, and controlling disk space used. To some degree,
On 06/26/2013 07:05 AM, Jamie Martin wrote:
> FYI I submitted a slightly modified patch since Amit's measurements that is
> slightly faster.
Yes. My perspective is that this is a worthwhile optimization for a
minority, but fairly well-known, use case, provided that it doesn't
negatively impact
On 07/03/2013 11:59 AM, Robert Haas wrote:
> Yeah. I think the system columns that we have today are pretty much
> crap. I wonder if we couldn't throw them out and replace them with
> some kind of functions that you can pass a row to. That would allow
> us to expose a lot more detail without add
2013/7/8 Josh Berkus :
> Pavel,
>
>>
>> sure, it should be in September CF. It is relative simple patch
>> without global impacts. But I like it, it increase speed for
>> sum(numeric) about 25% and avg(numeric) about 50%
>
> Do you think you could give this a review after CF1 ends, but before
> Sep
Pavel,
>
> sure, it should be in September CF. It is relative simple patch
> without global impacts. But I like it, it increase speed for
> sum(numeric) about 25% and avg(numeric) about 50%
Do you think you could give this a review after CF1 ends, but before
September? I hate to make Hadi wait
On Mon, Jul 8, 2013 at 10:28 AM, Jeff Davis wrote:
> I see this patch is still "waiting on author" in the CF. Is there
> something else needed from me, or should we move this to "ready for
> committer"?
Well, obviously someone still needs to think through the handling of
the infoMask bits.
Alvar
Hello
2013/7/8 Josh Berkus :
> On 07/07/2013 09:14 PM, Hadi Moshayedi wrote:
>> I am attaching the updated the patch, which also fixes a bug which
>> caused one of the regression tests failed.
>>
>> I'll subscribe this patch to the commitfest in the next hour.
>>
>> Can you please review the patch
On Fri, 2013-07-05 at 22:43 -0700, Jeff Davis wrote:
> On Sat, 2013-07-06 at 10:30 +0900, Satoshi Nagayasu wrote:
> > Hi,
> >
> > It looks fine, but I have one question here.
> >
> > When I run pg_filedump with -k against a database cluster which
> > does not support checksums, pg_filedump produc
On 07/07/2013 09:14 PM, Hadi Moshayedi wrote:
> I am attaching the updated the patch, which also fixes a bug which
> caused one of the regression tests failed.
>
> I'll subscribe this patch to the commitfest in the next hour.
>
> Can you please review the patch?
I'm afraid that, since this patch
Le lundi 8 juillet 2013 18:40:29, David E. Wheeler a écrit :
> On Jul 8, 2013, at 7:44 AM, ivan babrou wrote:
> >> Can you tell me why having ability to specify more accurate connect
> >> timeout is a bad idea?
> >
> > Nobody answered my question yet.
>
> From an earlier post by Tom:
> > What ex
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 skimmed the earlier discussion abou
All,
Normally the CommitFest would be ending in one week. Our current status
for the commitfest is:
Needs Review: 24
Waiting on Author: 17,
Ready for Committer: 13,
Committed: 35,
Returned with Feedback: 18,
Rejected: 2.
At current rates, CF1 will not conclude for four weeks.
Of the patches ne
On Jul 8, 2013, at 7:44 AM, ivan babrou wrote:
>> Can you tell me why having ability to specify more accurate connect
>> timeout is a bad idea?
>
> Nobody answered my question yet.
From an earlier post by Tom:
> What exactly is the use case for that? It seems like extra complication
> for som
On 5 July 2013 23:47, ivan babrou wrote:
> On 5 July 2013 23:26, Tom Lane wrote:
>> ivan babrou writes:
>>> If you can figure out that postgresql is overloaded then you may
>>> decide what to do faster. In our app we have very strict limit for
>>> connect time to mysql, redis and other services,
On 8 July 2013 12:46, Bernd Helmle wrote:
> Recently i got annoyed that psql doesn't tab complete to updatable foreign
> tables.
>
> Attached is a patch to address this. I'm using the new
> pg_relation_is_updatable() function to accomplish this. The function could
> also be used for the trigger ba
Tom Lane wrote:
> Noah Misch writes:
>> On Fri, Feb 08, 2013 at 02:51:40PM +0100, Kohei KaiGai wrote:
>>> I'll have a discussion about new materialized_view object class
>>> on selinux list soon, then I'll submit a patch towards
>>> contrib/sepgsql according to the consensus here.
>
>> Has this p
On Monday, July 08, 2013 5:16 PM Andres Freund wrote:
> On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
> > On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
> > > On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
> > > > +This utility can also be used to decide whether backup is
> > > requir
"MauMau" writes:
> I've found a bug in PostgreSQL 9.3 beta 2 which is related to statistics
> collection which emits excesssive amount of error messages. Please find
> attached the patch to fix this. I confirmed this problem occurs in
> PostgreSQL 9.2, too. Could you backport this?
It's not
On Mon, Jul 8, 2013 at 1:38 PM, Heikki Linnakangas
wrote:
> GetXLogBuffer() doesn't read the content of the page - it writes to it (or
> rather, the caller of GetXLogBarrier() does). The barrier is needed between
> reading xlblocks (to check that the buffer contains the right page), and
> writing
Recently i got annoyed that psql doesn't tab complete to updatable foreign
tables.
Attached is a patch to address this. I'm using the new
pg_relation_is_updatable() function to accomplish this. The function could
also be used for the trigger based stuff in the query, but i haven't
touched thi
On Monday, July 08, 2013 5:16 PM Andres Freund wrote:
>On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
>> On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
>> > On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
>> > > +This utility can also be used to decide whether backup is
>> > required or
On 2013-07-08 17:10:43 +0530, Amit Kapila wrote:
> On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
> > On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
> > > +This utility can also be used to decide whether backup is
> > required or not when the data page
> > > +in old-master precedes t
On Monday, July 08, 2013 4:26 PM Andres Freund wrote:
> On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
> > +This utility can also be used to decide whether backup is
> required or not when the data page
> > +in old-master precedes the last applied LSN in old-standby
> (i.e., new-master) at
Hello,
I've found a bug in PostgreSQL 9.3 beta 2 which is related to statistics
collection which emits excesssive amount of error messages. Please find
attached the patch to fix this. I confirmed this problem occurs in
PostgreSQL 9.2, too. Could you backport this?
[Problem]
If the direct
On 2013-07-08 16:17:54 +0530, Hari Babu wrote:
> +This utility can also be used to decide whether backup is required or
> not when the data page
> +in old-master precedes the last applied LSN in old-standby (i.e.,
> new-master) at the
> +moment of the failover.
> +
> +
I don't t
On Friday, July 05, 2013 6:48 PM Hari Babu wrote:
>On Thursday, July 04, 2013 11:19 PM Robert Haas wrote:
The patch is updated with the following changes.
1.If the input data is data directory, all the errors occurred are displayed
at once instead of one error at a time.
2.Fixed the problem of r
On 2013-07-08 10:45:41 +0300, Heikki Linnakangas wrote:
> On 01.07.2013 16:40, Andres Freund wrote:
> >On 2013-06-26 18:52:30 +0300, Heikki Linnakangas wrote:
> >>>* Could you document the way slots prevent checkpoints from occurring
> >>> when XLogInsert rechecks for full page writes? I think it
On 08.07.2013 13:21, Ants Aasma wrote:
On Mon, Jul 8, 2013 at 12:16 PM, Heikki Linnakangas
wrote:
Ok, I've committed this patch now. Finally, phew!
Fantastic work!
I simplified the handling of xlogInsertingAt per discussion, and added the
memory barrier to GetXLogBuffer(). I ran again the
On Wednesday, July 03, 2013 1:21 PM Kyotaro HORIGUCHI wrote:
> Hello,
>
> > I could see the same output with your latest script, also I could
> reproduce
> > the test if I run the test with individual sql statements.
> > One of the main point for reproducing individual test was to keep
> autovacuu
On Mon, Jul 8, 2013 at 12:16 PM, Heikki Linnakangas
wrote:
> Ok, I've committed this patch now. Finally, phew!
Fantastic work!
> I simplified the handling of xlogInsertingAt per discussion, and added the
> memory barrier to GetXLogBuffer(). I ran again the pgbench tests I did
> earlier with the
what is log switch and when it occur ?
Hi,
Please find attached to this mail version 9 of the Extension Templates
patch with fixes for the review up to now.
Markus Wanner writes:
>> I still think that we shouldn't allow creating a template for an
>> extension that is already installed, though. Do you have any suggestions
>> for a bet
On 07/08/2013 10:20 AM, Dimitri Fontaine wrote:
> Bypassing the file system entirely in order to install an extension. As
> soon as I figure out how to, including C-coded extensions.
Do I understand correctly that you want to keep the extensions (or their
templates) out of the dump and require the
On 27.06.2013 20:36, Andres Freund wrote:
On 2013-06-26 18:52:30 +0300, Heikki Linnakangas wrote:
There's this in the comment near the top of the file:
Btw, I find the 'you' used in the comment somewhat irritating. Not badly
so, but reading something like:
* When you are about to write
*
On 08.07.2013 12:16, Heikki Linnakangas wrote:
I just remembered one detail that I'm not sure has been mentioned on the
mailing list yet. Per the commit message:
This has one user-visible change: switching to a new WAL segment with
pg_switch_xlog() now fills the remaining unused portion of the
Ok, I've committed this patch now. Finally, phew!
I think I've addressed all your comments about the comments. I moved
some of the comments around: I split up the large one near the top of
the file, moving its paragraphs closer to the code where they apply.
Regarding your performance-related
2013/7/8 Hadi Moshayedi :
> I am attaching the updated the patch, which also fixes a bug which
> caused one of the regression tests failed.
>
> I'll subscribe this patch to the commitfest in the next hour.
>
> Can you please review the patch?
sure, :)
Pavel
>
> Thanks,
>-- Hadi
--
Sent vi
Jaime Casanova writes:
> the name). I'm talking about get_ext_ver_list_from_catalog() which is
> a different
> function.
Oh. I see it now. Sorry about that. It's blindly fixed in my git repo
and I'm going to send an updated patch soon now™ which will include the
fix.
Thanks for insisting here…
On 06/10/2013 09:43 PM, Hannu Krosing wrote:
> On 07/08/2013 09:26 AM, Heikki Linnakangas wrote:
>> The concept was useful, but not something we want
>> to call an extension, because the distinguishing feature of an
>> extension is that it lives outside the database and is *not* included
>> in pg_d
I create fsync v2 patch. There's not much time, so I try to focus fsync patch in
this commit festa as adviced by Heikki. And I'm sorry that it is not good that
diverging from main discussion in this commit festa... Of course, I continue to
try another improvement.
* Changes
- Add ckpt_flag in
Peter Eisentraut writes:
> local_preload_libraries allows unprivileged users to preload whitelisted
> libraries. session_preload_libraries allows superusers to preload any
> library. It's hard to see how to consolidate those, at least without
> adding another setting that whitelists the librarie
> On 07/08/2013 09:26 AM, Heikki Linnakangas wrote:
>> I'm just now dabbling back to this thread after skipping a lot of
>> discussion, and I'm disappointed to see that this still seems to be
>> running in circles on the same basic question: What exactly is the
>> patch trying to accomplish.
Bypas
Hello,
> > - How about pageinspect?
> >
> > I proposed a simple representation format as a basis for
> > discussion. Nevertheless, the VM pages has no more structure
> > than a simple bit string. Given the VM info in pg_freespacemap,
> > I've come in doubt of the necessity of vm_page_cont
On 01.07.2013 16:40, Andres Freund wrote:
On 2013-06-26 18:52:30 +0300, Heikki Linnakangas wrote:
* Could you document the way slots prevent checkpoints from occurring
when XLogInsert rechecks for full page writes? I think it's correct -
but not very obvious on a glance.
There's this in
On 07/08/2013 09:26 AM, Heikki Linnakangas wrote:
> On 08.07.2013 00:48, Markus Wanner wrote:
>> On 07/07/2013 09:51 PM, Dimitri Fontaine wrote:
>>> The design we found to address that is
>>> called "Extension Templates" and is implemented in the current patch.
>>
>> I placed my concerns with the p
On 08.07.2013 00:48, Markus Wanner wrote:
On 07/07/2013 09:51 PM, Dimitri Fontaine wrote:
The design we found to address that is
called "Extension Templates" and is implemented in the current patch.
I placed my concerns with the proposed implementation. It's certainly
not the only way how Post
94 matches
Mail list logo
