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 integrated true SQL parser.
Regards
Pavel
> ---
Tom Lane wrote:
One way to deal with it would be to expose the whole renegotiation
setting as a user configuratble option. So they can set *when* we
renegotiate, which would also let them turn it off completely.
>>>
>>> Well, that might be a reasonable thing to do, because it's not
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 reasons for being able to do so like:
* we are now suddenly in a situation
On Tue, Feb 23, 2010 at 5:37 AM, Tom Lane wrote:
> So the problem is that fsync_fname is trying to fsync a file it's opened
> O_RDONLY. I don't know whether Windows is similarly picky, but we'll
> soon find out.
>
Argh, now I feel silly. I had actually found that in my searches after
the first b
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 inserts and not COPY,
but if you're doing that you're not asking for p
Tom Lane writes:
> Alvaro Herrera writes:
>> Regarding hooks or events, I think postmaster should be kept simple:
>> launch at start, reset at crash recovery, kill at stop.
>
> This is exactly why I think the whole proposal is a nonstarter. It is
> necessarily pushing more complexity into the po
2010/2/23 Stefan Kaltenbrunner :
> 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 reasons for being able to do so lik
2010/2/22 Tom Lane :
> Magnus Hagander writes:
>> 2010/2/22 Tom Lane :
>> You'd still have to turn it off on the server side if you have a
>> *single* client that has the broken patch, but that's still a lot
>> better than nothing.
>
> Well, if it's a GUC it can be set per-user or per-database, so
2010/2/23 Albe Laurenz :
> Tom Lane wrote:
> One way to deal with it would be to expose the whole renegotiation
> setting as a user configuratble option. So they can set *when* we
> renegotiate, which would also let them turn it off completely.
Well, that might be a reasonable
On Tue, Feb 23, 2010 at 10:42 AM, Tom Lane wrote:
> Takahiro Itagaki writes:
> > Instead, how about excluding columns in primary keys from table data?
>
> How will you implement "select * from mytable" ? Or even
> "select * from mytable where non_primary_key = something" ?
> If you can't do eit
I wrote:
> Any theories about what is happening?
Hah --- the AIX failures, at least, are explained at
http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/fsync.htm
which says
Error Codes
The fsync or fsync_range subroutine is unsuccessful if on
Hi all,
On Mon, 2010-02-22 at 10:29 +, Greg Stark wrote:
> On Mon, Feb 22, 2010 at 8:18 AM, Gokulakannan Somasundaram
> wrote:
> > a) IOT has both table and index in one structure. So no duplication of data
> > b) With visibility maps, we have three structures a) Table b) Index c)
> > Visibil
Dimitri Fontaine wrote:
> Tom Lane writes:
> > Alvaro Herrera writes:
> >> Regarding hooks or events, I think postmaster should be kept simple:
> >> launch at start, reset at crash recovery, kill at stop.
> >
> > This is exactly why I think the whole proposal is a nonstarter. It is
> > necessari
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 integrated true SQL parser.
Great, thanks.
--
Bruce Momjian ht
Tatsuo Ishii wrote:
> Hi,
>
> 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 sen
I tried to set up a simple master/slave setup and immediately ran into
this assertion failure. The slave is just a cold copy of the database
immediately after initdb. The first WAL segment hasn't been archived
yet. It sees that the first archive fail hasn't been archived yet,
starts up walreceiver
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 performance
> benefits
On Tue, 2010-02-23 at 00:02 -0500, 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 t
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
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
> > 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:
> 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
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 o
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
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
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
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
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
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
"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
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
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
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
> > 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
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.
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:
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
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
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
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'
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
> 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
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
"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 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
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 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 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 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 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:
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
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
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
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
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
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
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
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
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
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
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, 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
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, 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
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
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, 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
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 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, 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.
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, 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()
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
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
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
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
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 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?
>
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
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
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
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
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.
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
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
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
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
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://
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
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
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
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 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
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 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 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 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 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
> > 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
1 - 100 of 118 matches
Mail list logo
