On Mon, Aug 16, 2010 at 14:33, Tom Lane wrote:
> Alex Hunsaker writes:
>> How exactly patches get applied into back branches?
> There was discussion about that before, but I don't know whether we
> really have a solution that will work comfortably.
I don't either, not
On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
> OK, try this. It takes about 14 seconds on my machine on my copy of
> Magnus's test repository. Output looks like this:
14 seconds! That sound much too slow :-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker wrote:
>> On Mon, Aug 16, 2010 at 18:48, Robert Haas wrote:
>>> OK, try this. It takes about 14 seconds on my machine on my copy of
>>> Magnus's test repository.
On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
>> On Tue, Aug 17, 2010 at 08:17, Robert Haas wrote:
>>> /me is very sorry master. Please beat your unworthy servant only
>>> lightly... or alternative
On Tue, Aug 17, 2010 at 06:31, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> Other comments?
>
> Will we be able to use it for psql while keeping just one database
> connection? I assume the answer is 'no', but it sure would be nice..
I think thats something that could be
On Tue, Aug 17, 2010 at 11:54, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker wrote:
>> On Tue, Aug 17, 2010 at 09:21, Robert Haas wrote:
>>> On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker wrote:
>>>> On Tue, Aug 17, 2010 at 08:17, Robert
On Tue, Aug 17, 2010 at 13:43, Robert Haas wrote:
> On Tue, Aug 17, 2010 at 3:40 PM, Tom Lane wrote:
>> It'd be interesting to look into the cvs2git
>> source code to see exactly what causes it to add a commit message
>> like that.
>
> I vigorously agree.
How sure are we that its not the cvs2sv
On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker wrote:
> How sure are we that its not the cvs2svn step that is screwing it up?
urp, I jumped to a conclusion while skimming the cvs2git.options file
Magnus posted. With all the references to svn and things like
"GitRevisionRecorder('cv
It bit rotted a bit find a new version attached that includes the
following fixes:
- show_session_authorization() no longer exists, instead access the
session_authorization_guc directly (like we do for show_role in
commands/variable.c). I find it quite ugly tho...
- it changed %u to %U and %U to b
On Tue, Jul 12, 2011 at 12:45, David E. Wheeler wrote:
> Hackers,
> That is, if a record is passed to a PL/Perl function, it's correctly
> converted into a hash. If, however, an array of records are passed, the
> record are stringified, rather than turned into hashes. This seems
> inconsistent
On Wed, Jul 27, 2011 at 14:08, Tom Lane wrote:
> Yeah. If we're going to allow this then we should just have a concept
> of a non-inherited constraint, full stop. This might just be a matter
> of removing the error thrown in ATAddCheckConstraint, but I'd be worried
> about whether pg_dump will
On Thu, Aug 4, 2011 at 09:11, Andrew Dunstan wrote:
>> What *I'd* like is a way to prevent libperl from touching the host
>> application's signal handlers at all. Sadly, Perl does not actually
>> think of itself as an embedded library, and therefore thinks it owns all
>> resources of the process
On Thu, Aug 4, 2011 at 16:34, David E. Wheeler wrote:
> On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote:
>
>> Mainly the options im thinking about are:
>> 1) if anyone touches %SIG die
>> 2) turn %SIG into a regular hash so people can set/play with %SIG, but
>> it
On Thu, Aug 4, 2011 at 17:52, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Thu, Aug 4, 2011 at 16:34, David E. Wheeler wrote:
>>> On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote:
>>>> 3) local %SIG before we call their trigger function. This lets signals
>>&
On Thu, Aug 4, 2011 at 19:40, Andrew Dunstan wrote:
> Let's slow down a bit. Nobody that we know of has encountered the problem
> Tom's referring to, over all the years plperlu has been available. The
> changes you're proposing have the potential to downgrade the usefulness of
> plperlu considera
On Fri, Aug 5, 2011 at 08:53, Andrew Dunstan wrote:
>
>
> On 08/04/2011 11:23 PM, Alex Hunsaker wrote:
>>
>> [ ... don't let people set signal handlers postgres sets ]
>
> This whole thing is a massive over-reaction to a problem we almost certainly
> know how
On Sun, Aug 7, 2011 at 17:06, Tim Bunce wrote:
> On Sat, Aug 06, 2011 at 12:37:28PM -0600, Alex Hunsaker wrote:
>> ...
>> Find attached a version that does the equivalent of local %SIG for
>> each pl/perl(u) call.
>
>> + gv = gv_fetchpv("SIG&qu
On Fri, Aug 12, 2011 at 18:00, David E. Wheeler wrote:
> Hackers,
>
> Given this script on 9.1beta3:
>
> BEGIN;
>
> CREATE EXTENSION plperl;
>
> CREATE OR REPLACE FUNCTION wtf(
> ) RETURNS TEXT[] LANGUAGE plperl AS $$ return []; $$;
>
> SELECT wtf() = '{}'::TEXT[];
> Why is that? I
On Wed, Aug 17, 2011 at 10:06, Andrew Dunstan wrote:
>
>
> On 08/12/2011 09:17 PM, Alex Hunsaker wrote:
>
> [empty arrays returned are not handled correctly]
>
>>
>> Anyway, the attached patch fixes it for me. That is when we don't have
>> an array state
On Thu, Sep 15, 2011 at 10:44, David E. Wheeler wrote:
> Hackers,
>
> Since installing Perl 5.14.1, I installed newer version of ExtUtils::ParseXS
> from CPAN. I installed it with `make install UNINST=1`, which removes the
> copy of xsubpp that ships with core Perl. This results in an error duri
On Thu, Sep 15, 2011 at 15:53, David E. Wheeler wrote:
> On Sep 15, 2011, at 4:41 PM, Alex Hunsaker wrote:
>
>> ExtUtils searches @INC, privlibexp maybe we should do that?
>
> Yes, I just got an email from David Golden to that effect. So perhaps the
> attached patch is be
On Fri, Sep 16, 2011 at 10:37, Tom Lane wrote:
> Greg Stark writes:
>> On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane wrote:
>>> Does anyone want
>>> to argue for doing something more complicated, and if so what exactly?
>
>> Well there's no harm trying to write to oom_score_adj and if that
>> fails
On Mon, Oct 3, 2011 at 04:20, Amit Khandekar
wrote:
> Is there a plan to commit this issue? I am still seeing this issue on
> PG 9.1 STABLE branch. Attached is a small patch that targets only the
> specific issue in the described testcase :
>
> create or replace function zerob() returns text as $
On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
wrote:
> WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
> utf8_str, so pg_verify_mbstr_len() will not get called. That's the
> reason, pg_verify_mbstr_len() is under the ( ret == utf8_str )
> condition.
Consider a latin1 database
On Tue, Oct 4, 2011 at 03:09, Amit Khandekar
wrote:
> On 4 October 2011 14:04, Alex Hunsaker wrote:
>> On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
>> wrote:
>>
>>> WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
>>> utf8_str, so pg
On Tue, Oct 4, 2011 at 23:46, Amit Khandekar
wrote:
> On 4 October 2011 22:57, Alex Hunsaker wrote:
>> On Tue, Oct 4, 2011 at 03:09, Amit Khandekar
>> wrote:
>>> On 4 October 2011 14:04, Alex Hunsaker wrote:
>>>> On Mon, Oct 3, 2011 at 23:35, Amit Kh
On Wed, Oct 5, 2011 at 00:30, Alex Hunsaker wrote:
> On Tue, Oct 4, 2011 at 23:46, Amit Khandekar
> wrote:
>> You mean the final changes in plperl_helpers.h would look like
>> something like this right? :
>>
>> static inline char *
>> utf_
Hi! *Waves*
First off, it all seems to work as described:
- regressions pass
- domains work
- tried various inherit options (merging constraints, alter table no
inherit etc)
- pg_dump/restore
I didn't care for the changes to gram.y so I reworked it a bit so we
now pass is_only to AddRelationNewCo
On Wed, Oct 5, 2011 at 08:18, Robert Haas wrote:
> On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar
> wrote:
>> I have no more issues with the patch.
>> Thanks!
>
> I think this patch needs to be added to the open CommitFest, with
> links to the reviews, and marked Ready for Committer.
The open co
tldr:
Seems to be broken by
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4da99ea4231e3d8bbf28b666748c1028e7b7d665
:
commit 4da99ea4231e3d8bbf28b666748c1028e7b7d665
Author: Robert Haas
Date: Mon Jun 27 10:27:17 2011 -0400
Avoid having two copies of the HOT-chain search logi
On Thu, Oct 6, 2011 at 02:42, Nikhil Sontakke wrote:
> Hi Alex,
>
>> I didn't care for the changes to gram.y so I reworked it a bit so we
>> now pass is_only to AddRelationNewConstraint() (like we do with
>> is_local). Seemed simpler but maybe I missed something. Comm
ELECT statements.
)
Thanks,
-- Alex -- alex-goncha...@comcast.net --
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,--- I/Alex (Thu, 06 Oct 2011 14:02:14 -0400) *
| My understanding is that libpq does not allow one to find if a result
| set column is nullable.
,--- You/Merlin (Thu, 6 Oct 2011 15:16:18 -0500) *
| why aren't you using PQgetisnull()?
This function is not about the nullability of a c
,--- I/Alex (Thu, 06 Oct 2011 14:02:14 -0400) *
| My understanding is that libpq does not allow one to find if a result
| set column is nullable.
,--- You/Merlin (Thu, 6 Oct 2011 15:16:18 -0500) *
| why aren't you using PQgetisnull()?
,--- I/Alex (Thu, 06 Oct 2011 16:22:28
,--- You/Florian (Fri, 7 Oct 2011 01:00:40 +0200) *
| On Oct7, 2011, at 00:02 , Alex Goncharov wrote:
| > ,--- Florian Pflug (Thu, 6 Oct 2011 23:16:53 +0200) *
| > | Sure, but there are still a lot of cases where the database could deduce
| > | (quite easily) that a result column
----*
I replied politely:
,--- I/Alex (Thu, 06 Oct 2011 16:22:28 -0400) *
| This function is not about the nullability of a column but rather
| about the value in a result set cell:
|
| PQgetisnull: Tests a field for a null value.
|
|
The obvious typos (sorry if this is a duplicate message, I sent the
first one from a wrong address):
,--- I/Alex (Thu, 06 Oct 2011 19:42:13 -0400) *
| (may use pg_attribute.attnotnull on t1, t2, is I didn't see the 'create's.
(may use pg_attribute.attnotnull on t1, t2,
I'll "PQexec(a-fancy-select-from-pg_attribute)".
Ugly :(
-- Alex -- alex-goncha...@comcast.net --
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to be answered about result sets.
-- Alex -- alex-goncha...@comcast.net --
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the design of this *before* starting
| work (in a separate thread). Otherwise, you might discover
| objections to the general approach, or even to the whole feature,
| only after you put considerable effort into this.
|
| best regards,
| Florian Pflug
Thank you: this is all very valuable,
-- Al
On Thu, Oct 6, 2011 at 07:24, Robert Haas wrote:
> On Wed, Oct 5, 2011 at 10:29 PM, Robert Haas wrote:
>> On Wed, Oct 5, 2011 at 5:53 PM, Alex Hunsaker wrote:
>>> tldr:
>>>
>>> Seems to be broken by
>>> http://git.postg
On Fri, Oct 7, 2011 at 00:28, Nikhil Sontakke wrote:
> Hi Alex,
>> So with it all spelled out now I see the "constraint must be added to
>> child tables too" check is dead code.
>>
>
> Thanks the above step-wise explanation helps.
>
> But AFAICS, the
,--- Peter Eisentraut (Fri, 07 Oct 2011 11:14:09 +0300) *
| On tor, 2011-10-06 at 20:15 -0400, Alex Goncharov wrote:
| > P.S. And on the odd chance that somebody thinks that this
| > functionality would be possible and helpful to add to libpq, and
| > the problem is in th
,--- You/Merlin (Fri, 7 Oct 2011 07:39:57 -0500) *
| On Thu, Oct 6, 2011 at 5:02 PM, Alex Goncharov
| > ,--- Merlin Moncure (Thu, 6 Oct 2011 16:28:56 -0500) *
| > | hm, good point. not sure how it's useful though. I suppose an
| > | application could leverage that for valid
On Fri, Oct 7, 2011 at 07:53, Robert Haas wrote:
> The only way we could
> trip up in that case is if there were two identically named
> constraints. We'd have to visit the first tuple, update it, then
> visit the second tuple, recurse (thus incrementing the command
> counter), and then visit th
On Fri, Oct 7, 2011 at 09:50, Robert Haas wrote:
> On Fri, Oct 7, 2011 at 11:19 AM, Alex Hunsaker wrote:
>> My only thought is
>> perhaps we should add that missing unique index on (conrelid,
>> conname). If we are not going to support duplicate names in the code,
>>
On Wed, Oct 5, 2011 at 20:36, Robert Haas wrote:
> On Wed, Oct 5, 2011 at 5:03 PM, Alex Hunsaker wrote:
>> On Wed, Oct 5, 2011 at 08:18, Robert Haas wrote:
>>> On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar
>>> wrote:
>>>> I have no more issues with the p
The obvious typos:
,--- I/Alex (Thu, 06 Oct 2011 19:42:13 -0400) *
| (may use pg_attribute.attnotnull on t1, t2, is I didn't see the 'create's.
(may use pg_attribute.attnotnull on t1, t2, if I didn't see the 'create's.
| Now, for this statement, I ca
On Fri, Oct 7, 2011 at 21:30, Nikhil Sontakke wrote:
> Hi Alex,
>
> I guess we both are in agreement with each other :)
>
> After sleeping over it, I think that check is indeed dead code with this new
> non-inheritable check constraints functionality in place. So unless you
On Sun, Oct 9, 2011 at 09:17, Greg Stark wrote:
> On Fri, Oct 7, 2011 at 5:45 PM, Alex Hunsaker wrote:
>> If I find the time maybe Ill submit something along these lines for
>> the next commit fest.
>>
>
> So i just picked up the non-inherited constraints patch and
n of both? PA-RISC? IA64?
Thanks,
-- Alex -- alex-goncha...@comcast.net --
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e items on HPPA 10.20.
Or anything of the items 1 to 3 is not true or not certain?
Thanks again!
-- Alex -- alex-goncha...@comcast.net --
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thank you all who replied!
-- Alex -- alex-goncha...@comcast.net --
/*
* They're only trying to make me LOOK paranoid!
*/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ter "e164.area_codes_format"
contrib_regression=# SET custom_variable_classes='e164';
ERROR: parameter "custom_variable_classes" cannot be changed now
I wonder how/if other contrib modules ever do regression tests on
their GUC options?
At this rate, removing the custom_variable_cl
On Wed, Oct 12, 2011 at 15:00, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Oct 12, 2011, at 9:15 AM, Tom Lane wrote:
>>> Well, the real question is why a function declared to return VOID cares
>>> at all about what the last command in its body is. If this has changed
>>> since previous ve
On Wed, Oct 12, 2011 at 17:53, David E. Wheeler wrote:
> On Sep 15, 2011, at 3:04 PM, Alex Hunsaker wrote:
>
>> Close, seems I was wrong about the typemap ExtUtils::ParseXS does not
>> install a new one so we still need to point to the one in privlib.
>> Also xsubpp is no
On Wed, Oct 12, 2011 at 15:33, Alex Hunsaker wrote:
> On Wed, Oct 12, 2011 at 15:00, Tom Lane wrote:
>> The core of the problem seems to be that if SvROK(sv) then
>> the code assumes that it must be intended to convert that to an array or
>> composite, no matter whether the
On Thu, Oct 13, 2011 at 16:05, Tom Lane wrote:
>
> Applied with some further hacking of my own to clean up memory leaks
> and grotty coding.
Thanks!
BTW after seeing it I agree passing in fcinfo (and the other fixes) to
plperl_sv_to_datum() is better.
--
Sent via pgsql-hackers mailing list (pg
On Sat, Jun 6, 2015 at 7:03 PM, Peter Eisentraut wrote:
> With the recently released Perl 5.22.0, the tests fail thus:
>
> -ERROR: Global symbol "$global" requires explicit package name at line 3.
> -Global symbol "$other_global" requires explicit package name at line 4.
> +ERROR: Global symbol
ase consistency violation.
Can anybody explain this situation with clogs?
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
providing illegal input parameters we have no
any exceptions or errors about that.
I think that to_timestamp() need to has more format checking than it has
now.
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsq
eters values:
postgres=# SELECT TO_TIMESTAMP('2016-06-13 99:99:99', 'YYYYMMDD
HH24:MI:SS');
to_timestamp
2016-01-06 14:40:39+03
(1 row)
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent
On 23.06.2016 16:30, Bruce Momjian wrote:
On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote:
On Monday, 20 June 2016 8:53 PM, Alex Ignatov wrote:
On 13.06.2016 18:52, amul sul wrote:
And it wont stop on some simple whitespace. By using to_timestamp you
can get any output results by
On 23.06.2016 19:37, David G. Johnston wrote:
On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov
mailto:a.igna...@postgrespro.ru>>wrote:
On 23.06.2016 16:30, Bruce Momjian wrote:
On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote:
On Monday, 20 June 2016 8
--
12
(1 row)
On the our side we have some discussions about to write a patch that
will change this incorrect behavior. So stay tuned.
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 20.06.2016 17:09, Albe Laurenz wrote:
Tom Lane wrote:
I don't necessarily have an opinion yet. I would like to see more than
just an unsupported assertion about what Oracle's behavior
on at every row where its value is needed."
Something wrong with executor? Is it bug or executor feature related
with subquery?
--
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 29.06.2016 15:30, David G. Johnston wrote:
More specifically...
On Wed, Jun 29, 2016 at 7:34 AM, Michael Paquier
mailto:michael.paqu...@gmail.com>>wrote:
On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov
mailto:a.igna...@postgrespro.ru>> wrote:
> Hello!
&
amount of WAL
(less indices will need be updated). Of course it will make index scan
a bit worse, however it looks like at least Uber is fine with that
extra cost of index scan.
Does it make sense to implement that kind of index as an access method?
Vladimir
You mean IOT like Oracle have
On Wed, Nov 2, 2011 at 17:12, Andrew Dunstan wrote:
>>> Considering that the issue appears to have been ignored from
>>> mid-February until early October, I don't see why it should now get to
>>> jump to the head of the queue. Other people may have different
>>> opinions, of course.
>>
>> Added.
===
(The above was obtained in 9.1.1; the subsequent build with GCC 4.1.2
succeeds without warnings.)
If the above change causes a warning in a client code, so much the
better: the client code is doing something unreasonable like the "*s"
assignment in my exam
,--- I/Alex (Tue, 13 Dec 2011 07:55:45 -0500) *
| If the above change causes a warning in a client code, so much the
| better: the client code is doing something unreasonable like the "*s"
| assignment in my example above.
,--- Robert Haas (Tue, 13 Dec 2011 10:51:54 -0500) *
| Or
On Fri, Dec 16, 2011 at 12:06, Alvaro Herrera
wrote:
> Yeah. Nikhil, Alex, this is the merged patch. Have a look that it
> still works for you (particularly the pg_dump bits) and I'll commit it.
> I adjusted the regression test a bit too.
Other than the version checks seem to
On Fri, Dec 16, 2011 at 14:01, Alvaro Herrera
wrote:
>
> Excerpts from Alex Hunsaker's message of vie dic 16 17:50:12 -0300 2011:
>>
>> On Fri, Dec 16, 2011 at 12:06, Alvaro Herrera
>> wrote:
>>
>> > Yeah. Nikhil, Alex, this is the merged patch.
On Wed, Jan 4, 2012 at 13:13, Andrew Dunstan wrote:
>
>
> On 01/04/2012 12:56 PM, Tom Lane wrote:
>> I looked at that last night but it appeared that SvOK would be perfectly
>> happy. (Didn't actually try it, though, I was just eyeballing the flags
>> in gdb.)
>
> I tested it and you're right,
On Thu, Jan 5, 2012 at 16:02, Andrew Dunstan wrote:
> Fix breakage from earlier plperl fix.
>
> Apparently the perl garbage collector was a bit too eager, so here
> we control when the new SV is garbage collected.
I know im a little late to the party...
I can't help but think this seems a bit in
On Thu, Jan 5, 2012 at 16:59, Andrew Dunstan wrote:
>
>
> On 01/05/2012 06:31 PM, Alex Hunsaker wrote:
>>
>> On Thu, Jan 5, 2012 at 16:02, Andrew Dunstan wrote:
>>>
>>> Fix breakage from earlier plperl fix.
>> I can't help but think this seems
On Fri, Jan 6, 2012 at 06:34, Andrew Dunstan wrote:
>> PFA that copies if its readonly and its not a scalar.
>>
>> I didn't bother adding regression tests-- should I have?
> I have several questions.
>
> 1. How much are we actually saving here? newSVsv() ought to be pretty cheap,
> no? I imagine
,--- You/Peter (Tue, 10 Jan 2012 19:13:42 +0200) *
| On tis, 2011-12-13 at 07:55 -0500, Alex Goncharov wrote:
| > char *PQcmdStatus(PGresult *res);
| > char *PQcmdTuples(PGresult *res);
| >
| > Unreasonable:
| >
| > a. What, these two can modify 'res' I pass
On Fri, Jan 6, 2012 at 14:05, Tom Lane wrote:
> Alex Hunsaker writes:
>> Oh my... I dunno exactly what I was smoking last night, but its a good
>> thing I didn't share :-). Uh so my test program was also completely
>> wrong, Ill have to redo it all. I've narrowed i
On Fri, Jan 13, 2012 at 16:07, Andrew Dunstan wrote:
>
>
> On 01/12/2012 09:28 PM, Alex Hunsaker wrote:
>>
>> Util.c/o not depending on plperl_helpers.h was also throwing me for a loop
>> so I fixed it and SPI.c... Thoughts?
>
>
> Basically looks good, but I&#
Greg Smith writes:
> One unicorn I would like to have here would give the CF app a database
> of recent e-mails to pgsql-hackers. I login to the CF app, click on
> "Add recent submission", and anything matching my e-mail address
> appears with a checkbox next to it. Click on the patch submissi
ej
>Seems like the file has changed since this patch was created. Please
>recreate the patch.
I've just tried to apply the original patch against a clean checkout of
master branch and it applies without a problem (no hunk failed, no
fuzziness.)
Could you please try again on
Andrew Dunstan writes:
> On 01/19/2012 12:59 PM, Alex Shulgin wrote:
>
>> Another idea: introduce some simple tag system in mails sent to -hackers
>> to be treated specially, e.g:
>>
>> @fest add-to-current
>>
>> to add new patch to the commit fest cu
ore elegant
solution. Or am I totally wrong?
Alex.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
for different tables - for the table in question it very well may ~20 disk
seeks per webpage view, so very high cache hit rate (ideally 100%) has to be
assured.
So - will the 'mlock' hack work? Or any other ideas for "pinning" a table in
memory?
- Alex
Heikki Li
On Sat, Nov 28, 2009 at 11:59, Tom Lane wrote:
> 1. I thought we'd agreed at
> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00558.php
> that the patch should support WITH on DML statements, eg
> with (some-query) insert into foo ...
> This might not take much more than grammar ad
On Fri, Dec 18, 2009 at 10:57, Tom Lane wrote:
> Obviously there's something there for the kernel guys to fix, but
> even with a non-borked kernel it's an expensive thing to do.
Any thoughts on back patching this? While its not a bug per-say, it
seems reasonably low-risk. I for one would love a
On Thu, Jan 7, 2010 at 15:16, Tim Bunce wrote:
> Is there any reason not to add .gitignore files into the repository?
> They'll make no difference to those who don't use git, but be very
> helpful to, and maintained by, those who do.
Since it seems we don't want them in CVS, maybe just add it to
On Mon, Jan 4, 2010 at 09:55, Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
>> Right. Which is why I like the idea of disabling the OOM killer for
>> the *postmaster*, but not the regular backends. Gives it a chance to
>> recover. It's not nice, but it's better than nothing.
>
> It doesn't soun
On Thu, Jan 7, 2010 at 20:26, Tom Lane wrote:
> Alex Hunsaker writes:
> We can either drop this in core (with a lot of #ifdef LINUX added)
Any thoughts on doing something like (in fork_process.c)
#ifdef LINUX
void oom_adjust()
{
...
}
#else
void oom_adjust() {}
#endif
So there is on
On Fri, Jan 8, 2010 at 07:53, Bruce Momjian wrote:
> Alex Hunsaker wrote:
>> On Thu, Jan 7, 2010 at 20:26, Tom Lane wrote:
>> > Alex Hunsaker writes:
> The usual solution for this kind of thing is:
>
> #ifdef LINUX
> #define OOM_ADJUST oom_adjust()
&
On Fri, Jan 8, 2010 at 07:27, Tom Lane wrote:
> Then, somebody who wants the feature would build with, say,
> -DLINUX_OOM_ADJ=0
> or another value if they want that.
Here is a stab at that.
It sets oom_adj for:
autovacuum workers
archivers (pgarch.c)
regular backends
Also it updates t
On Fri, Jan 8, 2010 at 02:03, Magnus Hagander wrote:
> You can always create your own branch with just the .gitignore files
> and merge that into whatever you're working on :)
The only thing annoying about that is if you generate diffs ala git
diff origin/master.. you get your .gitignore in it.
On Fri, Jan 8, 2010 at 10:07, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I don't want to go to the trouble of creating (and documenting) a
>> configure option for this. Much less a GUC ;-)
>
> Requiring a custom build to disable it would be horrible, in my view.
> Or, at bes
On Fri, Jan 8, 2010 at 10:24, Stephen Frost wrote:
> As I recall, oom_adj wasn't visible in the container because you
> explicitly set what proc entries processes can have access to when using
> VServers, and OpenSSH didn't handle that cleanly. Guess what I'm just
> saying is "don't just assume e
On Fri, Jan 8, 2010 at 12:45, Tom Lane wrote:
> Alex Hunsaker writes:
>> Sure this was openssh? I just looked through the entire cvs history
>> for opensshp and found 0 references to 'oom' let alone 'oom_adj'.
>> Maybe something distro specific?
>
&
On Fri, Jan 8, 2010 at 15:24, Stephen Frost wrote:
> There were a few issues, as it turns out, the particularly annoying one
> was in the init script which caused upgrades to fail due to sshd not
> being restarted, bug report here:
Thanks for the pointers!
> http://bugs.debian.org/cgi-bin/bugrep
On Sat, Jan 9, 2010 at 14:06, Peter Eisentraut wrote:
> I find this whole approach a bit evil.
I would tend to agree but this type of thing has been known since about 2004...
See http://thoughts.j-davis.com/2009/11/29/linux-oom-killer/,
particularly the comment from Greg Smith.
> If word of thi
On Wed, Jan 13, 2010 at 12:54, Tom Lane wrote:
> I'm a little worried by Stephen's plan, mainly because I'm concerned
> that it would lead to ALTER TABLE taking exclusive lock on a table long
> before it gets around to checking permissions. Still, that's just
> extending a window that exists now.
301 - 400 of 654 matches
Mail list logo
