Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> True. On the other hand, if we issue writes in essentially random order,
> we might fill the kernel buffers with random blocks and the kernel needs
> to flush them to disk as almost random I/O. If we did the writes in
> groups, the kernel has bett
On Sun, Jun 10, 2007 at 09:56:44PM +0200, Magnus Hagander wrote:
> AFAIK, most other compilers delete their output if it's not valid. Is
> there any particular reason why ecpg doesn't do this?
No, not really. Sometimes it comes handy to see what was already
processed, but you're right, it's not wh
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > FWIW this has been fixed in 8.3, you can drop the item from the 8.4
> > queue. Thanks.
>
> There are a couple of other things on that page that seem already
> applied, for instance hashing for numeric and an early form of the
> seq
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> FWIW this has been fixed in 8.3, you can drop the item from the 8.4
> queue. Thanks.
There are a couple of other things on that page that seem already
applied, for instance hashing for numeric and an early form of the
seq scan ringbuffer patch.
While
Removed.
---
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
> >
> > This has been saved for the 8.4 release:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> FWIW this has been fixed in 8.3, you can d
Bruce Momjian escribió:
>
> This has been saved for the 8.4 release:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
FWIW this has been fixed in 8.3, you can drop the item from the 8.4
queue. Thanks.
> ---
Every so often, buildfarm member skylark reports a "StartDb:2" failure,
as for instance here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-06-10%2023:00:01
but the logs contain no trace of any actual failure. What's happening,
and why is the buildfarm failing to record any use
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Sounds good. The cost is paid by the WHERE CURRENT OF query, not as an
> overhead on all cursors. Sounds like it will still be very fast too.
Yeah, there's zero added cost in the existing code paths, and the lookup
isn't really that expensive.
> Presuma
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Nick Barr <[EMAIL PROTECTED]> writes:
> > I was looking to start development on the following TODO entry.
> > Add a separate TRUNCATE permission
>
> Is there actually a use-case for that? It seems like mostly pointless
> complication to me. (Note that in t
On Sat, 2007-06-09 at 16:25 -0400, Tom Lane wrote:
> What I think we could do instead is not change any existing behavior of
> cursor declarations, but when WHERE CURRENT OF is used, dig through the
> execution node tree of the cursor to find the scan node for the target
> table.
Sounds good. Th
On Sun, 2007-06-10 at 20:48 +0200, [EMAIL PROTECTED] wrote:
> >
> > > My questions was: why don't we start the archiving *BEFORE* postmaster to
> > > make room.
> >
> > The archiver is executed from the postmaster, so thats not possible.
> >
> I'm aware of that, my point is maybe the archiver doesn
When working on the ecpg regression stuff things, it's the first time
I've actually used ecpg. And I notice now that it leaves incomplete and
broken files around when it fails. For example, I currently get:
parser.pgc:26: ERROR: syntax error at or near "NULLS"
when building. I have to investig
Jim C. Nasby wrote:
On Thu, Jun 07, 2007 at 10:16:25AM -0400, Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Thinking about this whole idea a bit more, it occured to me that the
current approach to write all, then fsync all is really a historical
artifact of the fact that we us
Hi Simon,
Sorry for replying so late...
On Fri, 8 Jun 2007, Simon Riggs wrote:
> Date: Fri, 08 Jun 2007 20:16:35 +0100
> From: Simon Riggs <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] little PITR annoyance
>
> Hi Olivier,
>
> On Fri, 2007-06-08 at
On Sun, Jun 10, 2007 at 12:50:11PM -0400, Greg Smith wrote:
> This is all true, but the reality here is that people in such a situation
> are usually flat-out violating their corporate policy by posting to the
> list at all from inside this kind of company.
We don't know that in advance, and
Greg Smith wrote:
On Sat, 9 Jun 2007, Bruce Momjian wrote:
If enough people do that, it might coerce people to avoid them, and
perhaps we could put something in the FAQ about it.
You should just say flat-out that the terms of the mailing list are
incompatible with confidentiality and similar
Bruce Momjian wrote:
I know we have talked about how to avoid legal email signatures on this
list. One idea would be for a small percentage of our users to ignore
emails with a legal signature. I know I am less likely to reply to such
an email.
Bah Bruce come on. The people that are sendi
On Sun, 10 Jun 2007, Andrew Sullivan wrote:
Moreover, people who are in such environments are often prevented from
visiting gmail, hotmail, or the other likely suspects in order to send
their messages in circumvention of corporate policy.
This is all true, but the reality here is that people
On Sat, 9 Jun 2007, Bruce Momjian wrote:
If enough people do that, it might coerce people to avoid them, and
perhaps we could put something in the FAQ about it.
You should just say flat-out that the terms of the mailing list are
incompatible with confidentiality and similar legal disclaimers
On Sat, Jun 09, 2007 at 06:14:00PM -0400, Bruce Momjian wrote:
> I know we have talked about how to avoid legal email signatures on this
> list. One idea would be for a small percentage of our users to ignore
> emails with a legal signature. I know I am less likely to reply to such
> an email.
T
20 matches
Mail list logo