On Tue, Sep 17, 2013 at 12:59 PM, Robert Haas wrote:
> Personally, I'm not particularly in favor of these kinds of changes.
+1. Experience has shown this kind of effort to be a tarpit. It turns
out that refactoring away compiler dependencies has this kind of
fractal complexity - the more you look
On Tue, Sep 17, 2013 at 05:54:04PM -0300, Alvaro Herrera wrote:
> > I don't want to be too dogmatic in opposing this; I accept that we
> > should, from time to time, refactor things. If we don't, superflouous
> > dependencies will probably proliferate over time. But personally, I'd
> > rather do
On Mon, Sep 30, 2013 at 1:49 PM, Huchev wrote:
> How come any compressor which could put some competition to pglz is
> systematically pushed out of the field on the ground of unverifiable "legal
> risks" ?
Because pglz has been around for a while and has not caused patent
trouble. The risks have
On Sun, 2013-09-15 at 18:27 +0200, Marko Tiikkaja wrote:
> I think the reasoning behind this patch is sound. However, I would like
> to raise a couple of small questions:
>
>1) Is there a reason for the fmt string not being const char*? You
> changed it for pg_log_v(), but not for pg_log()
On Wed, 2013-09-18 at 20:13 +0530, Amit Khandekar wrote:
> What's the reason behind calling pg_has_role(proowner, 'USAGE') before
> calling pg_get_function_arg_default() ? :
>
> CASE WHEN pg_has_role(proowner, 'USAGE')
> THEN pg_get_function_arg_default(p_oid, (ss.x).n)
> ELSE NULL E
On Wed, 2013-09-25 at 14:26 +0530, Jeevan Chalke wrote:
> So no issues from my side.
>
> However, do we still need this in close_pl() ?
>
> #ifdef NOT_USED
> if (FPeq(line->A, -1.0) && FPzero(line->B))
> {/* vertical */
> }
> #endif
No, that can be removed
On Fri, 2013-09-13 at 22:40 +0200, Dimitri Fontaine wrote:
> Please find attached to this email three patches covering the missing PL
> support for Event Triggers: pltcl, plperl and plpython.
For plperl, the previous reviews mostly apply analogously. In addition,
I have these specific points:
-
On Sun, Sep 29, 2013 at 10:58 PM, Daniel Farina wrote:
> I remember hacking that out for testing sake.
>
> I can only justify it as a foot-gun to prevent someone from being
> stuck restarting the database to get a reasonable number in there.
> Let's CC Peter; maybe he can remember some thoughts ab
On Fri, Sep 27, 2013 at 10:42:17AM +, Haribabu kommi wrote:
> If the changes are very high to deal all scenarios,
>
> I feel it is better do it only in scenarios where the use cases needs it,
> until
> it is not confusing users.
>
> The rest can be documented.
>
> Any other opinions/suggest
On Oct 1, 2013, at 3:56 PM, Merlin Moncure wrote:
> I don't think it has anything to do with the conditional index -- it's
> the functional based. For some reason postgres always wants to post
> filter (note the filter step below):
>
> postgres=# create index on try(upper_inf(irange));
> CREATE
On Tue, Oct 1, 2013 at 5:35 PM, David E. Wheeler wrote:
> Hackers,
>
> I was trying to figure out why a query was not doing an index-only scan on a
> partial index, when Josh Berkus pointed to this issue, reported by Merlin
> Moncure:
>
>
> http://www.postgresql.org/message-id/CAHyXU0x1OGao48
Hackers,
I was trying to figure out why a query was not doing an index-only scan on a
partial index, when Josh Berkus pointed to this issue, reported by Merlin
Moncure:
http://www.postgresql.org/message-id/CAHyXU0x1OGao48WajAfUsbXqkUDLf=_6ho6hlmb8dsfkwda...@mail.gmail.com
In short, the plan
Add file cloning as an alternative data transfer method to pg_upgrade.
Currently only btrfs is supported, but copy-on-write cloning is also
available on at least ZFS. Cloning must be requested explicitly and if
it isn't supported by the operating system or filesystem a fatal error
is thrown.
This
Magnus Hagander wrote:
> On Thu, Aug 22, 2013 at 8:13 AM, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On Fri, 2013-07-12 at 12:30 +0200, Magnus Hagander wrote:
> >>> Given that, I'm fine with just bumping the version on borka to that
> >>> version. Any objections?
> >
> >> This was not done
MauMau escribió:
> "AbortStartTime > 0" is also necessary to avoid sending SIGKILL
> repeatedly. I sent the attached patch during the original
> discussion. The below fragment is relevant:
Can you please send a fixup patch to what's already committed?
--
Álvaro Herrerahttp://ww
On Tue, Oct 1, 2013 at 5:32 AM, Sameer Thakur wrote:
> On Tue, Oct 1, 2013 at 12:48 AM, Daniel Farina-5 [via PostgreSQL]
> <[hidden email]> wrote:
>
>>
>> On Sep 30, 2013 4:39 AM, "Sameer Thakur" <[hidden email]> wrote:
>>>
>>> > Also, for onlookers, I have changed this patch around to do the
>>>
Cédric Villemain wrote:
> Andres, I was answering your question.
> Short and re-phrased:
> * we should not abuse make USE_PGXS to test the contrib build
> * I believe your patch is correct to issue an error when trying to build
> pg_xlogdump with PGXS, it is not possible, dot.
There being no d
Michael Paquier escribió:
> Btw, taking the problem from another viewpoint... This feature has now
> 3 patches, the 2 first patches doing only code refactoring. Could it
> be possible to have a look at those ones first? Straight-forward
> things should go first, simplifying the core feature evalua
On 2013-10-01 10:27:14 -0400, Robert Haas wrote:
> On Tue, Oct 1, 2013 at 10:19 AM, Magnus Hagander wrote:
> >> If we can't feel comfortable with an ERROR, let's not do it at all.
> >
> > In principle, I agree.
> >
> > However, if we want to do this as a temporary measure to judge impact,
> > we c
On 09/30/2013 06:44 PM, Andres Freund wrote:
Hi,
The series from friday was a bit too buggy - obviously I was too
tired. So here's a new one:
With this series I've also noticed
#2 0x007741a7 in ExceptionalCondition (
conditionName=conditionName@entry=0x7c2908 "!(!(tuple->t_infomas
> "Heikki" == Heikki Linnakangas writes:
Heikki> I've spent some time reviewing this patch - looks pretty
Heikki> good! I'm not through yet, but I wanted to post an
Heikki> update. Attached is a new version, with some modifications I
Heikki> made. Notably:
Heikki> I refactored the gramm
ck to
it later to finish the review and commit (unless someone beats me to
it). Meanwhile, if you could do something about that comment and manual
paragraph above, and re-review the changes I made, that would be great.
- Heikki
tablefunc-20131001-heikki-1.patch.gz
Description: GNU Zip comp
On 2013-10-01 10:07:19 -0400, Robert Haas wrote:
> - It seems that HeapSatisfiesHOTandKeyUpdate is now
> HeapSatisfiesHOTandKeyandCandidateKeyUpdate. Considering I think this
> was merely HeapSatisfiesHOTUpdate a year ago, it's hard not to be
> afraid that something unscalable is happening to this
On Tue, Oct 1, 2013 at 05:17:35PM +0200, Andres Freund wrote:
> On 2013-10-01 11:15:36 -0400, Bruce Momjian wrote:
> > I see a few cases of this code in src/backend/utils/adt/datetime.c:
> >
> > else if ((fmask & DTK_DATE_M) != DTK_DATE_M)
> >
> > Wouldn't this be clearer as:
> >
> > el
Amit Kapila escribió:
> While reading documentation for SET command, I observed that FROM
> CURRENT syntax and its description is missing from SET command's
> syntax page (http://www.postgresql.org/docs/devel/static/sql-set.html).
>
> Do you think that documentation should be updated for the same
On 2013-10-01 11:15:36 -0400, Bruce Momjian wrote:
> I see a few cases of this code in src/backend/utils/adt/datetime.c:
>
> else if ((fmask & DTK_DATE_M) != DTK_DATE_M)
>
> Wouldn't this be clearer as:
>
> else if (fmask & DTK_DATE_M)
That doesn't have the same meaning. The latter is t
I see a few cases of this code in src/backend/utils/adt/datetime.c:
else if ((fmask & DTK_DATE_M) != DTK_DATE_M)
Wouldn't this be clearer as:
else if (fmask & DTK_DATE_M)
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
On Tue, Oct 1, 2013 at 10:31 AM, Andres Freund wrote:
>> I have no problem with caching the primary key in the relcache, or
>> with using that as the default key for logical decoding, but I'm
>> extremely uncomfortable with the fallback strategy when no primary key
>> exists. Choosing any old uni
David Johnston wrote
> A paragraph cross-referencing where SET sub-commands exist has merit but
> since the main SET command does not accept FROM CURRENT it (FC) should not
> be included in its page directly.
It is strange that this actually does work - at least in 9.0 - given that
SET ... FROM CU
On 2013-10-01 07:41:46 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > A better solution probably is to promote tuple-level locks if
> > they exist to a relation level one upon freezing I guess?
>
> It would be sufficient to promote the tuple lock to a page lock.
> It would be pretty e
Andres Freund wrote:
> A better solution probably is to promote tuple-level locks if
> they exist to a relation level one upon freezing I guess?
It would be sufficient to promote the tuple lock to a page lock.
It would be pretty easy to add a function to predicate.c which
would accept a Relation
Hi,
On 2013-10-01 10:07:19 -0400, Robert Haas wrote:
> - AssignTransactionId changes "Mustn't" to "May not", which seems like
> an entirely pointless change.
It was "Musn't" before ;). I am not sure why I changed it to "May not"
instead of "Mustn't".
> - Do none of the callers of IsSystemRelatio
On Tue, Oct 1, 2013 at 10:19 AM, Magnus Hagander wrote:
>> If we can't feel comfortable with an ERROR, let's not do it at all.
>
> In principle, I agree.
>
> However, if we want to do this as a temporary measure to judge impact,
> we could do WARNING now and flip it to ERROR in the next minor
> re
On Tue, Oct 1, 2013 at 4:17 PM, Robert Haas wrote:
> On Tue, Oct 1, 2013 at 9:16 AM, Alvaro Herrera
> wrote:
>> Since back branches releases are getting closer, I would like to push
>> this to all supported branches. To avoid a compatibility nightmare in
>> case the new die-on-delayed-renegotia
On Tue, Oct 1, 2013 at 9:16 AM, Alvaro Herrera wrote:
> Since back branches releases are getting closer, I would like to push
> this to all supported branches. To avoid a compatibility nightmare in
> case the new die-on-delayed-renegotiation behavior turns out not to be
> so great, I think it wou
On Tue, Oct 1, 2013 at 6:27 PM, David Johnston wrote:
> Amit Kapila-2 wrote
>> On Tue, Oct 1, 2013 at 10:25 AM, David Johnston <
>
>> polobo@
>
>> > wrote:
>>> Amit Kapila-2 wrote
While reading documentation for SET command, I observed that FROM
CURRENT syntax and its description is miss
On Tue, Oct 1, 2013 at 7:26 AM, Andres Freund wrote:
> On 2013-10-01 06:20:20 -0400, Robert Haas wrote:
>> On Mon, Sep 30, 2013 at 5:34 PM, Andres Freund
>> wrote:
>> >> What's wrong with #1?
>> >
>> > It seems confusing that a changeset stream in database #1 will contain
>> > commits (without c
Review comments on 0004:
- In heap_insert and heap_multi_insert, please rewrite the following
comment for clarity: "add record for the buffer without actual content
thats removed if fpw is done for that buffer".
- In heap_delete, the assignment to need_tuple_data() need not
separately check Relati
Hello Noah,
Thread create time seems to be expensive as well, maybe up 0.1
seconds under some conditions (?). Under --rate, this create delay
means that throttling is laging behind schedule by about that time,
so all the first transactions are trying to catch up.
threadRun() already initializ
Hi,
isolation_main.c executes isolationtester with:
snprintf(psql_cmd + offset, sizeof(psql_cmd) - offset,
SYSTEMQUOTE "\"./isolationtester\" \"dbname=%s\" < \"%s\" > \"%s\"
That obviously fails if pg_isolation_tester is invoked when CWD is not
its build directory. That's rather annoyin
Since back branches releases are getting closer, I would like to push
this to all supported branches. To avoid a compatibility nightmare in
case the new die-on-delayed-renegotiation behavior turns out not to be
so great, I think it would be OK to set the error level to WARNING in
all branches but
Amit Kapila-2 wrote
> On Tue, Oct 1, 2013 at 10:25 AM, David Johnston <
> polobo@
> > wrote:
>> Amit Kapila-2 wrote
>>> While reading documentation for SET command, I observed that FROM
>>> CURRENT syntax and its description is missing from SET command's
>>> syntax page (http://www.postgresql.org
[oops, resent because stalled, wrong From!]
Hello Noah,
Thread create time seems to be expensive as well, maybe up 0.1
seconds under some conditions (?). Under --rate, this create delay
means that throttling is laging behind schedule by about that time,
so all the first transactions are trying
On Tue, Oct 1, 2013 at 12:48 AM, Daniel Farina-5 [via PostgreSQL]
wrote:
>
> On Sep 30, 2013 4:39 AM, "Sameer Thakur" <[hidden email]> wrote:
>>
>> > Also, for onlookers, I have changed this patch around to do the
>> > date-oriented stuff but want to look it over before stapling it up and
>> > sen
On Tue, Oct 1, 2013 at 2:08 PM, Andres Freund wrote:
>> As for the specific patch being discussed here. The read barrier is in
>> the wrong place and with the wrong comment, and the write side is
>> assuming that SpinLockAcquire() is a write barrier, which it isn't
>> documented to do at the momen
On 2013-10-01 14:31:11 +0300, Ants Aasma wrote:
> >> The correct way to think of this is
> >> that StartupXLOG() does a bunch of state modifications and then
> >> advertises the fact that it's done by setting
> >> xlogctl->SharedRecoveryInProgress = false; The state modifications
> >> should better
On Tue, Oct 1, 2013 at 2:13 PM, Andres Freund wrote:
> Agreed. The "wait free LW_SHARED" thing[1] I posted recently had a simple
>
> #define pg_atomic_read(atomic) (*(volatile uint32 *)&(atomic))
>
> That should be sufficient and easily greppable, right?
Looks good enough for me. I would consider
On 2013-10-01 06:20:20 -0400, Robert Haas wrote:
> On Mon, Sep 30, 2013 at 5:34 PM, Andres Freund wrote:
> >> What's wrong with #1?
> >
> > It seems confusing that a changeset stream in database #1 will contain
> > commits (without corresponding changes) from database #2. Seems like aaa
> > pola v
On 2013-10-01 04:47:42 +0300, Ants Aasma wrote:
> I still think we should have a macro for the volatile memory accesses.
> As a rule, each one of those needs a memory barrier, and if we
> consolidate them, or optimize them out, the considerations why this is
> safe should be explained in a comment.
On 2013-10-01 03:51:50 +0300, Ants Aasma wrote:
> On Sat, Sep 28, 2013 at 12:53 AM, Andres Freund
> wrote:
> > What confuses me is that pg_read_barrier() is just a compiler barrier on
> > x86[-64] in barrier.h. According to my knowledge it needs to be an
> > lfence or the full barrier?
> > The li
On Mon, Sep 30, 2013 at 5:34 PM, Andres Freund wrote:
>> What's wrong with #1?
>
> It seems confusing that a changeset stream in database #1 will contain
> commits (without corresponding changes) from database #2. Seems like aaa
> pola violation to me.
I don't really see the problem. A transacti
On Mon, Sep 30, 2013 at 1:20 PM, Heikki Linnakangas
wrote:
> You can almost create a bounding box opclass in the current implementation,
> by mapping < operator to "contains" and > to "not contains". But there's no
> support for creating a new, larger, bounding box on insert. It will just
> replac
On Tue, Oct 1, 2013 at 10:25 AM, David Johnston wrote:
> Amit Kapila-2 wrote
>> While reading documentation for SET command, I observed that FROM
>> CURRENT syntax and its description is missing from SET command's
>> syntax page (http://www.postgresql.org/docs/devel/static/sql-set.html).
>>
>> Do
On 25 September 2013 12:49, Amit Khandekar
wrote:
>
> 0003-Convert-object-names-to-**archive-encoding-before-matc.**patch
>>
>> Use iconv(3) in pg_restore to do encoding conversion in the client. This
>> involves a lot of autoconf changes that I'm not 100% sure about, other than
>> that it's prett
On Tue, Oct 1, 2013 at 12:48 AM, Daniel Farina-5 [via PostgreSQL]
wrote:
>
> On Sep 30, 2013 4:39 AM, "Sameer Thakur" <[hidden email]> wrote:
>>
>> > Also, for onlookers, I have changed this patch around to do the
>> > date-oriented stuff but want to look it over before stapling it up and
>> > sen
Hello
When I did a review of \pset improvements, I found so not all possible
options are supported by autocomplete. Here is fix
Regards
Pavel Stehule
pset-autocomplete-fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Hello all
I am thinking so almost all is done
I fixed a help and appended a simple test
But it is a cosmetic changes.
Comments?
Regards
Pavel Stehule
2013/9/30 Gilles Darold
> Le 30/09/2013 17:35, Peter Eisentraut a écrit :
> > Please remove the tabs from the SGML files.
>
> Done. I've a
On Thu, Sep 26, 2013 at 6:00 PM, Samrat Revagade
wrote:
> Hi,
>
> How about providing more granularity to replication, by setting separate
> values of replication parameters to each standby
> for example:
> standby1.wal_sender_timeout= 50s
> standby2.wal_sender_timeout= 40s
>
> The idea is to allo
58 matches
Mail list logo
