On 8 February 2011 03:50, Robert Haas wrote:
> On Thu, Feb 3, 2011 at 11:00 PM, Robert Haas wrote:
>> On Fri, Jan 14, 2011 at 6:15 AM, Simon Riggs wrote:
>>> Patch to implement the proposed feature attached, for CFJan2011.
>>>
>>> 2 sub-command changes:
>>>
>>> ALTER TABLE foo ADD FOREIGN KEY fk
Robert Haas wrote:
> It appears that the open items list is a bit stale:
>
> http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items
>
> The first item listed there is, I believe, fixed.
That was "SSI HOT chain traversal issue" -- which was fixed. I just
moved it to "Resolved Issues".
>
On Thu, Jun 02, 2011 at 01:01:05PM -0500, Kevin Grittner wrote:
> If we're going to put this into the README-SSI as the proof of the
> validity of this optimization, I'd like to have a footnote pointing
> to a paper describing the "first commit in the cycle" aspect of a
> dangerous structure. Got
On Thu, Jun 2, 2011 at 5:35 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> It appears that the open items list is a bit stale:
>>
>> http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items
>>
>> The first item listed there is, I believe, fixed.
>
> That was "SSI HOT chain traversal issue"
On 03/06/11 02:36, Tom Lane wrote:
Robert Haas writes:
So I'm not sure work_disk is a great name.
I agree. Maybe something along the lines of "temp_file_limit"?
Also, once you free yourself from the analogy to work_mem, you could
adopt some more natural unit than KB. I'd think MB would be a
Noah Misch writes:
> On Tue, May 24, 2011 at 02:00:54PM -0400, Noah Misch wrote:
>> I took your lack of any response as non-acceptance of the plan I outlined.
>> Alas, the wrong conclusion. I'll send a patch this week.
> See attached arrdom1v1-polymorphism.patch. This currently adds one syscach
On 02/06/11 18:34, Jaime Casanova wrote:
- the patch adds this to serial_schedule but no test has been added...
diff --git a/src/test/regress/serial_schedule b/src/test/regress/serial_schedule
index bb654f9..325cb3d 100644
--- a/src/test/regress/serial_schedule
+++ b/src/test/regress/serial_sc
Noah Misch wrote:
> On Wed, May 25, 2011 at 10:07:45PM +0300, Peter Eisentraut wrote:
> > On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
> > > Enthusiastic +1 for this concept. There's at least one rough edge: it
> > > fails if
> > > you have another postmaster running on port 5432.
> >
>
Marco Nenciarini wrote:
> While I was working on automatic translation of PostgreSQL's
> documentation from SGML to XML, I found some minor issues.
>
> In the file doc/src/sgml/ecpg.sgml there are many lines of C code
> containing unescaped '<' characters.
>
> In the file doc/src/sgml/array.sgml
On Thu, Jun 02, 2011 at 06:56:02PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, May 24, 2011 at 02:00:54PM -0400, Noah Misch wrote:
> >> I took your lack of any response as non-acceptance of the plan I outlined.
> >> Alas, the wrong conclusion. I'll send a patch this week.
>
> > See a
2011/6/2 Mark Kirkwood :
> On 01/06/11 09:24, Cédric Villemain wrote:
>> * I am not sure it is better to add a fileSize like you did or use
>> relationgetnumberofblock() when file is about to be truncated or
>> unlinked, this way the seekPos should be enough to increase the global
>> counter.
>>
>
On Thu, Jun 2, 2011 at 3:02 PM, Jeff Davis wrote:
> On Thu, 2011-06-02 at 18:46 +, Christopher Browne wrote:
>> > 1. How would the time-zone be defined in this composite? Offset from GMT?
>> > Timezone (well, link thereto) with all DST rules intact? Would "extract"
>> > need to be modified to
On Thu, 2011-06-02 at 20:28 -0400, Robert Haas wrote:
> But that doesn't seem like enough, because if someone adds '1 day',
> knowing the offset isn't sufficient to figure out the answer. You
> have to know where the DST boundary is.
Good point, I guess the timezone itself needs to be stored. Tha
On 03/06/11 12:33, Cédric Villemain wrote:
2011/6/2 Mark Kirkwood:
On 01/06/11 09:24, Cédric Villemain wrote:
* I am not sure it is better to add a fileSize like you did or use
relationgetnumberofblock() when file is about to be truncated or
unlinked, this way the seekPos should be enough to in
>>> I don't much like that approach. The standby would need to be able to
>>> write the backup history file to the archive at the end of backup, and
>>> we'd have to reintroduce the code to fetch it from archive and, when
>>> streaming, from the master. At the moment, the archiver doesn't even run
I wrote:
> What I was thinking last night is that it'd be smart to move all this
> logic into the typcache, instead of repeating all the work each time we
> make the check.
Attached is a proposed patch that does it that way. I haven't finished
poking around to see if there are any other places be
hi guys:
I'm using int[] in postgrsql to store int array. I want to get max
value of each row . While I can't find any function to get it(max
function will get max array in one column) . Even I could write a sql
function to get the max value. I still think a native funtion is better
. Can
On Jun 2, 2011, at 7:48 PM, Jeff Davis wrote:
> On Thu, 2011-06-02 at 20:28 -0400, Robert Haas wrote:
>> But that doesn't seem like enough, because if someone adds '1 day',
>> knowing the offset isn't sufficient to figure out the answer. You
>> have to know where the DST boundary is.
>
> Good poi
Excerpts from Tom Lane's message of jue jun 02 15:49:53 -0400 2011:
> The results of such a test wouldn't be worth the electrons they're
> written on anyway: you're ignoring the likelihood that two instances of
> shared memory would overrun the kernel's SHMALL limit, when a single
> instance would
On Thu, Jun 2, 2011 at 8:25 PM, Noah Misch wrote:
> I don't doubt that's usable, and folks would find the behavior of their
> applications acceptable given that approach. However, it's an arbitrary (from
> the user's perspective) difference in behavior compared to the interaction of
> polymorphic
On Thu, Jun 2, 2011 at 10:52 PM, fanngyuan wrote:
> hi guys:
> I'm using int[] in postgrsql to store int array. I want to get max value
> of each row . While I can't find any function to get it(max function will
> get max array in one column) . Even I could write a sql function to get the
> max
On Fri, Jun 03, 2011 at 12:27:35AM -0400, Robert Haas wrote:
> But in this case I really don't quite understand why you don't like
> the proposed behavior. AIUI, the case we're talking about is a
> function foo that takes, say, anyarray, and returns anyarray.
>
> Now, let us say we attempt to cal
On 02.06.2011 21:58, Alexey Klyukin wrote:
Hello,
We've recently come across the task of estimating the size of shared memory
required for PostgreSQL to start. This comes from the problem of validating
postgresql.conf files
(http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php), i.e
Hello, Andrew.
You wrote:
AC> On 6/2/2011 11:02 AM, Alvaro Herrera wrote:
>> Excerpts from Andrew Chernow's message of jue jun 02 10:12:40 -0400 2011:
>>
Andrew, why we have PQmakeEmptyPGresult, PQcopyResult,
PQsetResultAttrs, PQsetvalue and PQresultAlloc in this case? Of course
th
101 - 124 of 124 matches
Mail list logo
