On Wed, 21 Feb 2007 14:59, Greg Smith wrote:
> On Tue, 20 Feb 2007, Tom Lane wrote:
> > A smaller problem is that this forces people to incur a gettimeofday
> > call for every message logged
>
> I'm stumped trying to think of an application that would require importing
> the logs into a database to
On Tue, 20 Feb 2007, Tom Lane wrote:
A smaller problem is that this forces people to incur a gettimeofday
call for every message logged
I'm stumped trying to think of an application that would require importing
the logs into a database to analyze them, but not need the timestamp.
I'd expect
now applied.
cheers
andrew
Bruce Momjian wrote:
Uh, I haven't seen this applied yet.
---
Andrew Dunstan wrote:
Here's a patch along the same lines as the fix for plperl committed
earlier today, that allows passing t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > + CFLAGS="$CFLAGS -DPROFILE_PID_DIR -pg ${PROFILE_CFLAGS}"
>
> Kindly use AC_DEFINE instead of random -D in CFLAGS (which is the wrong
> place for -D anyway). Also, what exactly is the point here of
> PROFILE_CFLAGS? I though
On Wed, 21 Feb 2007 12:08, Tom Lane wrote:
> "FAST PostgreSQL" <[EMAIL PROTECTED]> writes:
> > - The log output will be in COPY format and will include the following
> > information, irrespective of the log_line_prefix setting.
> > ( timestamp_with_milliseconds, timestamp, username, databasename,
"FAST PostgreSQL" <[EMAIL PROTECTED]> writes:
> - The log output will be in COPY format and will include the following
> information, irrespective of the log_line_prefix setting.
> ( timestamp_with_milliseconds, timestamp, username, databasename,
> sessionid, host_and_port, host, proc_id, comm
Ok. Summarizing the key changes required on my patch, based on the
discussions so far are :
- The log_destination will include a new option 'sql'. This can be given with
other combinations of stderr, syslog or eventlog.
- The sql logs will be written in log_directory in a file log_filename.
I have implemented your ideas for checking BLCKSZ >= 1024, and having
initdb adjust shared buffers checks based on BLCKSZ.
Patch attached and applied.
---
Peter Eisentraut wrote:
> The smallest BLCKSZ that you can compile i
On Tue, 20 Feb 2007, Bruce Momjian wrote:
>
> The most recent version of this patch has been added.
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committer
As a result of discussion with Peter, I provide modified patch for
xpath_array() with namespaces support.
The signature is:
_xml xpath_array(text xpathQuery, xml xmlValue[, _text namespacesBindings])
The third argument is 2-dimensional array defining bindings for
namespaces. Simple examples:
x
Are there any performance numbers on this?
---
ITAGAKI Takahiro wrote:
> The attached is a patch to define O_DIRECT by ourselves on Windows,
> and to map O_DIRECT to FILE_FLAG_NO_BUFFERING.
>
> There will be a consistency i
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Je
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Jo
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Pa
Oops.! That one got away. I'll work on it tonight.
cheers
andrew
Bruce Momjian wrote:
Uh, I haven't seen this applied yet.
---
Andrew Dunstan wrote:
Here's a patch along the same lines as the fix for plperl committed
The most recent version of this patch has been added.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
-
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Pa
Uh, I haven't seen this applied yet.
---
Andrew Dunstan wrote:
>
> Here's a patch along the same lines as the fix for plperl committed
> earlier today, that allows passing type aliases to spi_prepare as well
> as types na
Please find attached a patch which provides for logging in the event that -k
is unable to clean up an old WAL file. Also make the failed to remove file
error message consistant for the trigger file.
--
Darcy Buskermolen
Command Prompt, Inc.
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Let's change it to a plain ColId, so you get a syntax error if you try
>> that.
> Should we perhaps support a variant that allows a string as opposed to
> an identifier as the name?
I think that'd just confuse matters. You can doub
Tom Lane wrote:
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
I'll save the full rant for my blog :), but wanted to submit this documentation
patch for this listen gotcha that's been bugging me for a while. I'd like
to see LISTEN and NOTIFY changed to use a simple text string, but until
Thanks. I have updated the documentation with the attached patch, and
backpatched it to 8.2.X.
---
Kirill Simonov wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2942
> Logged by: Kir
Greg Sabino Mullane said:
> I'll save the full rant for my blog :), but wanted to submit this
> documentation patch for this listen gotcha that's been bugging me
> for a while.
Why not just change LISTEN, NOTIFY, and UNLISTEN to only accept an unqualified
identifier?
-Neil
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> I'll save the full rant for my blog :), but wanted to submit this
> documentation
> patch for this listen gotcha that's been bugging me for a while. I'd like
> to see LISTEN and NOTIFY changed to use a simple text string, but until then,
> I t
I'll save the full rant for my blog :), but wanted to submit this documentation
patch for this listen gotcha that's been bugging me for a while. I'd like
to see LISTEN and NOTIFY changed to use a simple text string, but until then,
I think we should probably warn about the chopping off of the l
Pavel Stehule wrote:
xsd knows datetime type. You can inherit it, and then you have to
respect it. You can do own type, but you lost information, and any
general scripts don't understand. I don't know why xsd doesn't iso
format, but its simply fact. Please read this discussion:
http://for
Simon Riggs wrote:
>
> I've used the heap_sync() API call to improve performance of CLUSTER by
> avoiding WAL when archive_command is not set.
Cool. I noticed that the SGML seems broken here:
> --- 908,925
> will perform more slowly when archive_command
> is set, as a result of
From: Andrew Dunstan <[EMAIL PROTECTED]>
To: Peter Eisentraut <[EMAIL PROTECTED]>
CC: Pavel Stehule <[EMAIL PROTECTED]>,
pgsql-patches@postgresql.org
Subject: Re: [PATCHES] correct format for date, time, timestamp for XML
functionality
Date: Tue, 20 Feb 2007 11:37:31 -0500
Peter Eisentrau
Peter Eisentraut wrote:
Am Dienstag, 20. Februar 2007 16:54 schrieb Andrew Dunstan:
I'm not sure that we are actually guaranteeing anything about XML
validity against any schema or DTD, are we?
That is the "xmlschema" part of table_to_xmlschema() et al. recently
discussed. That entir
Am Dienstag, 20. Februar 2007 16:54 schrieb Andrew Dunstan:
> I'm not sure that we are actually guaranteeing anything about XML
> validity against any schema or DTD, are we?
That is the "xmlschema" part of table_to_xmlschema() et al. recently
discussed. That entire functionality hinges on produc
On Tue, Feb 20, 2007 at 04:32:28PM +0100, Pavel Stehule wrote:
>
> I am sorry. I reported this two times before. This patch is related only
> for xml functionality. XSD datestyle is only one internal constant.
There
> are no new datestyle (I hope so can be usefull). My patch is small bug
fix
>
I'm not sure that we are actually guaranteeing anything about XML validity
against any schema or DTD, are we?
what?
ofcourse you cannot garant validity against any schema. But mapping
functions are standardised and expect xsd. And I what I can meet protocols
based on xml, they respect xsd eve
On Tue, Feb 20, 2007 at 04:32:28PM +0100, Pavel Stehule wrote:
>
> I am sorry. I reported this two times before. This patch is related only
> for xml functionality. XSD datestyle is only one internal constant. There
> are no new datestyle (I hope so can be usefull). My patch is small bug fix
>
Pavel Stehule wrote:
Pavel Stehule wrote:
Hello,
this patch ensures independency datetime fields on current datestyle
setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust
same to USE_ISO_DATESTYLE. Differences are for timestamp:
ISO: -mm-dd hh24:mi:ss
XSD: -mm-ddThh
On Tue, Feb 20, 2007 at 08:31:45PM +0530, Pavan Deolasee wrote:
> I see your point, but as you mentioned do we really care ? The chain
> needs to be broken so that the intermediate DEAD tuples can be
> vacuumed. We can't vacuum them normally because they could
> be a part of live HOT-update chain.
Pavel Stehule wrote:
Hello,
this patch ensures independency datetime fields on current datestyle
setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust same
to USE_ISO_DATESTYLE. Differences are for timestamp:
ISO: -mm-dd hh24:mi:ss
XSD: -mm-ddThh24:mi:ss
Pavel,
Pavel Stehule wrote:
Hello,
this patch ensures independency datetime fields on current datestyle
setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust
same to USE_ISO_DATESTYLE. Differences are for timestamp:
ISO: -mm-dd hh24:mi:ss
XSD: -mm-ddThh24:mi:ss
Pavel,
I
On 2/20/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
>
> "Recently dead" means "still live to somebody", so those tids better not
> change either. But I don't think that's what he meant. I'm more
> worried about the deadlock possibilities inherent in trying to upgrade a
> buffe
On 2/20/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> ... Yes. The HOT-updated status of the root and all intermediate
> tuples is cleared and their respective ctid pointers are made
> point to themselves.
Doesn't that destroy the knowledge that they for
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> this patch ensures independency datetime fields on current datestyle
> setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust same
to
> USE_ISO_DATESTYLE. Differences are for timestamp:
> ISO: -mm-dd hh24:mi:ss
> XSD: -mm-ddTh
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Pavan Deolasee wrote:
> >> When following a HOT-update chain from the index fetch, if we notice that
> >> the root tuple is dead and it is HOT-updated, we try to prune the chain to
> >> the smallest possible length. To do that, the sha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Pavan Deolasee wrote:
>> When following a HOT-update chain from the index fetch, if we notice that
>> the root tuple is dead and it is HOT-updated, we try to prune the chain to
>> the smallest possible length. To do that, the share lock is upgraded to an
Pavan Deolasee wrote:
> On 2/20/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > Pavan Deolasee wrote:
> > > When following a HOT-update chain from the index fetch, if we notice
> > that
> > > the root tuple is dead and it is HOT-updated, we try to prune the chain
> > to
> > > the smallest poss
On 2/20/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
> When following a HOT-update chain from the index fetch, if we notice
that
> the root tuple is dead and it is HOT-updated, we try to prune the chain
to
> the smallest possible length. To do that, the share lock is upgrad
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> this patch ensures independency datetime fields on current datestyle
> setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust same to
> USE_ISO_DATESTYLE. Differences are for timestamp:
> ISO: -mm-dd hh24:mi:ss
> XSD: -mm-ddThh24
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> ... Yes. The HOT-updated status of the root and all intermediate
> tuples is cleared and their respective ctid pointers are made
> point to themselves.
Doesn't that destroy the knowledge that they form a tuple chain?
While it might be that no one care
Pavan Deolasee wrote:
> When following a HOT-update chain from the index fetch, if we notice that
> the root tuple is dead and it is HOT-updated, we try to prune the chain to
> the smallest possible length. To do that, the share lock is upgraded to an
> exclusive lock and the tuple chain is followe
Hello,
this patch ensures independency datetime fields on current datestyle
setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust same to
USE_ISO_DATESTYLE. Differences are for timestamp:
ISO: -mm-dd hh24:mi:ss
XSD: -mm-ddThh24:mi:ss
I found one link about this topic:
Hi,
I started working on my previous patch, encouraged
by the fact that it became a wishlist item for 8.3. :-)
The changes in this version are:
- Refreshed to almost current (5 days old)
CVS version of 8.3 devel
- The original SERIAL pseudo type is left alone,
you _have to_ spell out GENERATED
On 2/20/07, Hannu Krosing <[EMAIL PROTECTED]> wrote:
Ühel kenal päeval, T, 2007-02-20 kell 12:08, kirjutas Pavan Deolasee:
What do you do, if there are no live tuples on the page ? will this
un-HOTify the root and free all other tuples in HOT chain ?
Yes. The HOT-updated status of the root
On 2/20/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Of course, the other side of that coin is that syslog is known to drop
messages altogether under sufficient load. (At least on some platforms;
dunno about yours.)
Yes I know. That's one of the reason why I asked for the bahaviour of
7.4 log_durat
51 matches
Mail list logo
