---
Amit jain wants to stay in better touch using some of Google's coolest new
products.
If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-5c01992273-323d9fccf7-055df22a98d1c84d
You'll need to click t
---
Amit jain wants to stay in better touch using some of Google's coolest new
products.
If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-5c01992273-5c5916c841-05e987d31c258e4c
You'll need to click t
Hi guys any updates on this? Pinging you just so that we do not forget
it in the heap of mails in our inboxes.
Best regards,
On Feb 3, 2008 8:40 AM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Oleg Bartunov wrote:
> > On Sat, 2 Feb 2008, Gurjeet Singh wrote:
> >
> >> Hi All,
> >>
> >>I
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Nevertheless, I think there's something interesting missing here, which
> is a sort of strftime's %c format string.
Perhaps, but let us please not cram random non-Oracle-compatible stuff
into to_date/to_char. Those have a charter already.
Tom Lane wrote:
> "Gevik Babakhani" <[EMAIL PROTECTED]> writes:
> >> Surely it should be the inverse of the solution for output,
> >> eg TMMon selects localized input.
>
> > Of cource. But how would TM enforce a localized formatting. (perhaps I am
> > off 2:10 am...)
> > Lets say I have en_U
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I don't really buy the double patching argument. Back patching becomes
> more difficult when there has been significant code drit, but we surely
> don't expect that much drift in the next week or two. Back patching when
> there has been no code drift
"Gevik Babakhani" <[EMAIL PROTECTED]> writes:
>> Surely it should be the inverse of the solution for output,
>> eg TMMon selects localized input.
> Of cource. But how would TM enforce a localized formatting. (perhaps I am
> off 2:10 am...)
> Lets say I have en_US database but the dates I am
Peter Eisentraut wrote:
Tom Lane wrote:
As best I recall, the immediate branch after 8.2 was the exception not
the rule --- we've usually waited longer than that.
8.2, 8.1, and 8.0 were branched off the x.y.0 release tag. 7.4 was branched
at rc1, 7.3 was branched at beta4, 7.2 was
> Surely it should be the inverse of the solution for output,
> eg TMMon selects localized input.
Of cource. But how would TM enforce a localized formatting. (perhaps I am
off 2:10 am...)
Lets say I have en_US database but the dates I am trying to format is nl_NL.
If I am not mistaking SET L
"Gevik Babakhani" <[EMAIL PROTECTED]> writes:
> What do we think about a solution that would be like:
> 1. Add an extra (optional) parameter to to_date and to_timestamp which would
> indicate the locale we are trying to parse.
Surely it should be the inverse of the solution for output, eg TMMon
Hi,
I would like to start a discussion for a solution regarding this item.
At this moment these functions only accept English month/day names due
formatting.c:172:months_full[] and datetime.c:53-58 months[], days[].
The values are predetermined. (hardcoded sounds bahhh...)
What do we think about
On Mon, 2008-02-04 at 20:50 +, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > Also, they use "period" to mean interval, and "interval" to mean
> > duration -- which is wrong, in my opinion; interval already has a well-
> > defined mathematical meaning.
>
> Agreed, but that mistake actually
Tom Lane wrote:
> As best I recall, the immediate branch after 8.2 was the exception not
> the rule --- we've usually waited longer than that.
8.2, 8.1, and 8.0 were branched off the x.y.0 release tag. 7.4 was branched
at rc1, 7.3 was branched at beta4, 7.2 was branched at final release, 7.1 was
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm thinking of adding an extra parameter onto every call to
> LockBuffer() and LWLockAcquire() to explain the reason for the lock
> request.
Maybe I'm missing something, but I don't see what this would buy us,
except for being able to track which call sit
On Mon, 2008-02-04 at 16:48 -0500, Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > That shared memory of the children should not be added to the size
> > of the parent process multiple times regardless of if something's
> > an essential process or not.Since those bytes are shared, i
On Mon, 2008-02-04 at 13:40 -0800, Jeff Davis wrote:
> Did you read my post on LKML?
Nice post, BTW. I think you should just submit a patch. There was a
similar problem sometime recently with counting mapped files incorrectly
towards the dirty ratio, so your issue has both clear error and
similar
On Mon, 2008-02-04 at 13:31 -0800, Ron Mayer wrote:
> Alvaro Herrera wrote:
> > Yeah, the only way to improve the OOM problem would be to harass the
> > Linux developers to tweak badness() so that it considers the postmaster
> > to be an essential process rather than the one to preferentially kill.
Ron Mayer <[EMAIL PROTECTED]> writes:
> That shared memory of the children should not be added to the size
> of the parent process multiple times regardless of if something's
> an essential process or not.Since those bytes are shared, it
> seems such bytes should only be added to the badness on
On Mon, 2008-02-04 at 20:06 +, Simon Riggs wrote:
> We make no attempt to limit our overall memory usage. We limit
> individual sessions by default, but don't prevent them from increasing
> that allocation as they choose. We don't try to reallocate memory once
> it has finished being used.
>
Alvaro Herrera wrote:
> Yeah, the only way to improve the OOM problem would be to harass the
> Linux developers to tweak badness() so that it considers the postmaster
> to be an essential process rather than the one to preferentially kill.
Wouldn't the more general rule that Jeff Davis pointed out
Heikki Linnakangas wrote:
> Jeff Davis wrote:
>> Also, they use "period" to mean interval, and "interval" to mean
>> duration -- which is wrong, in my opinion; interval already has a well-
>> defined mathematical meaning.
>
> Agreed, but that mistake actually originates from the SQL standard. The
Tom Lane wrote:
> > Gregory Stark wrote:
> >> I wonder how hard it would be to shove the clog into regular shared memory
> >> pages and let the clock sweep take care of adjusting the percentage of
> >> shared
> >> mem allocated to the clog versus data pages.
> My recollection is that we didn't d
Alvaro Herrera wrote:
Gregory Stark wrote:
I wonder how hard it would be to shove the clog into regular shared memory
pages and let the clock sweep take care of adjusting the percentage of shared
mem allocated to the clog versus data pages.
Hmm, this is an interesting idea. I wonder what wou
Simon Riggs wrote:
> On Mon, 2008-02-04 at 20:03 +, Gregory Stark wrote:
>
> > I wonder how hard it would be to shove the clog into regular shared
> > memory pages and let the clock sweep take care of adjusting the
> > percentage of shared mem allocated to the clog versus data pages.
>
> Ther
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> I wonder how hard it would be to shove the clog into regular shared memory
>> pages and let the clock sweep take care of adjusting the percentage of shared
>> mem allocated to the clog versus data pages.
> Hmm, this is an interes
On Mon, 2008-02-04 at 20:03 +, Gregory Stark wrote:
> I wonder how hard it would be to shove the clog into regular shared
> memory pages and let the clock sweep take care of adjusting the
> percentage of shared mem allocated to the clog versus data pages.
There is a reason that's not been don
Jeff Davis wrote:
Also, they use "period" to mean interval, and "interval" to mean
duration -- which is wrong, in my opinion; interval already has a well-
defined mathematical meaning.
Agreed, but that mistake actually originates from the SQL standard. The
SQL INTERVAL data type is really a du
On Mon, 2008-02-04 at 15:31 -0500, Tom Lane wrote:
> I cannot see any way of restricting global memory
> consumption that won't hurt performance and flexibility.
We've discussed particular ways of doing this previously and not got
very far, its true. I think we need to separate problem identifica
Gregory Stark wrote:
> I wonder how hard it would be to shove the clog into regular shared memory
> pages and let the clock sweep take care of adjusting the percentage of shared
> mem allocated to the clog versus data pages.
Hmm, this is an interesting idea. I wonder what would happen if we let
Tom Lane wrote:
> Frankly, I'm entirely unpersuaded. It will do zilch to improve the OOM
> problem, and I cannot see any way of restricting global memory
> consumption that won't hurt performance and flexibility.
Yeah, the only way to improve the OOM problem would be to harass the
Linux develope
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2008-02-04 at 11:38 -0800, Jeff Davis wrote:
>> I am missing something, can you elaborate? What is postgresql doing
>> wrong?
> We make no attempt to limit our overall memory usage. We limit
> individual sessions by default, but don't prevent them
On Mon, 2008-02-04 at 11:38 -0800, Jeff Davis wrote:
> On Mon, 2008-02-04 at 19:29 +, Simon Riggs wrote:
> > On Mon, 2008-02-04 at 10:57 -0800, Jeff Davis wrote:
> >
> > > I tried bringing this up on LKML several times (Ron Mayer linked to one
> > > of my posts: http://lkml.org/lkml/2007/2/9/2
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> We still have a higher than desirable variability in response times and
> I'm looking at possible causes.
I agree we have a problem with this. My feeling is that the problems have more
to do with higher level things like stats being toasted, or checkpoi
On Sun, 2008-02-03 at 15:56 -0500, Greg Smith wrote:
> On Sun, 3 Feb 2008, Jeff Davis wrote:
>
> > I think what he means by "bitemporal" is what CJ Date, et al., refer to
> > as "fully temporal" (as opposed to semi-temporal), that is, dealing with
> > time intervals rather than time points.
>
> B
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> To avoid double-patching effort. I think we'll branch fairly shortly,
>> like in a week or so, but right now it'd mostly just create make-work
>> for committers.
> Was that a big problem last release?
Well, basically this happens at
On Mon, 2008-02-04 at 19:29 +, Simon Riggs wrote:
> On Mon, 2008-02-04 at 10:57 -0800, Jeff Davis wrote:
>
> > I tried bringing this up on LKML several times (Ron Mayer linked to one
> > of my posts: http://lkml.org/lkml/2007/2/9/275). If anyone has an inside
> > connection to the linux develo
On Mon, 2008-02-04 at 10:57 -0800, Jeff Davis wrote:
> I tried bringing this up on LKML several times (Ron Mayer linked to one
> of my posts: http://lkml.org/lkml/2007/2/9/275). If anyone has an inside
> connection to the linux developer community, I suggest that they raise
> this issue.
>
> If y
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Is there a checklist somewhere that contains all the steps to be taking
> in making a release? If so, where if at all is it published? If not,
> shouldn't there be?
src/tools/RELEASE_CHANGES enumerates the stuff that we typically worry
about before wr
On Fri, 2008-02-01 at 19:08 -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > This page
> > http://linux-mm.org/OOM_Killer
>
> Egad. Whoever thought *this* was a good idea should be taken out
> and shot:
+1
> /*
> * Processes which fork a lot of child proc
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
Andrew Dunstan wrote:
I don't see the branch point for REL8_3_STABLE - has that been done? I
thought it would happen at the same time as we tagged the release.
No, we will branch later.
We've got various facilities now for looking at LWLock waits, but I'd
like to have more information about the *reasons* for lock waits.
I know its possible to get backtraces in Dtrace at various tracepoints
but that can be fairly hard to interpret.
I'm thinking of adding an extra parameter onto
On Mon, 2008-02-04 at 13:27 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > In heapgetpage() we hold the buffer locked while we look for visible
> > tuples.
>
> It's a share lock though.
Which conflicts with write locks.
> Do you have any direct proof that this
> behavior
Simon Riggs <[EMAIL PROTECTED]> writes:
> In heapgetpage() we hold the buffer locked while we look for visible
> tuples.
It's a share lock though. Do you have any direct proof that this
behavior is as nasty as you claim?
regards, tom lane
---(end
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Andrew Dunstan wrote:
>>> I don't see the branch point for REL8_3_STABLE - has that been done? I
>>> thought it would happen at the same time as we tagged the release.
>>
>> No, we will branch later.
> We need this to be create
Is there a checklist somewhere that contains all the steps to be taking
in making a release? If so, where if at all is it published? If not,
shouldn't there be?
cheers
andrew
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
On Mon, Feb 04, 2008 at 09:44:17AM -0600, Roberts, Jon wrote:
> If you guys develop Merge for PostgreSQL, I highly suggest putting an
> "order by" statement in the syntax so if the source has duplicates, it
> will insert the first one and then do subsequent updates.
I don't think it would meet the
In heapgetpage() we hold the buffer locked while we look for visible
tuples. That works well in most cases since the visibility check is fast
if we have status bits set. If we don't have visibility bits set we have
to do things like scan the snapshot and confirm things via clog lookups.
All of tha
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Stephen Frost
> Sent: Monday, February 04, 2008 8:28 AM
> To: Amit jain
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Merge condition in postgresql
>
> * Amit jain ([EMAIL
* Amit jain ([EMAIL PROTECTED]) wrote:
> I am currently migrating database from ORACLE to postgresql but i am stucked
> up at one point while creating procedures.
> There is a query which has used oracle MERGE condition so how can i change
> this query as per posgresql. kindly suggest me its very u
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
... OOM_Killer
Egad. Whoever thought *this* was a good idea should be taken out
and shot:
If I read this right, http://lkml.org/lkml/2007/2/9/275 even the
shared memory is counted many times (once per child) for the
parent
Pretty neat. It may be a possible alternative to the use of
the hash index in some applications.
Cheers,
Ken
On Sun, Feb 03, 2008 at 07:13:23PM -0800, Gurjeet Singh wrote:
> Hi All,
>
> I have wanted to create a reverse key index for some time now, and it
> seems that an evening of reading a
Hello,
Omar Bettin wrote:
Probably I am on the wrong place but for me NULL on numbers means 0 or
ZERO.
I know about standards...
You can easily convert NULLs to 0 in your queries - read about COALESCE
function
http://www.postgresql.org/docs/8.0/interactive/functions-conditional.html.
Comp
On Fri, 2008-02-01 at 19:08 -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > This page
> > http://linux-mm.org/OOM_Killer
>
> Egad. Whoever thought *this* was a good idea should be taken out
> and shot:
>
> The independent memory size of any child (except a kernel thre
Le dimanche 03 février 2008, Greg Smith a écrit :
> On Sun, 3 Feb 2008, Jeff Davis wrote:
> > I think what he means by "bitemporal" is what CJ Date, et al., refer to
> > as "fully temporal" (as opposed to semi-temporal), that is, dealing with
> > time intervals rather than time points.
>
> >> I wou
Hello All,
I am currently migrating database from ORACLE to postgresql but i am stucked
up at one point while creating procedures.
There is a query which has used oracle MERGE condition so how can i change
this query as per posgresql. kindly suggest me its very urgent.
55 matches
Mail list logo