-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, May 27, 2011 at 04:43:28PM -0400, Alvaro Herrera wrote:
> Hi,
>
> One of our customers is interested in being able to store original
> timezone along with a certain timestamp.
I've felt that pain here and there too...
> So the first thing is
From: "Peter Eisentraut"
On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:
Also, I think it's about time we got ourselves some kind of bug
tracker. I have no idea how to make that work without breaking
workflow that works now, but a quick survey of my pgsql-bugs email
suggests that this is
From: "Tom Lane"
"MauMau" writes:
The bad thing is that pg_ctl continues to wait until the specified
duration
passes, even if postgres fails to start. For example, it is naturally
desirable for pg_ctl to terminate when postgresql.conf contains a syntax
error.
Hmm, I thought we'd fixed this
Excerpts from Cédric Villemain's message of vie may 27 18:37:05 -0400 2011:
> 2011/4/21 Robert Haas :
> > Modified Files
> > --
> > doc/src/sgml/ref/alter_table.sgml | 26 +++
> > src/backend/commands/tablecmds.c | 277
> > +++--
>
> I notice
Greg Stark writes:
> On Fri, May 27, 2011 at 10:06 AM, Steve Singer
> wrote:
>> As another data point, the dblink regression tests work fine for me on a
>> PPC32 debian (squeeze,gcc 4.4.5) based system.
> Given that it's dblink my guess is that it's picking up the wrong
> version of libpq someh
On May 27, 2011, at 6:29 PM, Greg Stark wrote:
> Both of these two cases can be handled differently. The former by
> storing the raw text inputs and then storing the interpreted value as
> a derived column separetly, and the latter by storing the local time
> zone to use for display as an additiona
On 05/27/2011 04:29 PM, Greg Stark wrote:
On Fri, May 27, 2011 at 4:13 PM, Steve Crawford
wrote:
I am very interested in the use-case for this (in part as I'm working on a
PG related time talk). My experience thus far is that people who want this
do not fully understand the nature of date-time
On Fri, May 27, 2011 at 4:13 PM, Steve Crawford
wrote:
> I am very interested in the use-case for this (in part as I'm working on a
> PG related time talk). My experience thus far is that people who want this
> do not fully understand the nature of date-time calculations and variables
> in PG.
Th
On 05/27/2011 01:43 PM, Alvaro Herrera wrote:
Hi,
One of our customers is interested in being able to store original
timezone along with a certain timestamp.
I am very interested in the use-case for this (in part as I'm working on
a PG related time talk). My experience thus far is that people w
On Fri, May 27, 2011 at 2:32 PM, Kevin Grittner
wrote:
> I think the key thing is that the timestamp portion of it would be
> identical to our current TIMESTAMP WITH TIME ZONE -- always store it
> in the value UTC zone.
Fwiw our timestamp with time zone stores seconds since the epoch. This
is a q
On Fri, May 27, 2011 at 10:06 AM, Steve Singer wrote:
> As another data point, the dblink regression tests work fine for me on a
> PPC32 debian (squeeze,gcc 4.4.5) based system.
Given that it's dblink my guess is that it's picking up the wrong
version of libpq somehow.
--
greg
--
Sent via pgs
On Fri, May 27, 2011 at 9:24 PM, Peter Eisentraut wrote:
> On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:
>> Also, I think it's about time we got ourselves some kind of bug
>> tracker. I have no idea how to make that work without breaking
>> workflow that works now, but a quick survey of m
On tor, 2011-05-26 at 17:31 -0400, Tom Lane wrote:
> > We could also do that globally, but that would probably be something
> for
> > the next release.
>
> Hmm. I'm a bit scared of how much might break. I don't think the
> autoconf tests are generally designed to guarantee no warnings.
Yeah, I
On Friday, May 27, 2011 20:39:26 Robert Haas wrote:
> On Fri, May 27, 2011 at 2:19 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Fri, May 27, 2011 at 12:21 PM, Tom Lane wrote:
> >>> That patch is waiting for a committer who knows something about Windows
> >>> to pick it up.
> >>
> >> It m
From a language definition perspective, it is helpful to have a name for
every case instead of an implicit fallback, without any word to describe
it. See for instance "CREATE USER CREATEDB/NOCREATEDB" or "CREATE RULE ...
DO ALSO/INSTEAD" for similar occurences of naming default cases.
Oddly en
On Fri, May 27, 2011 at 04:55:07PM -0400, Robert Haas wrote:
> When a strong lock is taken or released, we have to increment or
> decrement strong_lock_counts[fasthashpartition]. Here's the question:
> is that atomic? In other words, suppose that strong_lock_counts[42]
> starts out at 0, and two
On May 27, 2011, at 2:35 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> I like it, but what do you do when a TZ has been renamed or has ceased
>> to exist.
>
> As far as that goes, I think "nothing" is a sufficient answer. There's
> no requirement that an OID in the mapping table correspon
"David E. Wheeler" writes:
> I like it, but what do you do when a TZ has been renamed or has ceased
> to exist.
As far as that goes, I think "nothing" is a sufficient answer. There's
no requirement that an OID in the mapping table correspond to a live TZ.
It's just a more compact way of storing
"David E. Wheeler" wrote:
> I like it, but what do you do when a TZ has been renamed or has
> ceased to exist. Or, worse, existed last week, so last week's
> dates might still use it, but next week's must not?
I think the key thing is that the timestamp portion of it would be
identical to our
On fre, 2011-05-27 at 13:55 -0400, Robert Haas wrote:
> Also, I think it's about time we got ourselves some kind of bug
> tracker. I have no idea how to make that work without breaking
> workflow that works now, but a quick survey of my pgsql-bugs email
> suggests that this is far from the only th
On May 27, 2011, at 1:43 PM, Alvaro Herrera wrote:
> Right now we rely on the tzdata files on disk for things like
> pg_timezone_names and other accesses of TZ data; so the files are the
> authoritative source of TZ info. So we need to ensure that whenever the
> files are updated, the catalogs ar
Alvaro Herrera writes:
> Right now we rely on the tzdata files on disk for things like
> pg_timezone_names and other accesses of TZ data; so the files are the
> authoritative source of TZ info. So we need to ensure that whenever the
> files are updated, the catalogs are updated as well.
> I thi
I intend to have a look at this patch and hopefully fix the outstanding
issues.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
Robert Haas writes:
> When a strong lock is taken or released, we have to increment or
> decrement strong_lock_counts[fasthashpartition]. Here's the question:
> is that atomic? In other words, suppose that strong_lock_counts[42]
> starts out at 0, and two backends both do ++strong_lock_counts[42
On Tue, May 24, 2011 at 10:03 AM, Noah Misch wrote:
> On Tue, May 24, 2011 at 08:53:11AM -0400, Robert Haas wrote:
>> On Tue, May 24, 2011 at 5:07 AM, Noah Misch wrote:
>> > This drops the part about only transferring fast-path entries once when a
>> > strong_lock_counts cell transitions from zer
Hi,
One of our customers is interested in being able to store original
timezone along with a certain timestamp.
It is currently possible to store a TZ in a separate column, but this is
a bit wasteful and not very convenient anyway.
There are all sorts of UI issues that need to be resolved in ord
On Wed, May 25, 2011 at 01:29:05PM -0400, Robert Haas wrote:
> On Wed, May 25, 2011 at 1:06 PM, Greg Smith wrote:
> > On 05/24/2011 04:34 PM, Robert Haas wrote:
>
> > I've been looking into a similar refactoring of the names here, where we
> > bundle all of these speed over safety things (fsync,
On Thu, May 26, 2011 at 12:38 AM, Fujii Masao wrote:
> On Thu, May 26, 2011 at 1:18 PM, Robert Haas wrote:
>>> The replay of the WAL record for A doesn't rely on the content of chunk 1
>>> which B modified. So I don't think that "partial page writes" has such
>>> a problem.
>>> No?
>>
>> Sorry.
On Fri, May 27, 2011 at 2:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, May 27, 2011 at 12:21 PM, Tom Lane wrote:
>>> That patch is waiting for a committer who knows something about Windows
>>> to pick it up.
>
>> It might be useful, in this situation, for the OP to add this patch to
>
Robert Haas writes:
> Still, maybe we don't have a better option. If it were me, I'd add an
> additional safety valve: use your formula if the percentage of the
> relation scanned is above some threshold where there's unlikely to be
> too much skew. But if the percentage scanned is too small, th
Robert Haas writes:
> On Fri, May 27, 2011 at 12:21 PM, Tom Lane wrote:
>> That patch is waiting for a committer who knows something about Windows
>> to pick it up.
> It might be useful, in this situation, for the OP to add this patch to
> the CommitFest application.
> https://commitfest.postgr
On Fri, May 27, 2011 at 11:10 AM, Greg Stark wrote:
> It would be nice if the VM had a bit for "all-frozen" but that
> wouldn't help much except in the case of truly cold data. We could
> perhaps keep the frozen data per segment or per VM page (which covers
> a large section of the table) which wo
On Fri, May 27, 2011 at 12:21 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> You have done what you need to do to check the status. Someone who knows
>> something about the bug should speak up at some point.
>
> That patch is waiting for a committer who knows something about Windows
> to pick
On 11-05-27 12:35 PM, Tom Lane wrote:
grebe, which is also a PPC64 machine, isn't showing the bug. And I just
failed to reproduce the problem on a RHEL6 PPC64 box. About to go try
it on RHEL5, which has a gcc version much closer to what wombat says
it's using, but I'm not very hopeful about th
I wrote:
> grebe, which is also a PPC64 machine, isn't showing the bug. And I just
> failed to reproduce the problem on a RHEL6 PPC64 box. About to go try
> it on RHEL5, which has a gcc version much closer to what wombat says
> it's using, but I'm not very hopeful about that.
Nope, no luck there
"Kevin Grittner" writes:
> Robert Haas wrote:
>> Around when did it start failing?
> According to the buildfarm logs the first failure was roughly 1 day
> 10 hours 40 minutes before this post.
See
http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=wombat&br=HEAD
The problem here is t
"Joshua D. Drake" writes:
> You have done what you need to do to check the status. Someone who knows
> something about the bug should speak up at some point.
That patch is waiting for a committer who knows something about Windows
to pick it up.
regards, tom lane
--
Sent
On 05/27/2011 05:36 AM, MauMau wrote:
> Hello,
>
> I posted a patch for bug #6011 to pgsql-hackers several days ago. How
> can I check the status of bug fixes? I'm worried that the patch might be
> forgotten, because bug #5842 was missed for two months until Bruce
> noticed it.
The joke that m
Excerpts from Andrew Dunstan's message of vie may 27 08:53:50 -0400 2011:
> In the immortal words of Robert Haas: "Hey, look! An elephant!"
This is Robert's $1000 tshirt, I think.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Develop
Robert Haas wrote:
> Andrew Dunstan wrote:
>>
>> Something odd is happening on buildfarm member wombat, a PPC970MP
>> box running Gentoo. We're getting dblink test failures. On the
>> one I << looked at more closely I saw this:
>>
>> [4ddf2c59.7aec:153] LOG: disconnection: session time:
>> 0:00
On Fri, May 27, 2011 at 7:41 PM, Heikki Linnakangas
wrote:
> On 27.05.2011 16:52, Pavan Deolasee wrote:
>>
>> On closer inspection, I realized that we have
>> deliberately put in this hook to ensure that we use visibility maps
>> only when we see at least SKIP_PAGES_THRESHOLD worth of all-visible
On Fri, May 27, 2011 at 7:11 AM, Heikki Linnakangas
wrote:
> Well, as with normal queries, it's usually faster to just seqscan the whole
> table if you need to access more than a few percent of the pages, because
> sequential I/O is so much faster than random I/O.
Well it's not strictly random ac
On Fri, May 27, 2011 at 8:44 AM, Andrew Dunstan wrote:
>
> Something odd is happening on buildfarm member wombat, a PPC970MP box
> running Gentoo. We're getting dblink test failures. On the one I looked at
> more closely I saw this:
>
> [4ddf2c59.7aec:153] LOG: disconnection: session time: 0:00:0
On Fri, May 27, 2011 at 7:36 PM, Tom Lane wrote:
> Pavan Deolasee writes:
>> My statistical skills are limited, but wouldn't that mean that for a
>> fairly well distributed write activity across a large table, if there
>> are even 3-4% update/deletes, we would most likely hit a
>> not-all-visible
On Thu, May 26, 2011 at 5:50 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> When we prune or vacuum a page, I don't suppose we have enough
>> information about that page's previous state to calculate a tuple
>> count delta, do we? That would allow a far more accurate number to
>> be maintaine
2011/5/27 Cédric Villemain :
> 2011/5/27 Pavan Deolasee :
>> I wonder if we have tested the reasoning behind having
>> SKIP_PAGES_THRESHOLD and the magic number of 32 assigned to it
>> currently. While looking at the code after a long time and doing some
>> tests, I realized that a manual VACUUM wo
"MauMau" writes:
> The bad thing is that pg_ctl continues to wait until the specified duration
> passes, even if postgres fails to start. For example, it is naturally
> desirable for pg_ctl to terminate when postgresql.conf contains a syntax
> error.
Hmm, I thought we'd fixed this in the last
On 27.05.2011 16:52, Pavan Deolasee wrote:
On closer inspection, I realized that we have
deliberately put in this hook to ensure that we use visibility maps
only when we see at least SKIP_PAGES_THRESHOLD worth of all-visible
sequential pages to take advantage of possible OS seq scan
optimizations
2011/5/27 Pavan Deolasee :
> I wonder if we have tested the reasoning behind having
> SKIP_PAGES_THRESHOLD and the magic number of 32 assigned to it
> currently. While looking at the code after a long time and doing some
> tests, I realized that a manual VACUUM would always scan first 31
> pages of
Pavan Deolasee writes:
> My statistical skills are limited, but wouldn't that mean that for a
> fairly well distributed write activity across a large table, if there
> are even 3-4% update/deletes, we would most likely hit a
> not-all-visible page for every 32 pages scanned ?
Huh? With a typical
I wonder if we have tested the reasoning behind having
SKIP_PAGES_THRESHOLD and the magic number of 32 assigned to it
currently. While looking at the code after a long time and doing some
tests, I realized that a manual VACUUM would always scan first 31
pages of a relation which has not received an
Something odd is happening on buildfarm member wombat, a PPC970MP box
running Gentoo. We're getting dblink test failures. On the one I looked
at more closely I saw this:
[4ddf2c59.7aec:153] LOG: disconnection: session time: 0:00:00.444 user=markwkm
database=contrib_regression host=[local]
On 05/27/2011 08:36 AM, MauMau wrote:
> Hello,
>
> I posted a patch for bug #6011 to pgsql-hackers several days ago. How
> can I check the status of bug fixes? I'm worried that the patch might
> be forgotten, because bug #5842 was missed for two months until Bruce
> noticed it.
>
>
In the immort
Hello,
I posted a patch for bug #6011 to pgsql-hackers several days ago. How can I
check the status of bug fixes? I'm worried that the patch might be
forgotten, because bug #5842 was missed for two months until Bruce noticed
it.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-
Hello,
I've encountered a problem of PostgreSQL startup, and I can think of a
simple solution for that. However, I don't yet have much knowledge about
PostgreSQL implementation, I'd like to ask you about what is the best and
easiest solution. If it is easy for me to work on during my spare tim
On 27 May 2011 10:01, Florian Pflug wrote:
> Anyway, I'm glad to see that Peter Geoghegan has picked this up
> any turned this into an actual patch.
>
> Extremely cool!
Thanks Florian.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Servi
On 27.05.2011 09:09, Jun Ishiduka wrote:
> STEP1: Make startup process to acquire backup-end-position from
> not only backup-end record but also backup-history-file .
>* startup process allows to acquire backup-end-position
> from backup-history-file .
>
On Fri, May 27, 2011 at 10:49:13AM +0100, Leonardo Francalanci wrote:
> > From: Noah Misch
> > > - the patch is missing the "send all table pages to the
> > > standby" part; is there some code I can use as base?
> >
> > Nothing comes to mind as especially similar.
> >
> > > I guess I have to
2011/5/27 Heikki Linnakangas :
> On 27.05.2011 12:06, Pavel Stehule wrote:
>>
>> Hello,
>>
>> I am working on testing Orafce for PostgreSQL 9.1. I found a issue.
>>
>> I cannot directly call a function "lower".
>
> See DirectFunctionCall1Coll()
ook
Thank you
Pavel
>
> --
> Heikki Linnakangas
>
On 27.05.2011 12:06, Pavel Stehule wrote:
Hello,
I am working on testing Orafce for PostgreSQL 9.1. I found a issue.
I cannot directly call a function "lower".
See DirectFunctionCall1Coll()
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailin
> From: Noah Misch
> > - the patch is missing the "send all table pages to the
> > standby" part; is there some code I can use as base?
>
> Nothing comes to mind as especially similar.
>
> > I guess I have to generate some special log type that
> > is only "played" by standby servers.
>
> W
On Fri, May 20, 2011 at 09:37:20AM +0100, Leonardo Francalanci wrote:
> I'll try to sum up what I understood:
>
> 1) the standby keeps the lock, so no problem with
> stray files coming from the unlogged->logged log
> reply, as the table can't be read during the operation
>
> 2) calling ResetUnlog
On May7, 2011, at 03:50 , Robert Haas wrote:
> On Sat, Jan 15, 2011 at 10:44 AM, Florian Pflug wrote:
>> I've realized that POSIX actually *does* provide a way to receive a signal -
>> the SIGIO machinery. I've modified my test case do to that. To simplify
>> things,
>> I've removed support for m
Hello,
I am working on testing Orafce for PostgreSQL 9.1. I found a issue.
I cannot directly call a function "lower".
Is it correct?
select dbms_assert.enquote_name('''"AAA');
! enquote_name.
! --
! "'""aaa"
! (1 row)
!.
select dbms_assert.enquote_name('''"AAA', false);
enq
On Fri, May 27, 2011 at 2:31 AM, Tom Lane wrote:
> Peter Eisentraut writes:
> > On tor, 2011-05-26 at 12:14 -0400, Tom Lane wrote:
> >> I tried this on my HP-UX 10.20 box, and it didn't work very nicely:
> >> configure decided that the compiler accepted +Olibmerrno, so I got a
> >> compile full
65 matches
Mail list logo
