> > (1) we've always been laxer about contrib than the core code,
>
> While that appears to be true, I think
>
> (a) there is no technical reason allowing us to do that, and
> (b) most people don't seem to like it.
>
I will even go so far as to say there are technical reasons not to do it. I
> > Right. My thought is still that if it isn't good enough for core, it
> > shouldn't be in contrib. If it *is* good enough, and we want it, we
> > should accept that it came in long after freeze and put it in core
> > anyway. If it *isn't*, then it should be on pgfoundry and be moved into
> > co
> In hindsight, all these ecpg changes should have been made between beta1
> and beta2 when we have time to deal with the fallout, not right before
> beta1.
>
Or considered new features and held back for 8.4. Not picking on Michael, but
the resemblance to the /contrib discussion is striking. Ec
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see how timing has anything to do with this. You could have
> added it between beta1 and beta2 after sufficient hackers discussion.
Uh, it *was* after beta1.
regards, tom lane
---(end of broadca
Joshua D. Drake wrote:
> The docs since 7.3 have declared the money type deprecated.. that is an
> awful long time. Can we get some clarity on the issue?
>
IMHO it's not but it certainly need some more work on the storage
(numeric?) and locale part as already discussed.
--
Euler Taveira de
Jan Wieck wrote:
> On 10/8/2007 1:34 PM, Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> >> Marko Kreen wrote:
> >>> Because of the bad timing it would have been -core call anyway
> >>> whether it gets in or not so Jan asked -core directly. That's
> >>> my explanation about what
Tatsuo Ishii wrote:
> > Tatsuo Ishii wrote:
> > > > > More question. Who is in charge of updating HISTORY? I see no commit
> > > > > messages for this.
> > > >
> > > > It is a generated file.
> > >
> > > I mean release.sgml.
> >
> > Tom and others made commits to this and we will update it again
> Tatsuo Ishii wrote:
> > > > More question. Who is in charge of updating HISTORY? I see no commit
> > > > messages for this.
> > >
> > > It is a generated file.
> >
> > I mean release.sgml.
>
> Tom and others made commits to this and we will update it again before
> final.
Did it? I see nothin
Tatsuo Ishii wrote:
> > > More question. Who is in charge of updating HISTORY? I see no commit
> > > messages for this.
> >
> > It is a generated file.
>
> I mean release.sgml.
Tom and others made commits to this and we will update it again before
final.
--
Bruce Momjian <[EMAIL PROTECTED]>
I had a thought a week ago. If we update the time zone database for
future dates, and you have a future date/time stored, doesn't the time
change when the time zone database changes.
For example if I schedule an appointment in New Zealand for 10:00a and
we change the time zone database so that da
On Mon, 8 Oct 2007 20:02:56 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> On Mon, 8 Oct 2007 22:52:23 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > Joshua D. Drake wrote:
> > -- Start of PGP signed section.
> > > On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
> > > Bruce Momjian <[
Hello,
The docs since 7.3 have declared the money type deprecated.. that is an
awful long time. Can we get some clarity on the issue?
If it isn't deprecated cool, I will submit a patch to docs.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Su
On Mon, 8 Oct 2007 22:52:23 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
> -- Start of PGP signed section.
> > On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
> > Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > > Joshua D. Drake wrote:
> > > -- Start of PGP signed sectio
On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
> -- Start of PGP signed section.
> > On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
> > Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
>dering money is deprecated, is this really needed?
>
> We have
Joshua D. Drake wrote:
-- Start of PGP signed section.
> On Mon, 8 Oct 2007 22:42:57 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > Joshua D. Drake wrote:
> > -- Start of PGP signed section.
> > > On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
> > > Bruce Momjian <[EMAIL PROTECTED]> wrote:
On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > I noticed that if you create a dump on a database containing a
> > > money column and a certain locale, this dump is not restorable on
> > > a dat
Joshua D. Drake wrote:
-- Start of PGP signed section.
> On Mon, 8 Oct 2007 22:31:31 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > Tom Lane wrote:
> > > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > > I noticed that if you create a dump on a database containing a
> > > > money co
Gregory Stark wrote:
>
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > Asynchronous Commit allows some transactions to commit faster than
> > others, offering a trade-off between performance and durability for
> > specific transaction types only
>
> A lot of users will be confused about what a
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I noticed that if you create a dump on a database containing a money
> > column and a certain locale, this dump is not restorable on a database
> > with a different locale.
>
> We've been through this, no? If money doesn't print tha
Patch applied. Thanks. Your documentation changes can be viewed on our
web site shortly.
---
Brendan Jurd wrote:
> On 10/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > > Now t
In hindsight, all these ecpg changes should have been made between beta1
and beta2 when we have time to deal with the fallout, not right before
beta1.
---
Tom Lane wrote:
> This morning's ecpg patch certainly seems to have b
> > More question. Who is in charge of updating HISTORY? I see no commit
> > messages for this.
>
> It is a generated file.
I mean release.sgml.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL
Tatsuo Ishii wrote:
> More question. Who is in charge of updating HISTORY? I see no commit
> messages for this.
It is a generated file.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
> On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote:
> > Log Message:
> > ---
> > Added the Skytools extended transaction ID module to contrib as discussed
> > on CORE previously.
> >
> > This module offers transaction ID's containing the original XID and the
> > transaction epoch
Tom Lane wrote:
So I have no interest in trying to "retire" contrib. I think there's
room for debate about exactly which modules to include, of course.
I dont' think there's much call for retiring it. I think there is
interest in renaming it, as "contrib" is a wholly misleading
A Dimarts 09 Octubre 2007, Joshua D. Drake va escriure:
>
> Contrib is just a dead zone for the user populous. Most people consider
> it unsupported *stuff* with no particular purpose (regardless of the
> real meaning).
>
I think no visible documentation is the reason for this misconception and 8.
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Right. My thought is still that if it isn't good enough for core, it
> shouldn't be in contrib. If it *is* good enough, and we want it, we
> should accept that it came in long after freeze and put it in core
> anyway. If it *isn't*, then it should be on
On Mon, 08 Oct 2007 22:32:55 +0200
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> >> Marko Kreen wrote:
> >>> Because of the bad timing it would have been -core call anyway
> >>> whether it gets in or not so Jan asked -core directly.
On Mon, 08 Oct 2007 17:38:48 -0400
Robert Treat <[EMAIL PROTECTED]> wrote:
> On Monday 08 October 2007 16:29, Magnus Hagander wrote:
> > The whole contrib thing confuses a lot of users. Is it included, or
> > isn't it? IMHO, that distinction need to be clear, and I thought we
> > were working (if
Tom Lane wrote:
> (1) we've always been laxer about contrib than the core code,
While that appears to be true, I think
(a) there is no technical reason allowing us to do that, and
(b) most people don't seem to like it.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
--
On Monday 08 October 2007 16:29, Magnus Hagander wrote:
> The whole contrib thing confuses a lot of users. Is it included, or
> isn't it? IMHO, that distinction need to be clear, and I thought we
> were working (if not actively then at least passively) to "retire"
> contrib, moving things either t
On Mon, 2007-10-08 at 16:50 -0400, Alvaro Herrera wrote:
> palloc uses malloc underneath. My thought is to replace that with
> sbrk, mmap or something like that. Not very portable though, a lot of
> work, and most likely not nearly enough benefits.
Yeah, I agree this isn't likely to be a win in
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> The whole contrib thing confuses a lot of users. Is it included, or
> isn't it? IMHO, that distinction need to be clear, and I thought we
> were working (if not actively then at least passively) to "retire"
> contrib, moving things either to core or
Bruce Momjian escribió:
> Brendan Jurd wrote:
> > On 9/29/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > I think we need more than one person's request to add this function.
> >
> > Well, I don't expect it would get requested. Most DBAs would likely
> > look for the function in the docs, see
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Tom Lane wrote:
> > > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > > http://blogs.netapp.com/dave/2007/08/oracle-optimize.html
> > >
> > > Not a whole lot of technical content there, but pretty interesting
> > > nonetheless. I *think* that the iss
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > http://blogs.netapp.com/dave/2007/08/oracle-optimize.html
> >
> > Not a whole lot of technical content there, but pretty interesting
> > nonetheless. I *think* that the issues we're seeing are largely in the
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Marko Kreen wrote:
>>> Because of the bad timing it would have been -core call anyway
>>> whether it gets in or not so Jan asked -core directly. That's
>>> my explanation about what happened, obviously Jan and Tom have
>>> their own
Jan Wieck wrote:
> On 10/8/2007 1:34 PM, Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> Marko Kreen wrote:
Because of the bad timing it would have been -core call anyway
whether it gets in or not so Jan asked -core directly. That's
my explanation about what happe
> --- Original Message ---
> From: Andrew Dunstan <[EMAIL PROTECTED]>
> To: Marko Kreen <[EMAIL PROTECTED]>
> Sent: 08/10/07, 18:05:57
> Subject: Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended
> transactionID module to contrib as
>
>
> Surely there should at the very lea
On 10/8/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Marko Kreen wrote:
> > On 10/8/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> >> On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote:
> >>> Log Message:
> >>> ---
> >>> Added the Skytools extended transaction ID module to cont
On 10/8/2007 1:34 PM, Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Marko Kreen wrote:
Because of the bad timing it would have been -core call anyway
whether it gets in or not so Jan asked -core directly. That's
my explanation about what happened, obviously Jan and Tom have
their
Alvaro Herrera wrote:
> > Greg Smith wrote:
> > > On Thu, 27 Sep 2007, Tom Lane wrote:
> > >
> > >> Also, I spent a dreary two or three hours this afternoon examining the
> > >> CVS commit logs since 8.3 branched...I tried to post that info to
> > >> pgsql-docs but it broke the list's message size
Brendan Jurd wrote:
> On 9/29/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > I think we need more than one person's request to add this function.
>
> Well, I don't expect it would get requested. Most DBAs would likely
> look for the function in the docs, see it's not there and then just
> imple
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Marko Kreen wrote:
>> Because of the bad timing it would have been -core call anyway
>> whether it gets in or not so Jan asked -core directly. That's
>> my explanation about what happened, obviously Jan and Tom have
>> their own opinion.
> Right. I ca
Gokulakannan Somasundaram wrote:
> I am always slightly late in understanding things. Let me try
> to understand the use of DSM. It is a bitmap index on whether all the tuples
> in a particular block is visible to all the backends, whether a particular
> block contains tuples which are
Marko Kreen wrote:
> On 10/8/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>> On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote:
>>> Log Message:
>>> ---
>>> Added the Skytools extended transaction ID module to contrib as discussed
>>> on CORE previously.
>
> To explain the situat
Gokulakannan Somasundaram wrote:
Hi Heikki, I am always slightly late in understanding things. Let me
try to understand the use of DSM. It is a bitmap index on whether all
the tuples in a particular block is visible to all the backends,
whether a particular block contains tuples which are invisib
Marko Kreen wrote:
Now as you can read from recent disussion we had, we found out
that it would be *really* *really* cool if it would appear
in 8.3... Talk about last moment...
That discussion didn't happen on any list I read, so to me it just came
as a bolt from the blue.
Surely the
On 10/8/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote:
> > Log Message:
> > ---
> > Added the Skytools extended transaction ID module to contrib as discussed
> > on CORE previously.
To explain the situation, the public discussion
Hi Heikki,
I am always slightly late in understanding things. Let me try
to understand the use of DSM. It is a bitmap index on whether all the tuples
in a particular block is visible to all the backends, whether a particular
block contains tuples which are invisible to everyone. But i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I share your other concerns. This process certainly seems to have been
> less than transparent.
FWIW, Jan asked -core about a week ago whether it'd be okay to add this
code post-beta, and we concluded it would be okay on the grounds that
(1) we've alwa
Magnus Hagander wrote:
Or I could've missed the discussion on -hackers that actually took place -
in that case, just discard this message. but the only one I recall is
someone asking for pl/proxy to go in.
There was some discussion (subject: Provide 8-byte transaction IDs to
user leve
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> * mmap the WAL segments, instead of using the slru buffers.
>
> This one's almost certainly a nonstarter, for lack of any portable way
> to control when writes happen.
I think mlock and msync(MS_SYNC) oug
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> We mustn't write data pages before the WAL hits the disk, but we don't
> have any such limitation for WAL.
Um, you're right, I was remembering discussions about trying to mmap
data files. Still, googling "msync performance" leaves me full of
conc
On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote:
> Log Message:
> ---
> Added the Skytools extended transaction ID module to contrib as discussed
> on CORE previously.
>
> This module offers transaction ID's containing the original XID and the
> transaction epoch as a bigint valu
Tom Lane wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> * mmap the WAL segments, instead of using the slru buffers.
>
> This one's almost certainly a nonstarter, for lack of any portable way
> to control when writes happen.
For flushing, there's msync, which I believe is quite porta
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> * mmap the WAL segments, instead of using the slru buffers.
This one's almost certainly a nonstarter, for lack of any portable way
to control when writes happen.
regards, tom lane
---(end of broadc
On Mon, 2007-10-08 at 14:58 +0300, Hannu Krosing wrote:
> 1. get rid of indexes for TOAST tables
>
> instead of TOAST tuple id store CTID of first TOAST block directly, and
> use something like skip lists inside the TOAST block headers to access
> next TOAST tuples.
It should be possible to opti
Peter Eisentraut wrote:
Am Freitag, 28. September 2007 schrieb Nikolay Samokhvalov:
what should be returned for XML like "PostgreSQL
is a powerful, open source relational database system" if user
requests for text under "em" node? In XML world, the correct answer is
"PostgreSQL is a powerf
Ühel kenal päeval, E, 2007-10-08 kell 12:12, kirjutas Gokulakannan
Somasundaram:
> Hi,
> Currently The index implementation in Postgresql does not store
> the Snapshot information in the Index.
..
> Please reply back with your comments.
I think you got enoght "search for previous discussion"
Ühel kenal päeval, E, 2007-10-08 kell 11:41, kirjutas Heikki
Linnakangas:
> The dead space map holds
> visibility information in a condensed form. For index-only-scans, we
> need to know if all tuples on page are are visible to us. If the dead
> space map is designed with index-only-scans in mind,
Am Freitag, 28. September 2007 schrieb Nikolay Samokhvalov:
> what should be returned for XML like "PostgreSQL
> is a powerful, open source relational database system" if user
> requests for text under "em" node? In XML world, the correct answer is
> "PostgreSQL is a powerful, open source relation
Gokulakannan Somasundaram wrote:
> On 10/8/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>> IMO, the most promising approach to achieving index-only-scans at the
>> moment is the Dead Space Map, as discussed in the 8.3 dev cycle.
>
> Index only scans means that in order to get certain results
Am Samstag, 6. Oktober 2007 schrieb Tom Lane:
> It's not real clear to me whether, on a Unix machine, there is even
> supposed to be any difference between setting LC_TIME=es_ES.iso88591 and
> setting it to es_ES.utf8. Since nl_langinfo(CODESET) is supposedly
> determined only by LC_CTYPE, you cou
Am Sonntag, 7. Oktober 2007 schrieb Gregory Stark:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
> > Since nl_langinfo(CODESET) is supposedly determined only by LC_CTYPE, you
> > could argue that strftime's results should be in that encoding
> > regardless,
>
> It seems to me we aren't actually using st
On 10/8/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Csaba Nagy wrote:
> > On Mon, 2007-10-08 at 09:40 +0100, Heikki Linnakangas wrote:
> >> This idea has been discussed to death many times before. Please search
> >> the archives.
> >
> > Somewhat related to the "visibility in index" thing
On 10/8/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> > Currently The index implementation in Postgresql does not store the
> > Snapshot information in the Index. If we add the snapshot information
> into
> > the indexing structure, we will have the fo
Gokulakannan Somasundaram wrote:
>Finally i found some time to look more into the CRC code. The
> time is mostly taken when there is a back-up block in the XLOG structure.
> when it calculates the CRC for the entire block(there is some optimization
> already for the holes), the time is
Csaba Nagy wrote:
> On Mon, 2007-10-08 at 09:40 +0100, Heikki Linnakangas wrote:
>> This idea has been discussed to death many times before. Please search
>> the archives.
>
> Somewhat related to the "visibility in index" thing: would it be
> possible to have a kind of index-table ? We do have her
On Mon, 2007-10-08 at 09:40 +0100, Heikki Linnakangas wrote:
> This idea has been discussed to death many times before. Please search
> the archives.
Somewhat related to the "visibility in index" thing: would it be
possible to have a kind of index-table ? We do have here some tables
which have 2-4
On Thu, Oct 04, 2007 at 05:33:43PM -0400, Tom Lane wrote:
> This business with having libpq and ecpg pull in src/port modules
> manually is getting unmaintainable. I wonder whether we could persuade
> src/port to generate three versions of libpgport.a --- backend,
> frontend, and frontend-shlib-re
Gokulakannan Somasundaram wrote:
> Currently The index implementation in Postgresql does not store the
> Snapshot information in the Index. If we add the snapshot information into
> the indexing structure, we will have the following advantages.
This idea has been discussed to death many times
72 matches
Mail list logo
