On Tue, 2010-02-23 at 17:46 -0800, Josh Berkus wrote:
> On 2/23/10 10:58 AM, Simon Riggs wrote:
> > So I don't see this as something that needs fixing for 9.0. There is
> > already too much non-essential code there, all of which needs to be
> > tested. I don't think adding in new corner cases to "h
On Wed, 2010-02-24 at 08:30 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2010-02-22 at 11:47 +, Heikki Linnakangas wrote:
> >> Log Message:
> >> ---
> >> Move documentation of all recovery.conf option to a new chapter.
> >> They used to be scattered between the "bac
On Wed, Feb 24, 2010 at 2:51 AM, Takahiro Itagaki
wrote:
> Also, I heard ext4 has a "feature" in that rename() might truncate the
> renamed file to zero bytes on crash. The user data in the file might be
> lost if the machine crashes just after rename().
In our case I think this is the one thing
2010/2/24 Jeff Davis :
> On Tue, 2010-02-23 at 09:34 -0500, Bruce Momjian wrote:
>> Pavel Stehule wrote:
>> > 2010/2/23 Bruce Momjian :
>> > >
>> > > Can someone work on a patch to implement the document changes suggested
>> > > below?
>> > >
>> >
>> > This patch is useless now. There are no this i
Simon Riggs wrote:
> On Mon, 2010-02-22 at 11:47 +, Heikki Linnakangas wrote:
>> Log Message:
>> ---
>> Move documentation of all recovery.conf option to a new chapter.
>> They used to be scattered between the "backup and restore" and "streaming
>> replication" chapters.
>
> It's just
The fourth alpha release for PostgreSQL version 9.0, 9.0alpha4, is now
available. This alpha contains several new major features added since
the previous alpha. Please download, install, and test it to give us
early feedback on the features being developed for the next version of
PostgreSQL.
Featu
On Fri, Feb 12, 2010 at 4:59 PM, Heikki Linnakangas
wrote:
> Joachim Wieland wrote:
>> On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao wrote:
>>> Yeah, even if primary_conninfo is not given, the standby tries to invoke
>>> walreceiver by using the another connection settings (environment variables
>
On Wed, Feb 24, 2010 at 8:24 AM, Simon Riggs wrote:
> On Mon, 2010-02-22 at 11:47 +, Heikki Linnakangas wrote:
>> Log Message:
>> ---
>> Move documentation of all recovery.conf option to a new chapter.
>> They used to be scattered between the "backup and restore" and "streaming
>> repl
On Tue, Feb 23, 2010 at 10:18 PM, Tom Lane wrote:
>
> Personally I find that goal rather suspect anyway.
> I think the chances of determining this reliably in pgpool are
> negligible, even if functions were marked like that. You would need to
> duplicate *all* of the backend's parsing and all of
Tom Lane wrote:
> Bruce Momjian writes:
> > Uh, I don't see this patch as applied. Was it not necessary?
>
> It was not; the real problem was that ExecutorEnd shouldn't have been
> called at all, which I fixed in the portal code.
Thanks, both of you. :-)
--
Bruce Momjian http://mo
Tatsuo Ishii writes:
> Apparently IMMUTABLE/STABLE should not write to database according to
> docs. Are you saying that in the real world these are ignored? If so,
> this is an important database intergrity issue as Simon pointed out.
One more time: these markings are not about whether the funct
Bruce Momjian writes:
> Uh, I don't see this patch as applied. Was it not necessary?
It was not; the real problem was that ExecutorEnd shouldn't have been
called at all, which I fixed in the portal code.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-h
Takahiro Itagaki writes:
> Andres Freund wrote:
>> I started setting up some halfway automated method of simulating hard
>> crashes
>> and even while setting those up I found some pretty unsettling results...
>> Now its not unlikely that my testing is flawed but unfortunately I don't see
>> wh
Andres Freund wrote:
> I started setting up some halfway automated method of simulating hard crashes
> and even while setting those up I found some pretty unsettling results...
> Now its not unlikely that my testing is flawed but unfortunately I don't see
> where right now (its 3am now and I h
Bruce Momjian writes:
> Tom Lane wrote:
>> Well, "trivial" and "correct" are entirely different things :-(.
> So you are saying if you run pg_restore on the SQL dump file, it doesn't
> pick up the version?
No, I'm saying it printed the wrong thing if you did pg_restore -v from
an archive file ma
Bruce Momjian wrote:
> Uh, I don't see this patch as applied. Was it not necessary?
No, the bug was reported again and fixed then with:
- Force READY portals into FAILED state when a transaction or subtransaction
is aborted
Message-Id: <20100218030646.500a3754...@cvs.postgresql.org>
On 2/23/10 10:58 AM, Simon Riggs wrote:
> So I don't see this as something that needs fixing for 9.0. There is
> already too much non-essential code there, all of which needs to be
> tested. I don't think adding in new corner cases to "help" people makes
> any sense until we have automated testing
> IMMUTABLE/STABLE/VOLATILE is not really about side effects, it is about
> how long the function value can be expected to hold still for.
>
> There are quite a lot of cases of functions that are marked
> conservatively as stable (or even volatile) but could be considered
> immutable in particular
> > I'm wondering if we could detect a funcion has a side effect,
> > i.e. does a write to database. This is neccessary for pgpool to decide
> > if a qeury should to be sent to all of databases or not. If a query
> > includes functions which do writes to database, it should send the
> > query to al
On Wed, Feb 24, 2010 at 4:49 AM, Robert Haas wrote:
> Maybe. But for sure, if it doesn't, and instead tells the user to
> issue pg_stop_backup(), then pg_stop_backup() had better WORK when the
> user tries to execute it. I gather that the problem is that it has to
> finish all that outstanding a
On 2/24/10, Rémi Zara wrote:
> Pika, which has been upgraded to NetBSD/mips 5.0.2, failed twice in a row
> pgcrypto/test sha2 because of the following warning (identical each time) :
>
> Anything I should try ?
Please try --without-openssl.
--
marko
--
Sent via pgsql-hackers mailing list
On Tue, Feb 23, 2010 at 4:40 AM, Magnus Hagander wrote:
> 2010/2/23 Jaime Casanova :
>> Hi,
>>
>> it's safe to set synchrounous_commit to off in a pg_dump generated
>> script? if yes, would this help to the performance of restore a
>> database?
>
> It might help if you're dumping as individual ins
On Tue, 2010-02-23 at 09:34 -0500, Bruce Momjian wrote:
> Pavel Stehule wrote:
> > 2010/2/23 Bruce Momjian :
> > >
> > > Can someone work on a patch to implement the document changes suggested
> > > below?
> > >
> >
> > This patch is useless now. There are no this issue now, because we
> > have in
On Mon, 2010-02-22 at 11:47 +, Heikki Linnakangas wrote:
> Log Message:
> ---
> Move documentation of all recovery.conf option to a new chapter.
> They used to be scattered between the "backup and restore" and "streaming
> replication" chapters.
It's just taken me 15 minutes to locate
On Tue, 2010-02-23 at 10:00 +0100, Stefan Kaltenbrunner wrote:
> While playing with SR/HS in a more complex datacenter environment I
> immediatly hit the need to being able to specify the ipaddress(or
> interface) that the backend(or libpq) uses to connect to the master.
>
> There are a few reas
Simon Riggs writes:
> So wrongly marking a function as something other than volatile *is* a
> data integrity issue. Why is that OK? ISTM that this should work the way
> Tatsuo wants it to work.
Please read the rest of the thread.
regards, tom lane
--
Sent via pgsql-hack
On Tue, 2010-02-23 at 17:49 -0500, Bruce Momjian wrote:
> I assume no progress has been made on testing the performance of this
> patch.
>
That's correct. As of right now, the potential benefits of the patch do
not seem to justify the performance testing effort.
Others are welcome to try, of cou
On Thu, 2010-01-28 at 10:28 +0200, Heikki Linnakangas wrote:
> Fujii Masao wrote:
> > In relation to the functions added recently, I found an annoying problem;
> > pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the
> > wrong name because pg_xlogfile_name() always uses the cur
I assume no progress has been made on testing the performance of this
patch.
---
Jeff Davis wrote:
> Attached is a patch to implement the idea discussed here:
>
> http://archives.postgresql.org/pgsql-hackers/2009-08/msg011
Robert Haas wrote:
> Perhaps we should add it to the next CommitFest?
Sounds like the right course of action to me. If nobody objects or
beats me to it, I'll do that.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Tue, 2010-02-23 at 12:51 +0900, Tatsuo Ishii wrote:
> I'm wondering if we could detect a funcion has a side effect,
> i.e. does a write to database. This is neccessary for pgpool to decide
> if a qeury should to be sent to all of databases or not. If a query
> includes functions which do writes
Uh, I don't see this patch as applied. Was it not necessary?
---
Itagaki Takahiro wrote:
>
> Robert Haas wrote:
>
> > It looks like this is enough to reproduce the cache lookup failure:
>
> The "cache loopup failure" pa
Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Feb 23, 2010 at 1:47 PM, Tom Lane wrote:
> >> However, has the patch actually been reviewed? ?pg_dump is a piece of
> >> code where it is notoriously easy for novices to do things wrong,
> >> and this is especially true for adding output that shou
On Mon, 2010-02-22 at 23:49 -0500, Tom Lane wrote:
> Tatsuo Ishii writes:
> > I'm wondering if we could detect a funcion has a side effect,
> > i.e. does a write to database.
>
> > Currently we have three properties of functions: IMMUTABLE, STABLE and
> > VOLATILE. According to docs IMMUTABLE or
Kevin Grittner wrote:
> Due to a thread about the neglect of the sample start scripts I took a
> look at the current Linux file. There's certainly room for several
> improvements, but some of them might require discussion. Attached are
> a couple small changes which seem to me to be pretty tame.
Hi,
Pika, which has been upgraded to NetBSD/mips 5.0.2, failed twice in a row
pgcrypto/test sha2 because of the following warning (identical each time) :
**
/home/pgbuildfarm/workdir/HEAD/pgsql.12374/contrib/pgcrypto/expected/sha2.out
Tue Feb 23 13:14:03 2010
---
/home/pgbuildfarm/work
Robert Haas writes:
> On Tue, Feb 23, 2010 at 1:47 PM, Tom Lane wrote:
>> However, has the patch actually been reviewed? pg_dump is a piece of
>> code where it is notoriously easy for novices to do things wrong,
>> and this is especially true for adding output that should only come out
>> in par
On Tue, Feb 23, 2010 at 4:03 PM, Kevin Grittner
wrote:
> Bruce Momjian wrote:
>> I assume this is not something we are supposed to apply.
>
> While it appears to improve conformance with the IEEE Std 1003.1 and
> expand the range of numbers which are correctly handled, it does
> more calculations
On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane wrote:
>
> There may be some value in inventing a "has no side effects" marker, but
> that should not be confused with IMMUTABLE/STABLE.
>
a READONLY function?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de
Robert Haas wrote:
> On Tue, Feb 23, 2010 at 1:47 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Tom Lane escribi?:
> >>> That would be an argument for sticking this in the next CF, not for
> >>> applying it now --- it was submitted after the close of the last CF no?
> >
> >> Sep. 29 2009?
>
Andrew Dunstan wrote:
>
>
> Robert Haas wrote:
> > On Tue, Feb 23, 2010 at 12:43 AM, Bruce Momjian wrote:
> >
> >> Is this a TODO?
> >>
> >
> > Sounds good to me.
> >
> >
>
> I think it would be useful if we put line breaks in the column list it
> gets, otherwise not so much for any
Robert Haas wrote:
> On Tue, Feb 23, 2010 at 12:22 AM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Alvaro Herrera writes:
> >> > Andrew Dunstan wrote:
> >> >> It will affect any dbname or username in mixed or upper case, not just
> >> >> ALL, won't it?
> >>
> >> > No, I am suggesting to change
Tom Lane wrote:
> Stefan Kaltenbrunner writes:
> > Tom Lane wrote:
> >> Nobody suggested dismissing it. The point was that it hasn't been
> >> tested adequately to justify applying it now.
>
> > not sure what testing people want to get done though (there are a fair
> > amount of results and pro
Bruce Momjian wrote:
> I assume this is not something we are supposed to apply.
While it appears to improve conformance with the IEEE Std 1003.1 and
expand the range of numbers which are correctly handled, it does
more calculations. I wouldn't want to see it get in without
performance testing
On Tue, Feb 23, 2010 at 3:09 PM, Joshua D. Drake wrote:
> On Tue, 2010-02-23 at 14:49 -0500, Robert Haas wrote:
>
>> > If I issue a shutdown, PostgreSQL should do whatever it needs to do to
>> > shutdown; including issuing a pg_stop_backup.
>>
>> Maybe. But for sure, if it doesn't, and instead te
On Tue, 2010-02-23 at 14:49 -0500, Robert Haas wrote:
> > If I issue a shutdown, PostgreSQL should do whatever it needs to do to
> > shutdown; including issuing a pg_stop_backup.
>
> Maybe. But for sure, if it doesn't, and instead tells the user to
> issue pg_stop_backup(), then pg_stop_backup()
Greg Stark wrote:
> Kevin Grittner wrote:
>> Thanks for the examples. They did make me consider a real-life
>> type of process which isn't currently implemented as a PostgreSQL
>> function, but conceivably could be -- randomizing a pool of
>> jurors to facilitate jury selection. My eyes are o
On Tue, Feb 23, 2010 at 2:02 PM, Tom Lane wrote:
> There may be some value in inventing a "has no side effects" marker, but
> that should not be confused with IMMUTABLE/STABLE.
Yeah, that's what I was thinking, too
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Tue, Feb 23, 2010 at 12:52 PM, Joshua D. Drake
wrote:
> On Tue, 2010-02-23 at 09:45 -0800, Josh Berkus wrote:
>> Simon, Fujii, All:
>>
>> While demoing HS/SR at SCALE, I ran into a problem which is likely to be
>> a commonly encountered bug when people first setup HS/SR. Here's the
>> sequenc
On Tue, 2010-02-23 at 11:24 -0800, Joshua D. Drake wrote:
> This will bite us if we release like this.
No it won't. The current behaviour was put there by user request a few
releases back. This isn't a 9.0 issue, and as I've said its addressing
something that we now longer see as mainstream going
On Tue, Feb 23, 2010 at 06:58:22PM +, Simon Riggs wrote:
> On Tue, 2010-02-23 at 09:45 -0800, Josh Berkus wrote:
>
> > 1) Set up a brand new master with an archive-commmand and
> > archive=on.
> >
> > 2) Start the master
> >
> > 3) Do a pg_start_backup()
> >
> > 4) Realize, based on log err
Simon Riggs wrote:
> The correct resolution is to put in an archive_command that works.
One really should ensure that WAL files (or should I now say data?
;-) are flowing before issuing running the pg_start_backup()
function. The documentation has always been pretty explicit about
that:
htt
On Tue, 2010-02-23 at 18:58 +, Simon Riggs wrote:
> On Tue, 2010-02-23 at 09:45 -0800, Josh Berkus wrote:
> > This issue is 100% reproduceable.
>
> IMHO there in no problem in that behaviour. If somebody requests a
> backup then we should wait for it to complete. Kevin's suggestion of
> pg_fa
On Tue, Feb 23, 2010 at 1:47 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane escribió:
>>> That would be an argument for sticking this in the next CF, not for
>>> applying it now --- it was submitted after the close of the last CF no?
>
>> Sep. 29 2009?
>
> Oh, I was thinking it had just
Greg Stark writes:
> On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner
> wrote:
>> I didn't realize tsearch functions were volatile. Should they
>> really be so?
> Uhm, my mistake. They're stable.
IMMUTABLE/STABLE/VOLATILE is not really about side effects, it is about
how long the function value
On Tue, 2010-02-23 at 09:45 -0800, Josh Berkus wrote:
> 1) Set up a brand new master with an archive-commmand and archive=on.
>
> 2) Start the master
>
> 3) Do a pg_start_backup()
>
> 4) Realize, based on log error messages, that I've misconfigured the
> archive_command.
> 5) Attempt to shut d
Stefan Kaltenbrunner writes:
> Tom Lane wrote:
>> Nobody suggested dismissing it. The point was that it hasn't been
>> tested adequately to justify applying it now.
> not sure what testing people want to get done though (there are a fair
> amount of results and profiles in the thread)?
Robert
On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner
wrote:
>> Or somebody who uses the tsearch functions because they're
>> planning to not change their dictionaries.
>
> I didn't realize tsearch functions were volatile. Should they
> really be so?
Uhm, my mistake. They're stable. Ok, for that one I
Alvaro Herrera writes:
> Tom Lane escribió:
>> That would be an argument for sticking this in the next CF, not for
>> applying it now --- it was submitted after the close of the last CF no?
> Sep. 29 2009?
Oh, I was thinking it had just come in recently, but looking back you're
right. It did sl
Tom Lane wrote:
Stefan Kaltenbrunner writes:
hmm I tend to disagree, this patch was specifically done to address a
hotspot I noticed under a given workload and it helped a lot for that
workload(like getting 6000qps more is pretty neat imho).
While people might not use fixed width chars that of
Stefan Kaltenbrunner writes:
> hmm I tend to disagree, this patch was specifically done to address a
> hotspot I noticed under a given workload and it helped a lot for that
> workload(like getting 6000qps more is pretty neat imho).
> While people might not use fixed width chars that often(which
Greg Stark wrote:
> Kevin Grittner wrote:
>> Does anyone have a sane use case for a non-volatile function to
>> call a volatile one or to update the database?
>
> So consider for example a function which explicitly sets the
> timezone and then uses timestamp without timezone functions (which
Robert Haas wrote:
On Tue, Feb 23, 2010 at 12:43 AM, Bruce Momjian wrote:
Is this a TODO?
Sounds good to me.
I think it would be useful if we put line breaks in the column list it
gets, otherwise not so much for any view with more than a handful of
columns. That's where we c
Tom Lane escribió:
> Josh Berkus writes:
> > On 2/23/10 10:14 AM, Robert Haas wrote:
> >> On Mon, Feb 22, 2010 at 8:55 PM, Bruce Momjian wrote:
> >>> What happened to this patch? I don't see any objections, but it was not
> >>> applied.
> >>
> >> I think that the patch author never added it to t
Alvaro Herrera wrote:
Robert Haas escribió:
On Mon, Feb 22, 2010 at 9:35 PM, Bruce Momjian wrote:
What ever happened to this patch?
I think it's unclear that all of the best and worst cases have been
sufficiently tested and that the results are satisfactory. We have
everything from massive
Josh Berkus writes:
> On 2/23/10 10:14 AM, Robert Haas wrote:
>> On Mon, Feb 22, 2010 at 8:55 PM, Bruce Momjian wrote:
>>> What happened to this patch? I don't see any objections, but it was not
>>> applied.
>>
>> I think that the patch author never added it to the open CommitFest
>> and nobody
Robert Haas escribió:
> On Mon, Feb 22, 2010 at 9:35 PM, Bruce Momjian wrote:
> > What ever happened to this patch?
>
> I think it's unclear that all of the best and worst cases have been
> sufficiently tested and that the results are satisfactory. We have
> everything from massive performance
On Tue, Feb 23, 2010 at 12:43 AM, Bruce Momjian wrote:
> Is this a TODO?
Sounds good to me.
>> It doesn't seem like it would be that difficult to add a view editor as
>> \ev.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Feb 23, 2010 at 12:22 AM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>> > Andrew Dunstan wrote:
>> >> It will affect any dbname or username in mixed or upper case, not just
>> >> ALL, won't it?
>>
>> > No, I am suggesting to change only the comparisons to the literal
On 2/23/10 10:14 AM, Robert Haas wrote:
> On Mon, Feb 22, 2010 at 8:55 PM, Bruce Momjian wrote:
>> What happened to this patch? I don't see any objections, but it was not
>> applied.
>
> I think that the patch author never added it to the open CommitFest
> and nobody else thought it was important
On Mon, Feb 22, 2010 at 9:35 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Jeremy Kerr writes:
>> > Stephen,
>> >> If the updated function is always faster when the overall string is at
>> >> least, say, 16 characters long,
>>
>> > But that's not the case - the cost of the function (and the speed
On Tue, Feb 23, 2010 at 4:52 PM, Kevin Grittner
wrote:
> Right, we all know it currently doesn't throw an error, but I can't
> think of anywhere I'd like to have someone do that in a database for
> which I have any responsibility. Does anyone have a sane use case
> for a non-volatile function to
On Mon, Feb 22, 2010 at 8:55 PM, Bruce Momjian wrote:
> What happened to this patch? I don't see any objections, but it was not
> applied.
I think that the patch author never added it to the open CommitFest
and nobody else thought it was important enough to pick up. It looks
innocuous to me; wan
"Joshua D. Drake" wrote:
> If I issue a shutdown, PostgreSQL should do whatever it needs to
> do to shutdown; including issuing a pg_stop_backup.
Should we have a pg_fail_backup function, so that it doesn't put out
a file which suggests that we have a complete backup?
-Kevin
--
Sent via p
On Tue, 2010-02-23 at 09:45 -0800, Josh Berkus wrote:
> Simon, Fujii, All:
>
> While demoing HS/SR at SCALE, I ran into a problem which is likely to be
> a commonly encountered bug when people first setup HS/SR. Here's the
> sequence:
>
> 1) Set up a brand new master with an archive-commmand and
> This issue is 100% reproduceable.
Oh, btw, this is on Alpha4.
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon, Fujii, All:
While demoing HS/SR at SCALE, I ran into a problem which is likely to be
a commonly encountered bug when people first setup HS/SR. Here's the
sequence:
1) Set up a brand new master with an archive-commmand and archive=on.
2) Start the master
3) Do a pg_start_backup()
4) Rea
I added this URL to the existing TODO item.
---
Heikki Linnakangas wrote:
> Here is an updated version of my patch to return data from b-tree
> indexes, and use it to satisfy quals.
>
> I added a new column 'amregurgitate'
Tom Lane wrote:
> "Kevin Grittner" writes:
>> throw an error on any attempt to call a volatile function or
>> modify the database?
> It's *not an error* for a nonvolatile function to call a volatile
> one.
Right, we all know it currently doesn't throw an error, but I can't
think of anywhere
Is this a TODO?
---
Heikki Linnakangas wrote:
> Robert Haas wrote:
> > Since you previously stated that you were going to put this patch
> > aside to work on HS and SR[1], I'm going to move this to Returned with
> > Feedback
On Tue, Feb 23, 2010 at 11:08 AM, Tom Lane wrote:
>
> It's *not an error* for a nonvolatile function to call a volatile one.
it should be considered an error i think, someone think there is a use
cas for calling volatile functions
inside stable ones but i can see what that reason could be...
> A
Oleg, Teodor, can you look at this? I tried to fix it in wparser_def.c,
but couldn't figure out how. Thanks.
---
Dan O'Hara wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5021
> Logged by:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
What happened to this? I didn't see it applied.
I got puzzled by some delphic comments, and then I got pulled into work
of a higher priority, so it slipped down my list.
Maybe we can pick it up again in 9.
> > I was talking about this to someone in Cuba and one conclusion we
> > reached was that this was a fairly difficult task -- consider that
> > someone may choose to define an innocent-looking operator using a
> > volatile function. If you only examine things that look like functions
> > in the q
Andrew Dunstan wrote:
>
>
>
> Bruce Momjian wrote:
> > What happened to this? I didn't see it applied.
> >
> >
>
> I got puzzled by some delphic comments, and then I got pulled into work
> of a higher priority, so it slipped down my list.
>
> Maybe we can pick it up again in 9.1.
OK, sho
Bruce Momjian wrote:
> bruce wrote:
> > bruce wrote:
> > > Dave Page wrote:
> > > > This was posted as a documentation comment:
> > > >
> > > > to_char(interval '0d 0h 12m 44s', 'DD HH MI SS');
> > > > with HH and HH12 will return 12 instead of 0.
> > > >
> > > > Testing on 8.4.1, it does seem to
I wrote:
> BTW, I notice that after allegedly fixing things, we are now seeing
> fsync failures during CREATE DATABASE in the installcheck phase of
> buildfarm runs on (apparently) all the Windows critters, plus a
> couple of other platforms too. This mystifies me. I could believe
> that there wa
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Those classifications are meant as planner directives; they are
>> NOT meant to be bulletproof. Hanging database integrity
>> guarantees on whether a "non volatile" function changes anything
>> is entirely unsafe. To give just one illustration of th
Steve Atkins wrote:
> Would having a higher level process manager be adequate - one
> that spawns the postmaster and a list of associated processes
> (queue manager, job scheduler, random user daemons that are
> used for database application maintenance). It sounds like
> something like that would
On Feb 22, 2010, at 9:02 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Regarding hooks or events, I think postmaster should be kept simple:
>> launch at start, reset at crash recovery, kill at stop. Salt and pepper
>> allowed but that's about it -- more complex ingredients are out of the
>> q
Bruce Momjian wrote:
What happened to this? I didn't see it applied.
I got puzzled by some delphic comments, and then I got pulled into work
of a higher priority, so it slipped down my list.
Maybe we can pick it up again in 9.1.
cheers
andrew
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
> Those classifications are meant as planner directives; they are
> NOT meant to be bulletproof. Hanging database integrity
> guarantees on whether a "non volatile" function changes anything
> is entirely unsafe. To give just one illustration of the
> problems, a nonvolatile fu
Greg Stark writes:
> I don't like using configure tests for this because I fear someone
> could compile Postgres on a system with one set of behaviour and then
> switch to a different kernel version with a different set of
> behaviour. In the worst case it could be filesystem dependent whether
> y
On Tue, 2010-02-23 at 17:08 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2010-02-22 at 08:51 +0200, Heikki Linnakangas wrote:
> >> Gokulakannan Somasundaram wrote:
> >
> >>> May i get a little clarification on this issue? Will we be supporting
> >>> the IOT feature in post
Simon Riggs wrote:
> On Mon, 2010-02-22 at 08:51 +0200, Heikki Linnakangas wrote:
>> Gokulakannan Somasundaram wrote:
>
>> > May i get a little clarification on this issue? Will we be
>> > supporting the IOT feature in postgres in future?
>>
>> What seems like the best path to achieve the kind o
Andrew Dunstan wrote:
> Gokulakannan Somasundaram wrote:
>> I looked at the postgres nbtree code. From my analysis(which
>> might be wrong!), we can implement IOTs, provided we make a decision
>> on broken data types issue.
>
> I am not familiar with this term "broken data types", and I j
Simon Riggs wrote:
> On Mon, 2010-02-22 at 08:51 +0200, Heikki Linnakangas wrote:
>> Gokulakannan Somasundaram wrote:
>
>>> May i get a little clarification on this issue? Will we be supporting
>>> the IOT feature in postgres in future?
>> What seems like the best path to achieve the kind of p
> > I'm wondering if we could detect a funcion has a side effect,
> > i.e. does a write to database. This is neccessary for pgpool to decide
> > if a qeury should to be sent to all of databases or not. If a query
> > includes functions which do writes to database, it should send the
> > query to al
Simon Riggs wrote:
> What is wanted is a means to integrate parts of a solution that are
> already intimately tied to Postgres. Non-integration makes the whole
> Postgres-based solution less reliable and harder to operate. Postgres
> should not assume that it is the only aspect of the server: in a
Gokulakannan Somasundaram wrote:
I looked at the postgres nbtree code. From my analysis(which
might be wrong!), we can implement IOTs, provided we make a decision
on broken data types issue.
I am not familiar with this term "broken data types", and I just looked
for it in the
1 - 100 of 118 matches
Mail list logo
