On Fri, 2007-12-14 at 18:42 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> How do people feel about applying this to 8.3, rather than holding it?
> One possible objection is that we're past string freeze, but I noted
> Peter doing some message editorializing as recently as toda
On Fri, 2007-12-14 at 18:22 -0500, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > By modifying COPY: COPY IGNORE ERRORS or some such would instruct COPY
> > to drop (and log) rows that contain malformed data. That is, rows with
> > too many or too few columns, rows that result in con
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
> Hi,
> I already made a discussion about it. We can view the Logical I/Os. If
> we enable the log_statement_stats in the conf file and apply the following
> patch, it is possible. But putting it in Explain analyze makes more sense to
> m
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> On Dec 14, 2007 6:42 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
How do people feel about applying this to 8.3, rather than holding it?
>
>> I think it would have been better to apply before beta. We would have
> Read-Only Tables
>
> Postgres supports the concept of freezing tuples, so they can live
> forever within the database without needing further writes. Currently
> there is no command that will guarantee that a table has been completely
> frozen. This makes it difficult to reliably
I was going to say that I'm really only interested in physical I/O. Logical
> I/O which is satisfied by the kernel cache is only marginally interesting
> and
> buffer fetches from Postgres's shared buffer is entirely uninteresting
> from
> the point of view of trying to figure out what is slowing d
Alvaro Herrera wrote:
> Magnus Hagander wrote:
>> On Thu, Dec 13, 2007 at 09:55:33AM -0300, Alvaro Herrera wrote:
>>> Many of these are nonsensical -- we know this is not a device, nor
>>> network access. Still there is more than one possibility, and I don't
>>> know which ones should be really ac
Magnus Hagander wrote:
Alvaro Herrera wrote:
Magnus Hagander wrote:
On Thu, Dec 13, 2007 at 09:55:33AM -0300, Alvaro Herrera wrote:
Many of these are nonsensical -- we know this is not a device, nor
network access. Still there is more than one possibility, and I don't
know wh
Hello
I am thinking about global temporary tables. Current problem is
frequent modification some system tables pg_class, pg_attribute and
others. We need merge metadata for real tables and for temporary
tables. Currently we use metadata of temp tables like metadata of
normal tables with known prob
Gokulakannan Somasundaram wrote:
I was going to say that I'm really only interested in physical I/O. Logical
I/O which is satisfied by the kernel cache is only marginally interesting
and
buffer fetches from Postgres's shared buffer is entirely uninteresting
from
the point of view of trying to fi
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Alvaro Herrera wrote:
>>> Magnus Hagander wrote:
>>>
>>> Note that their behavior on finding SHARING_VIOLATION or LOCK_VIOLATION
>>> is to retry forever until the error goes away, on the theory that the
>>> antivirus/bac
Hi everybody,
I' m work on a software to create automatic webservices for stored
procedure in any language.
It's almost like the explain above:
have one table pg_plwebservice
Have one sp hello, develope in any languages like sql, plpgsql(trusted or
untrusted)like for example.
The DBA chec
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> Interesting. Maybe forever is going a bit too far, but retrying for
>> seconds or so.
> I think looping forever is the right thing. Having a fixed timeout just means
> Postgres will break sometimes instead
Hey, Ivo,
> I' m work on a software to create automatic webservices for stored
> procedure in any language.
Seems like the new XML and XLST support should fit in here somewhere.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
Hello Josh,
the XML and XLST are data presentation only?
the idea is provide some like one Http request where I can post data for a
Stored procedure and receive one Http response using WSDL description and
SOAP transport to implement the web service.
Where can I find more info about this new fe
On Tue, 2007-12-11 at 19:11 -0500, Greg Smith wrote:
> I'm curious what you feel is missing that pgloader doesn't fill that
> requirement: http://pgfoundry.org/projects/pgloader/
For complicated ETL, I agree that using an external tool makes the most
sense. But I think there is still merit in ad
On 16/12/2007, Neil Conway <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-12-11 at 19:11 -0500, Greg Smith wrote:
> > I'm curious what you feel is missing that pgloader doesn't fill that
> > requirement: http://pgfoundry.org/projects/pgloader/
>
> For complicated ETL, I agree that using an external too
Aftab Hussain wrote:
> In general, \d command is working perfectly for database objects.
>
> For sequences, I think the current \d some_sequence command's output is
> displaying information which does not help the end user very much. Also
> isn't the newly display information (same as information
18 matches
Mail list logo
