I've noticed a filename error in feedback messages from psql's '\s' command
when saving the command line history to a file specified by an absolute
filepath:
psql (9.2.2)
Type "help" for help.
pgdevel=# \s history.txt
Wrote history to file "./history.txt".
pgdevel=# \s /tmp/history.txt
On 21.01.2013 02:07, Jeff Janes wrote:
As a junior reviewer, I'd like to know if my main task should be to decide
between 1) writing a review convincing you or Tom that your judgement is
hasty, or 2) to convince the author that your judgement is correct. That
would provide me with some direction
On 2013-01-19 17:33:05 -0500, Steve Singer wrote:
> On 13-01-09 03:07 PM, Tom Lane wrote:
> >Andres Freund writes:
> >>Well, I *did* benchmark it as noted elsewhere in the thread, but thats
> >>obviously just machine (E5520 x 2) with one rather restricted workload
> >>(pgbench -S -jc 40 -T60). At
On 2013-01-20 21:45:11 -0500, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 12:32 PM, Andres Freund
> wrote:
> > Makes sense?
>
> Yes. The catalog timetravel stuff still gives me heartburn. The idea
> of treating system catalogs in a special way has never sat well with
> me and still doesn't -
On Mon, Jan 21, 2013 at 12:22 PM, Jeff Davis wrote:
>
> On Mon, 2013-01-21 at 11:27 +0530, Pavan Deolasee wrote:
> > Of course, there is an argument that this patch will
> > simplify the code, but I'm not sure if its enough to justify the
> > additional contention which may or may not show up in
On Jan 21, 2013 3:06 AM, "Craig Ringer" wrote:
>
> On 01/21/2013 10:03 AM, Craig Ringer wrote:
> > On 01/19/2013 04:08 AM, Boszormenyi Zoltan wrote:
> >> However, I am not sure whether Cygwin provides the mkstemp() call or
not.
> >> Searching... Found bugzilla reports against mkstemp on Cygwin.
>
Hello!
I wrote to general ( [GENERAL] standby, pg_basebackup and last xlog file )
some times ago. but still hasn't got any feedback.
Hello!
Is there any reason why pg_basebackup has limitation in an online backup from
the standby: "The backup history file is not created in the datab
On Mon, 2013-01-21 at 00:48 -0500, Tom Lane wrote:
> I looked at this patch. ISTM we should not have the option at all but
> just do it always. I cannot believe that always-go-left is ever a
> preferable strategy in the long run; the resulting imbalance in the
> index will surely kill any possibl
On Mon, 2013-01-21 at 11:27 +0530, Pavan Deolasee wrote:
> I tend to agree. When I looked at the patch, I thought since its
> removing a WAL record (and associated redo logic), it has some
> additional value. But that was kind of broken (sorry, I haven't looked
> at the latest patch if Jeff fixed i
On Mon, Jan 21, 2013 at 12:11 PM, Devrim GÜNDÜZ wrote:
>
> Hi,
>
> On Mon, 2013-01-21 at 11:33 +0530, Vivek Singh Raghuwanshi wrote:
>
> > But i am trying to achieve this via multiple if conditions , can you
> > send me your redhat and suse spec files.
>
> As I have emailed you before, spec files
Hi,
On Mon, 2013-01-21 at 11:33 +0530, Vivek Singh Raghuwanshi wrote:
> But i am trying to achieve this via multiple if conditions , can you
> send me your redhat and suse spec files.
As I have emailed you before, spec files,etc. are at
http://svn.pgrpms.org/repo
Regards,
--
Devrim GÜNDÜZ
Pr
On Sun, 2013-01-20 at 22:19 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Jan 18, 2013 at 3:31 AM, Jeff Davis wrote:
> >> So, I attached a new version of the patch that doesn't look at the VM
> >> for tables with fewer than 32 pages. That's the only change.
>
> > That certainly seems
Thanks Devrim,
But i am trying to achieve this via multiple if conditions , can you send
me your redhat and suse spec files.
On Mon, Jan 21, 2013 at 11:09 AM, Devrim GÜNDÜZ wrote:
>
> Hi,
>
> On Mon, 2013-01-21 at 10:53 +0530, Vivek Singh Raghuwanshi wrote:
> > I am trying to build rpm of Postg
On Sun, Jan 20, 2013 at 4:29 AM, Tom Lane wrote:
> Pavan Deolasee writes:
>> Sorry for posting on such an old thread. But here is a patch that
>> fixes this. I'm also adding to the next commitfest so that we don't
>> lose track of it again.
>
> As submitted, this broke pg_dump for dumping from pr
On Mon, Jan 21, 2013 at 8:49 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 18, 2013 at 3:31 AM, Jeff Davis wrote:
>>> So, I attached a new version of the patch that doesn't look at the VM
>>> for tables with fewer than 32 pages. That's the only change.
>
>> That certainly seems worthw
On Sunday, January 20, 2013, Stephen Frost wrote:
> * Jeff Janes (jeff.ja...@gmail.com ) wrote:
>
> > By making the list over-flowable, we fix a demonstrated pathological
> > workload (restore of huge schemas); we impose no detectable penalty to
> > normal workloads; and we fail to improve, but
Jeff Davis writes:
> On Fri, 2012-12-14 at 18:36 +0200, Heikki Linnakangas wrote:
>> BTW, I don't much like the option name "randomization". It's not clear
>> what's been randomized. I'd prefer something like
>> "distribute_on_equal_penalty", although that's really long. Better ideas?
> I agree
Hi,
On Mon, 2013-01-21 at 10:53 +0530, Vivek Singh Raghuwanshi wrote:
> I am trying to build rpm of PostgreSQL, and the approach is building
> rpm for
> 1. CentOS 6+
> 2. Fedora 15+
> 3. RedHat 6+
> 4. OpenSUSE
> 5. SuSE
>
> via single spec file and not using any external rpm or repo while
> bui
Vivek Singh Raghuwanshi writes:
> 3.RedHat_RHEL-6
> uuid-devel (Now RedHat is not providing this rpm)
works for me in RHEL-6 ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
On 1/20/2013 9:23 PM, Vivek Singh Raghuwanshi wrote:
3.RedHat_RHEL-6
uuid-devel (Now RedHat is not providing this rpm)
you sure about that? now, I'm running CentOS 6 not RHEL6, but the
packages are 1:1 and built from the same SRPMs.
uuid-devel.i686
1.6.1-10.el6
Hi All,
I am trying to build rpm of PostgreSQL, and the approach is building rpm for
1. CentOS 6+
2. Fedora 15+
3. RedHat 6+
4. OpenSUSE
5. SuSE
via single spec file and not using any external rpm or repo while building
the problem i am facing right now is there is some dependencies which is
now
2013/1/21 Robert Haas :
> On Sun, Jan 20, 2013 at 10:01 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane wrote:
Pavel is claiming it's okay for that to fall over if the array has
more than 100 elements. I disagree, not only for the specific case
Stephen Frost writes:
> Strictly speaking, it's this:
> tborder[i] = '\0';
> Which ends up writing past the end of the buffer (which is allocated as
> 'width + 1'). Perhaps we should also change that to be:
> tborder[width] = '\0';
Yeah, I like that better too. Will commit.
On 01/21/2013 11:26 AM, Robert Haas wrote:
> On Sun, Jan 20, 2013 at 2:59 PM, Phil Sorber wrote:
>> Ok. I can add something to the notes section of the docs. I can also
>> add some code comments for this and for grabbing the default params.
> Sounds good.
>
>>> Oh, I see. Is it really important t
Xi Wang writes:
> The correct NULL check should use `*newval'; `newval' must be non-null.
Great catch, will commit. (But first I'm looking through commit
2594cf0e to see if I made the same mistake anywhere else :-(.)
How did you find that, coverity or some such tool?
re
Stephen Frost writes:
> * Xi Wang (xi.w...@gmail.com) wrote:
>> The correct NULL check should use `*newval'; `newval' must be non-null.
> Why isn't this using pstrdup()..?
The GUC API uses malloc, mainly because guc.c can't afford to lose
control on out-of-memory situations.
On 01/19/2013 11:47 AM, Tomonari Katsumata wrote:
>
> Hi,
>
> I made a patch to divide privileges for replication role.
>
I've added your patch to the commitfest tracking app for the post-9.3
release; see https://commitfest.postgresql.org/action/patch_view?id=1072 .
If it's convenient for you to
On Sun, Jan 20, 2013 at 2:59 PM, Phil Sorber wrote:
> Ok. I can add something to the notes section of the docs. I can also
> add some code comments for this and for grabbing the default params.
Sounds good.
>> Oh, I see. Is it really important to have the host and port in the
>> output, or shou
On Sun, Jan 20, 2013 at 10:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane wrote:
>>> Pavel is claiming it's okay for that to fall over if the array has
>>> more than 100 elements. I disagree, not only for the specific case of
>>> CONCAT(), but with the
Robert Haas writes:
> On Fri, Jan 18, 2013 at 3:31 AM, Jeff Davis wrote:
>> So, I attached a new version of the patch that doesn't look at the VM
>> for tables with fewer than 32 pages. That's the only change.
> That certainly seems worthwhile, but I still don't want to get rid of
> this code.
On Monday, January 21, 2013 7:36 AM Craig Ringer wrote:
> On 01/21/2013 10:03 AM, Craig Ringer wrote:
> > On 01/19/2013 04:08 AM, Boszormenyi Zoltan wrote:
> >> However, I am not sure whether Cygwin provides the mkstemp() call or
> not.
> >> Searching... Found bugzilla reports against mkstemp on Cy
Robert Haas writes:
> On Sun, Jan 20, 2013 at 7:07 PM, Jeff Janes wrote:
>> As a junior reviewer, I'd like to know if my main task should be to decide
>> between 1) writing a review convincing you or Tom that your judgement is
>> hasty, or 2) to convince the author that your judgement is correct.
On Sun, Jan 20, 2013 at 10:04 PM, Andrew Dunstan wrote:
>
> On 01/20/2013 09:37 PM, Robert Haas wrote:
>>
>> On Sun, Jan 20, 2013 at 7:07 PM, Jeff Janes wrote:
>>>
>>> As a junior reviewer, I'd like to know if my main task should be to
>>> decide
>>> between 1) writing a review convincing you or
On 01/20/2013 09:37 PM, Robert Haas wrote:
On Sun, Jan 20, 2013 at 7:07 PM, Jeff Janes wrote:
As a junior reviewer, I'd like to know if my main task should be to decide
between 1) writing a review convincing you or Tom that your judgement is
hasty, or 2) to convince the author that your judgem
Robert Haas writes:
> On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane wrote:
>> Pavel is claiming it's okay for that to fall over if the array has
>> more than 100 elements. I disagree, not only for the specific case of
>> CONCAT(), but with the more general implication that such a limitation
>> is go
On 01/21/2013 02:11 AM, Dickson S. Guedes wrote:
> 2013/1/17 Daniel Farina :
>> I realized while making my adjustments that I pointlessly grew some input
>> checking in the inner loop. I just hoisted it out in this version.
> Since psql uses libreadline, what do you think about to call
> rl_clear_
On Fri, Jan 18, 2013 at 12:32 PM, Andres Freund wrote:
> Makes sense?
Yes. The catalog timetravel stuff still gives me heartburn. The idea
of treating system catalogs in a special way has never sat well with
me and still doesn't - not that I am sure what I'd like better. The
complexity of the
On Sun, Jan 20, 2013 at 7:07 PM, Jeff Janes wrote:
> As a junior reviewer, I'd like to know if my main task should be to decide
> between 1) writing a review convincing you or Tom that your judgement is
> hasty, or 2) to convince the author that your judgement is correct.
That's a hard question.
On Sat, Jan 19, 2013 at 12:47 PM, Tomonari Katsumata <
t.katsumata1...@gmail.com> wrote:
> a) adding new privileges for replication:"MASTER REPLICATION" and "CASCADE
> REPLICATION"
>
>"MASTER REPLICATION": Replication-connection to master server is only
> allowed
>"CASCADE REPLICATION": R
On 01/19/2013 05:42 AM, Boszormenyi Zoltan wrote:
> Hi,
>
> I want to test my lock_timeout code under Windows and
> I compiled the whole PG universe with the MinGW cross-compiler
> for 64-bit under Fedora 18.
You're significantly better off compiling for native Windows if at all
possible. Windows c
On 01/19/2013 11:09 PM, 朱冯贶天 wrote:
> After downloading the source code, I enter the
> "postgresql-9.2.2\contrib\cube" to type 'nmake' with VS2010 command
> environment. However, the Makefile is not compatible with vs2010.
Correct - PostgreSQL's makefiles are written for GNU make and a
unix-like
On 01/21/2013 10:03 AM, Craig Ringer wrote:
> On 01/19/2013 04:08 AM, Boszormenyi Zoltan wrote:
>> However, I am not sure whether Cygwin provides the mkstemp() call or not.
>> Searching... Found bugzilla reports against mkstemp on Cygwin.
> Is Cygwin a platform that should be targeted for the serve
On Fri, Jan 18, 2013 at 3:31 AM, Jeff Davis wrote:
> So, I attached a new version of the patch that doesn't look at the VM
> for tables with fewer than 32 pages. That's the only change.
That certainly seems worthwhile, but I still don't want to get rid of
this code. I'm just not seeing a reason
On 01/19/2013 04:08 AM, Boszormenyi Zoltan wrote:
>
> However, I am not sure whether Cygwin provides the mkstemp() call or not.
> Searching... Found bugzilla reports against mkstemp on Cygwin.
Is Cygwin a platform that should be targeted for the server backend
these days?
I can understand making s
On 01/17/2013 09:36 PM, Magnus Hagander wrote:
>
> Yeah. I used to have an AMI with the VS environment preinstalled on
> Amazon, but I managed to fat finger things and delete it at some point
> and haven't really had time to rebuild it.
>
> Having a script that would download and install all the pr
Katsumata-san,
> In this patch, I made below.
> a) adding new privileges for replication:"MASTER REPLICATION" and "CASCADE
> REPLICATION"
>"MASTER REPLICATION": Replication-connection to master server is only
> allowed
>"CASCADE REPLICATION": Replication-connection to cascade server is on
On 01/18/2013 11:50 PM, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 10:36 AM, Merlin Moncure wrote:
>> Any scenario that involves non-trivial amount of investigation or
>> development should result in us pulling the patch for rework and
>> resubmission in later 'festit's closing time as they
On 19 January 2013 20:38, Noah Misch wrote:
> staticloud.com seems to be gone. Would you repost these?
I've pushed these to a git repo, hosted on github.
https://github.com/petergeoghegan/commit_delay_benchmarks
I'm sorry that I didn't take the time to make the html benchmarks
easily viewable
On Sunday, January 20, 2013, Simon Riggs wrote:
> On 20 January 2013 18:42, Robert Haas >
> wrote:
> > On Sat, Jan 19, 2013 at 5:21 PM, Jeff Janes
> > >
> wrote:
> >> Sometime this type of high-level summary review does happen, at the
> senior
> >> person's whim, but is not a formal part of the c
On Thu, Jan 17, 2013 at 5:50 PM, Jeff Davis wrote:
> If the "without interruption" part becomes a practical problem, it seems
> fairly easy to fix: drop the pin and pick it up again once every K
> pages. Unless I'm missing something, this is a minor concern.
I think probably so.
> Test plan:
>
>
2013/1/20 Robert Haas :
> On Sun, Jan 20, 2013 at 3:21 PM, Tom Lane wrote:
>> I suppose this complaint is based on the idea that we could have
>> declared format() as format(fmt text, VARIADIC values text[]) if
>> only the argument matching rules were sufficiently permissive.
>> I disagree with th
2013/1/20 Robert Haas :
> On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane wrote:
That's utter nonsense. Why wouldn't people expect concat(), for
example, to work for large (or even just moderate-sized) arrays?
>>
>>
On Sun, Jan 20, 2013 at 3:21 PM, Tom Lane wrote:
> I suppose this complaint is based on the idea that we could have
> declared format() as format(fmt text, VARIADIC values text[]) if
> only the argument matching rules were sufficiently permissive.
> I disagree with that though. For that to be any
On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane wrote:
>>> That's utter nonsense. Why wouldn't people expect concat(), for
>>> example, to work for large (or even just moderate-sized) arrays?
>
>> /me blinks.
>
>> What does tha
On Sun, Jan 20, 2013 at 2:39 PM, Simon Riggs wrote:
> (Without meaning to paraphrase you in any negative way...)
>
> Judgements made in a few minutes are very frequently wrong, and it
> takes a lot of time to convince the person making snap decisions that
> they should revise their thinking in lig
Robert Haas writes:
> On Sat, Jan 19, 2013 at 11:58 AM, Pavel Stehule
> wrote:
>> We introduced VARIADIC "any" function. Motivation for this kind of
>> function was bypassing postgresql's coerce rules - and own rules
>> implementation for requested functionality. Some builtins function
>> does i
2013/1/20 Simon Riggs :
> On 20 January 2013 18:42, Robert Haas wrote:
>> On Sat, Jan 19, 2013 at 5:21 PM, Jeff Janes wrote:
>>> Sometime this type of high-level summary review does happen, at the senior
>>> person's whim, but is not a formal part of the commit fest process.
>>>
>>> What I don't
Hello
2013/1/20 Tom Lane :
> Robert Haas writes:
>> On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane wrote:
>>> That's utter nonsense. Why wouldn't people expect concat(), for
>>> example, to work for large (or even just moderate-sized) arrays?
>
>> /me blinks.
>
>> What does that have to do with anyt
On Sun, Jan 20, 2013 at 11:38 AM, Robert Haas wrote:
> On Sun, Jan 20, 2013 at 9:58 AM, Phil Sorber wrote:
>> This was done to silence useless error messages in the logs. If you
>> attempt to connect as some user that does not exist, or to some
>> database that does not exist, it throws an error
On 20 January 2013 18:42, Robert Haas wrote:
> On Sat, Jan 19, 2013 at 5:21 PM, Jeff Janes wrote:
>> Sometime this type of high-level summary review does happen, at the senior
>> person's whim, but is not a formal part of the commit fest process.
>>
>> What I don't know is how much work it takes
On 01/20/2013 01:37 PM, Robert Haas wrote:
On Sat, Jan 19, 2013 at 11:58 AM, Pavel Stehule wrote:
We introduced VARIADIC "any" function. Motivation for this kind of
function was bypassing postgresql's coerce rules - and own rules
implementation for requested functionality. Some builtins functi
On 3 January 2013 13:49, Ali Dar wrote:
> Find attached an initial patch for ALTER RENAME RULE feature. Please note
> that it does not have any documentation yet.
>
Hi,
I just got round to looking at this. All-in-all it looks OK. I just
have a few more review comments, in addition to Stephen's c
Stephen Frost writes:
> I'm curious if this is going to help with rollback's of transactions
> which created lots of tables..? We've certainly seen that take much
> longer than we'd like, although I've generally attributed it to doing
> all of the unlink'ing and truncating of files.
If a single
Robert Haas writes:
> On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane wrote:
>> That's utter nonsense. Why wouldn't people expect concat(), for
>> example, to work for large (or even just moderate-sized) arrays?
> /me blinks.
> What does that have to do with anything? IIUC, the question isn't
> whe
Bruce Momjian writes:
> ! * Using pg_restore --single-transaction is faster than
> other
> ! * methods, like --jobs.
Is this still the case now that Jeff's AtEOXact patch is in? The risk
of locktable overflow with --single-transaction makes me think that
pg_u
Jeff Janes writes:
> [ patch for AtEOXact_RelationCache ]
I've reviewed and committed this with some mostly-cosmetic adjustments,
notably:
* Applied it to AtEOSubXact cleanup too. AFAICS that's just as
idempotent, and it seemed weird to not use the same technique both
places.
* Dropped the hac
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> Thanks for looking at it. I'll move it 9.4 CF-1.
Awesome, thanks.
Stephen
signature.asc
Description: Digital signature
On Sat, Jan 19, 2013 at 5:21 PM, Jeff Janes wrote:
> Sometime this type of high-level summary review does happen, at the senior
> person's whim, but is not a formal part of the commit fest process.
>
> What I don't know is how much work it takes for one of those senior people
> to make one of thos
* Jeff Janes (jeff.ja...@gmail.com) wrote:
> By making the list over-flowable, we fix a demonstrated pathological
> workload (restore of huge schemas); we impose no detectable penalty to
> normal workloads; and we fail to improve, but also fail to make worse, a
> hypothetical pathological workload.
On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane wrote:
>> disagree - non variadic manner call should not be used for walk around
>> FUNC_MAX_ARGS limit. So there should not be passed big array.
>
> That's utter nonsense. Why wouldn't people expect concat(), for
> example, to work for large (or even jus
On Sat, Jan 19, 2013 at 11:58 AM, Pavel Stehule wrote:
> We introduced VARIADIC "any" function. Motivation for this kind of
> function was bypassing postgresql's coerce rules - and own rules
> implementation for requested functionality. Some builtins function
> does it internally - but it is not p
2013/1/17 Daniel Farina :
> I realized while making my adjustments that I pointlessly grew some input
> checking in the inner loop. I just hoisted it out in this version.
Since psql uses libreadline, what do you think about to call
rl_clear_screen() inside that "while (true)" loop? Obviously we s
On 20 January 2013 16:30, Stephen Frost wrote:
> Dean,
>
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> I've been thinking about WITH CHECK OPTION for auto-updatable views.
>> Given the timing I doubt if this will be ready for 9.3, since I only
>> get occasional evenings and weekends to hac
Robert Haas wrote:
> I heartily agree. I can say from firsthand experience that when minor
> releases break things for customers (and they do), the customers get
> *really* cranky. Based on recent experience, I think we should be
> tightening our standards for what gets back-patched, not loosening
On 5 January 2013 16:58, Magnus Hagander wrote:
> Attached is an updated version of the patch, per the comments from Tom
> and rebased on top of the current master. Since it's been a long time
> ago, and some code churn in the area, another round of review is
> probably a good thing...
>
I took a
On Sat, Jan 19, 2013 at 12:33 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> On the other hand, discrepancies in between command line arguments
>> processing in our tools are already not helping our users (even if
>> pg_dump -d seems to have been fixed along the years); so much so that
>> I'm
On Sun, Jan 20, 2013 at 9:58 AM, Phil Sorber wrote:
> This was done to silence useless error messages in the logs. If you
> attempt to connect as some user that does not exist, or to some
> database that does not exist, it throws an error in the logs, even
> with PQping. You could fix it with env
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> I've been thinking about WITH CHECK OPTION for auto-updatable views.
> Given the timing I doubt if this will be ready for 9.3, since I only
> get occasional evenings and weekends to hack on postgres, but I think
> it's probably worth kicking
On Sun, Jan 20, 2013 at 10:53 AM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah. We'd need to think a little bit about how to make this work,
>> since I think that adding a gajillion booleans to pg_authid will not
>> make anyone very happy. But I like the idea. GRANT
>> kill_sessions_of_other_
Kohei KaiGai writes:
> About ALTER FUNCTION towards aggregate function, why we should raise
> an error strictly?
I agree we probably shouldn't --- traditionally we have allowed that,
AFAIR, so changing it would break existing applications for little
benefit.
Similarly, you should not be throwing
Bruce Momjian writes:
> Can someone comment on the attached patch? pg_upgrade was testing if
> system() returned a non-zero value, while I am thinking I should be
> adjusting system()'s return value with WEXITSTATUS().
AFAIK it's not very good style to test the result as an integer, and
testin
On Sun, Jan 20, 2013 at 4:59 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> + PGresult *res = ExecuteSqlQueryForSingleRow(fout, "SELECT
>> pg_is_in_recovery()");
>
> That function call needs to be schema-qualified for security.
Ha! I wonder if I can set up an autoresponder to *mys
Magnus Hagander writes:
> + PGresult *res = ExecuteSqlQueryForSingleRow(fout, "SELECT
> pg_is_in_recovery()");
That function call needs to be schema-qualified for security.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
Robert Haas writes:
> Yeah. We'd need to think a little bit about how to make this work,
> since I think that adding a gajillion booleans to pg_authid will not
> make anyone very happy. But I like the idea. GRANT
> kill_sessions_of_other_users TO bob? GRANT install_untrusted_pls TO
> any_datab
* Xi Wang (xi.w...@gmail.com) wrote:
> Don't write past the end of tborder; the size is width + 1.
This whole block of code is woefully without any comments. :(
Strictly speaking, it's this:
tborder[i] = '\0';
Which ends up writing past the end of the buffer (which is allocated as
'width + 1').
* Xi Wang (xi.w...@gmail.com) wrote:
> The correct NULL check should use `*newval'; `newval' must be non-null.
Why isn't this using pstrdup()..?
Thanks,
Stephen
signature.asc
Description: Digital signature
On Sun, Jan 20, 2013 at 8:40 AM, Robert Haas wrote:
> On Fri, Jan 18, 2013 at 4:17 PM, Phil Sorber wrote:
>> Updated patch is rebased against current master and copyright year is
>> updated.
>
> I took a look at this. According to the documentation for
> PQpingParams: "It accepts connection par
Bruce Momjian wrote:
>> Why are you insisting on cramming version() into this? It could
>> just as easily be a different query.
>
> I am fine with that:
Done.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
2013/1/20 Xi Wang :
> The correct NULL check should use `*newval'; `newval' must be non-null.
[... cutting code ...]
Please see [1] to know how is our submit patch process.
[1] http://wiki.postgresql.org/wiki/Submitting_a_Patch
regards,
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - sk
On Sat, Jan 19, 2013 at 8:54 AM, Simon Riggs wrote:
> On 19 January 2013 13:45, Kohei KaiGai wrote:
>> I think, it is a time to investigate separation of database superuser
>> privileges
>> into several fine-grained capabilities, like as operating system doing.
>> https://github.com/torvalds/lin
On Fri, Jan 18, 2013 at 4:17 PM, Phil Sorber wrote:
> Updated patch is rebased against current master and copyright year is updated.
I took a look at this. According to the documentation for
PQpingParams: "It accepts connection parameters identical to those of
PQconnectdbParams, described above.
On Sat, Jan 19, 2013 at 4:47 AM, Tomonari Katsumata
wrote:
> Hi,
>
> I made a patch to divide privileges for replication role.
>
> Currently(9.2), the privilege for replication role is
> true / false which means that standby server is able to
> connect to another server or not with the replication
(2012/12/10 3:06), Tomas Vondra wrote:
On 29.10.2012 04:58, Satoshi Nagayasu wrote:
2012/10/24 1:12, Alvaro Herrera wrote:
Satoshi Nagayasu escribi�:
With this patch, walwriter process and each backend process
would sum up dirty writes, and send it to the stat collector.
So, the value could b
(2012/11/27 7:42), Alvaro Herrera wrote:
Satoshi Nagayasu escribió:
I attached the latest one, which splits the reset_time
for bgwriter and walwriter, and provides new system view,
called pg_stat_walwriter, to show the dirty write counter
and the reset time.
Thanks. I gave this a look and I
2013/1/20 Amit kapila :
> On Sunday, January 20, 2013 4:04 AM Dickson S. Guedes wrote:
> 2013/1/18 Amit kapila :
>>> Please find the rebased Patch for Compute MAX LSN.
>
>>The function 'remove_parent_refernces' couldn't be called
>>'remove_parent_references' ?
>
> Shall fix this.
>
>> Why not an ex
On Tue, Jan 15, 2013 at 10:35 PM, Magnus Hagander wrote:
> On Tue, Jan 15, 2013 at 12:13 AM, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7809
>> Logged by: Joe Van Dyk
>> Email address: j...@tanga.com
>> PostgreSQL version: 9.2.2
>> Operati
96 matches
Mail list logo
