Greg Smith wrote:
> Fujii Masao wrote:
>> We would be easily able to calculate the last archived log file from
>> the existence of archive status files.
>
> Right, but you have to actually scan the whole archive directory to
> figure that out, and I'd rather not see that code get duplicated
> some
Sorry for the delay.
On Fri, Feb 26, 2010 at 6:26 AM, Erik Rijkers wrote:
> With this patch the standby compiles, tests, installs OK.
> I wanted to check with you if the following is expected.
Thanks for the test and bug report!
> With standby (correctly) as follows :
> LOG: redo starts at 0/1
Hi,
> Now it is true that a lot of the uses for that were subsumed when
> we added coerce-via-IO to the native cast capabilities; but I'm
> still quite scared of what this would break, and I don't see any
> field demand for a change.
Well, we have had one of our EDB connectors facing issues becau
Fujii Masao wrote:
We would be easily able to calculate the last archived log file from
the existence of archive status files.
Right, but you have to actually scan the whole archive directory to
figure that out, and I'd rather not see that code get duplicated
somewhere else when it's alrea
Fujii Masao wrote:
On Fri, Feb 26, 2010 at 2:47 AM, Bruce Momjian wrote:
Postgres 9.0 will be the first release to mention /bin/true as a way of
turning off archiving in extraordinary circumstances:
http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html
Setting
On Fri, Feb 26, 2010 at 10:00 PM, Greg Stark wrote:
> Secondarily, the message printed at this time and when the process is
> finished doesn't actually give the user any information on how much
> longer to expect the process to take.
>
> It would be nice to say what the target archive log we're wa
Robert Haas wrote:
I just read through the current documentation and it doesn't really
seem to explain very much about how HS decides which queries to kill.
Can someone try to flesh that out a bit?
I believe it just launches on a mass killing spree once things like
max_standby_delay expire. T
On Fri, Feb 26, 2010 at 2:47 AM, Bruce Momjian wrote:
> Postgres 9.0 will be the first release to mention /bin/true as a way of
> turning off archiving in extraordinary circumstances:
>
> http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html
> Setting archive_mode to a c
Bruce Momjian wrote:
Joachim Wieland wrote:
1) With the current implementation they will see better performance on
the master and more aggressive vacuum (!), since they have less
long-running queries now on the master and autovacuum can kick in and
clean up with less delay than before. On the
>
> > a) We are already going from table to index to do unique checks. This is
> the
> > same thing, which we will do to go and update the snapshot in the
> indexes.
>
> No, it is not the same thing. Updating index snapshots requires being
> able to *re-find* a previously made index entry for the
Josh Berkus wrote:
> HS+SR is still a tremendous improvement over the options available
> previously. We never thought it was going to work for everyone
> everywhere, and shouldn't let our project's OCD tendencies run away from us.
OCD (Obsessive-Compulsive Disorder) --- good one. :-)
--
Bru
Joachim Wieland wrote:
> 1) With the current implementation they will see better performance on
> the master and more aggressive vacuum (!), since they have less
> long-running queries now on the master and autovacuum can kick in and
> clean up with less delay than before. On the other hand their q
"Ed L." writes:
> On Monday 01 March 2010 @ 17:57, Tom Lane wrote:
>> BTW, there seems to be some other contributing factor here
>> besides the weird username, because I don't see any looping
>> when I try CREATE USER "@". What's your platform exactly,
>> and what type of filesystem is $PGDATA on
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >> Hiroshi Inoue wrote:
> >>> Bruce Momjian wrote:
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> >> Where are we on this issue?
> > Oops I forgot it completely.
> > I have a little improved version and w
* Tom Lane [100301 20:04]:
> Greg Stark writes:
> > josh, nobody is talking about it because it doesn't make sense. you could
> > only retry if it was the first query in the transaction and only if you
> > could prove there were no side-effects outside the database and then you
> > would have no
On Mon, Mar 1, 2010 at 5:32 PM, Josh Berkus wrote:
> On 2/28/10 7:12 PM, Robert Haas wrote:
>>> However, I'd still like to hear from someone with the requisite
>>> > technical knowledge whether capturing and retrying the current query in
>>> > a query cancel is even possible.
>>
>> I'm not sure wh
Josh Berkus wrote:
However, this leaves aside Greg's point about snapshot age and
successive queries; does anyone dispute his analysis? Simon?
There's already a note on the Hot Standby TODO about unexpectly bad
max_standby_delay behavior being possible on an idle system, with no
suggested
Greg Stark writes:
> josh, nobody is talking about it because it doesn't make sense. you could
> only retry if it was the first query in the transaction and only if you
> could prove there were no side-effects outside the database and then you
> would have no reason to think the retry would be any
josh, nobody is talking about it because it doesn't make sense. you could
only retry if it was the first query in the transaction and only if you
could prove there were no side-effects outside the database and then you
would have no reason to think the retry would be any more likely to work.
greg
Robert Haas writes:
> On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure wrote:
>> IMNSHO, an 'in core' scheduler would be useful. however, I think
>> before you tackle a scheduler, we need proper stored procedures. Our
>> existing functions don't cut it because you can manage the transaction
>> st
Maciej Mrozowski wrote:
Hello,
Not sure whether it's appropriate list for feature requests though..
Would it be suitable to implement such variable declarations in PL/pgSQL so
that following (or similar) constructs would be possible?
DECLARE
tmpStruct (name varchar, foo integer, bar
On Mon, Mar 1, 2010 at 4:43 PM, Robert Haas wrote:
> On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure wrote:
>> IMNSHO, an 'in core' scheduler would be useful. however, I think
>> before you tackle a scheduler, we need proper stored procedures. Our
>> existing functions don't cut it because you c
Tom Lane wrote:
> Peter Eisentraut writes:
>> SQL standard:
>
>> ::=
>> NO SQL
>> | CONTAINS SQL
>> | READS SQL DATA
>> | MODIFIES SQL DATA
>
> Huh. I understand three of those, but what is the use of CONTAINS
> SQL? Seems like that would have to be the same as the last one,
> or maybe the n
Hello,
Not sure whether it's appropriate list for feature requests though..
Would it be suitable to implement such variable declarations in PL/pgSQL so
that following (or similar) constructs would be possible?
DECLARE
tmpStruct (name varchar, foo integer, bar boolean)[] := array[
('somen
Josh Berkus wrote:
> It's undeniable that auto-retry would be better from a user's
> perspective than a user-visible cancel. So if it's *reasonable*
> to implement, I think we should be working on it. I'm also very
> puzzled as to why nobody else wants to even discuss it; it's like
> some wier
On Mon, Mar 1, 2010 at 4:29 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> SQL standard:
>
>> ::=
>> NO SQL
>> | CONTAINS SQL
>> | READS SQL DATA
>> | MODIFIES SQL DATA
>
> Huh. I understand three of those, but what is the use of CONTAINS SQL?
> Seems like that would have to be the same as t
On 2/28/10 7:12 PM, Robert Haas wrote:
>> However, I'd still like to hear from someone with the requisite
>> > technical knowledge whether capturing and retrying the current query in
>> > a query cancel is even possible.
>
> I'm not sure who you want to hear from here, but I think that's a dead en
2010/3/1 Robert Haas :
> On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure wrote:
>> IMNSHO, an 'in core' scheduler would be useful. however, I think
>> before you tackle a scheduler, we need proper stored procedures. Our
>> existing functions don't cut it because you can manage the transaction
>>
On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure wrote:
> IMNSHO, an 'in core' scheduler would be useful. however, I think
> before you tackle a scheduler, we need proper stored procedures. Our
> existing functions don't cut it because you can manage the transaction
> state yourself.
Did you mean
Jaime Casanova írta:
> On Mon, Mar 1, 2010 at 2:56 PM, Peter Eisentraut wrote:
>
>> On tis, 2010-02-23 at 16:54 -0500, Jaime Casanova wrote:
>>
>>> 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
>>>
Theo Schlossnagle writes:
> I'm writing some extension and I have a hot code path that has a lot of
> double (C type) data and needs to output NUMERIC tuple data. The current
> methods I can find in the code to convert sprintf the double to a buffer and
> then invoke the numeric_in function on
Peter Eisentraut writes:
> SQL standard:
> ::=
> NO SQL
> | CONTAINS SQL
> | READS SQL DATA
> | MODIFIES SQL DATA
Huh. I understand three of those, but what is the use of CONTAINS SQL?
Seems like that would have to be the same as the last one, or maybe
the next-to-last one if you're prepared t
Theo Schlossnagle wrote:
Hello all,
I'm writing some extension and I have a hot code path that has a lot of double
(C type) data and needs to output NUMERIC tuple data. The current methods I
can find in the code to convert sprintf the double to a buffer and then invoke
the numeric_in funct
2010/3/1 Peter Eisentraut :
> On sön, 2010-02-21 at 11:00 +0100, Pavel Stehule wrote:
>> * Now I am working on migration of plpgpsm to plpgsql 9.0 base. I hope
>> so I understand SQL/PSM well so I am able to write production quality
>> implementation. If you like, I can integrate it to core. It can
On Mon, Mar 1, 2010 at 2:56 PM, Peter Eisentraut wrote:
> On tis, 2010-02-23 at 16:54 -0500, Jaime Casanova wrote:
>> 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
Hello all,
I'm writing some extension and I have a hot code path that has a lot of double
(C type) data and needs to output NUMERIC tuple data. The current methods I
can find in the code to convert sprintf the double to a buffer and then invoke
the numeric_in function on them. I've profile my
On sön, 2010-02-21 at 11:00 +0100, Pavel Stehule wrote:
> * Now I am working on migration of plpgpsm to plpgsql 9.0 base. I hope
> so I understand SQL/PSM well so I am able to write production quality
> implementation. If you like, I can integrate it to core. It can share
> about 40-50% code with p
On 3/1/10 11:43 AM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> Greg Stark wrote:
>>> For what it's worth Oracle has an option to have your standby
>>> intentionally hold back n minutes behind and I've seen that set to 5
>>> minutes.
>
>> yeah a lot of people are doing that intentionally...
On tis, 2010-02-23 at 16:54 -0500, Jaime Casanova wrote:
> 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?
SQL standard:
::=
NO
BTW, it looks like the MSVC build scripts don't bother to make sure that
USE_LIBXSLT is defined (or not) correctly --- at least I can't see any
reference to that symbol in the Windows-specific files. This is now
necessary to avoid disabling the xslt functionality in contrib/xml2.
I'm not too sure
Stefan Kaltenbrunner writes:
> Greg Stark wrote:
>> For what it's worth Oracle has an option to have your standby
>> intentionally hold back n minutes behind and I've seen that set to 5
>> minutes.
> yeah a lot of people are doing that intentionally...
It's the old DBA screwup safety valve ... d
Greg Stark wrote:
On Mon, Mar 1, 2010 at 7:21 PM, Josh Berkus wrote:
Completely aside from that, how many users are going to be happy with a
slave server which is constantly 5 minutes behind?
Uhm, well all the ones who are happy with our current warm standby
setup for one?
And all the ones
On Mon, Mar 1, 2010 at 7:21 PM, Josh Berkus wrote:
> Completely aside from that, how many users are going to be happy with a
> slave server which is constantly 5 minutes behind?
>
Uhm, well all the ones who are happy with our current warm standby
setup for one?
And all the ones who are looking f
On Mon, Mar 1, 2010 at 1:39 PM, Tom Lane wrote:
> Anybody have an opinion about whether to try to improve the error
> response exhibited in bug #5352?
> http://archives.postgresql.org/message-id/201003010922.o219m9lk016...@wwwmaster.postgresql.org
>
> Currently, if the first variable named after I
> So I think the primary solution currently is to raise max_standby_age.
>
> However there is a concern with max_standby_age. If you set it to,
> say, 300s. Then run a 300s query on the slave which causes the slave
> to fall 299s behind. Now you start a new query on the slave -- it gets
> a snaps
Marc G. Fournier wrote:
Is there a higher then normal amount of earthquakes happening
recently? haiti, japan just had one for 6.9, there was apparently one
in illinos a few weeks back, one on the Russia/China/N.Korean border
and now Chile?
Random events come in bunches - something I always
On Mon, Mar 1, 2010 at 5:50 PM, Josh Berkus wrote:
> I don't think that defer_cleanup_age is a long-term solution. But we
> need *a* solution which does not involve delaying 9.0.
So I think the primary solution currently is to raise max_standby_age.
However there is a concern with max_standby_a
Anybody have an opinion about whether to try to improve the error
response exhibited in bug #5352?
http://archives.postgresql.org/message-id/201003010922.o219m9lk016...@wwwmaster.postgresql.org
Currently, if the first variable named after INTO is a rowtype variable,
we just stop parsing the INTO c
Greg Stark wrote:
So fwiw Narwhal says EACCESS is working.
dawn_bat is also working. Both of these build using Mingw/gcc, not MSVC.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
Josh Berkus wrote:
And I think we can measure bloat in a pgbench test, no? When I get a
chance, I'll run one for a couple hours and see the difference that
cleanup_age makes.
The test case I attached at the start of this thread runs just the
UPDATE to the tellers table. Running something
On 2/28/10 7:00 PM, Greg Smith wrote:
> The main problem with setting vacuum_defer_cleanup_age high isn't
> showing it works, it's a pretty simple bit of code. It's when you
> recognize that it penalizes all cleanup all the time, whether or not the
> standby is actually executing a long-running qu
"Kevin Grittner" writes:
> Exactly. With Fedora respecting the standard in this regard, I'm
> convinced we should, too. In reviewing things based on Peter's
> question, I did start to have doubts about *not* special-casing
> "status" -- it has its own set of values and 5 is not assigned, so
> us
Tom Lane wrote:
> I think though that the answer to Peter's question is that "stop"
> has to be special cased to some extent, because it is not supposed
> to be an error to stop a service that's not running. If it's not
> even installed, then a fortiori it's not running, so the exit code
> *mus
Tom Lane wrote:
Eh? The buildfarm sends out a daily status-change summary email? To where?
See
http://pgfoundry.org/mail/?group_id=140
I'm subscribed to pgbuildfarm-status-green ... and the archives for
it match my local log, which says there hasn't been a message since
Friday. T
Andrew Dunstan writes:
> Tom Lane wrote:
>> No, it ignores it if libxml2 isn't available. It can be built with
>> or without libxslt though.
> ugh.
> Maybe we need to set up a dummy function or two if not building with
> xslt, like we do with the XML functions if not building with libxml.
Rig
Robert Haas writes:
> On Mon, Mar 1, 2010 at 10:01 AM, Tom Lane wrote:
>> BTW, in case anyone with admin privileges is paying attention, the
>> buildfarm (a) is about two hours off on its system clock again,
>> and (b) hasn't sent out a daily status-change summary email since
>> Friday.
> Eh? T
Robert Haas wrote:
On Mon, Mar 1, 2010 at 10:01 AM, Tom Lane wrote:
BTW, in case anyone with admin privileges is paying attention, the
buildfarm (a) is about two hours off on its system clock again,
and (b) hasn't sent out a daily status-change summary email since
Friday.
Eh? The b
Tom Lane wrote:
Robert Haas writes:
I thought the contrib makefile was set up to ignore xml2 if libxslt
wasn't being used.
No, it ignores it if libxml2 isn't available. It can be built with
or without libxslt though.
ugh.
Maybe we need to set up a du
"Kevin Grittner" writes:
> I can't see a clear case either way. I know I *have* seen scripts
> which took the trouble to special-case it, but I just poked around
> and found that it seems much less common than unconditionally using
> "exit 5". Does anyone know of an environment where it matters?
On Mon, Mar 1, 2010 at 10:01 AM, Tom Lane wrote:
> BTW, in case anyone with admin privileges is paying attention, the
> buildfarm (a) is about two hours off on its system clock again,
> and (b) hasn't sent out a daily status-change summary email since
> Friday.
Eh? The buildfarm sends out a dail
Robert Haas writes:
> I thought the contrib makefile was set up to ignore xml2 if libxslt
> wasn't being used.
No, it ignores it if libxml2 isn't available. It can be built with
or without libxslt though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
On Mon, Mar 1, 2010 at 10:32 AM, Tom Lane wrote:
> In yet another demonstration that no good deed goes unpunished, I see
> that my addition of regression tests to contrib/xml2 is still a few
> bricks shy of a load. Buildfarm member pika is failing on it, and the
> reason is clear upon inspection:
2010/3/1 Zdenek Kotala :
> Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100:
>> On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala wrote:
>> > Hi all,
>> >
>> > I got following stack:
>> >
>> > fd7ffed14b70 strlen () + 40
>> > fd7ffed71665 snprintf () + e5
>> > fd7fff36d088 pg_GSS_sta
In yet another demonstration that no good deed goes unpunished, I see
that my addition of regression tests to contrib/xml2 is still a few
bricks shy of a load. Buildfarm member pika is failing on it, and the
reason is clear upon inspection: pika is configured --with-libxml
but not --with-libxslt,
So fwiw Narwhal says EACCESS is working.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut wrote:
> On tor, 2009-08-20 at 10:31 -0500, Kevin Grittner wrote:
>> (2) It doesn't exit with zero for a missing executable unless
>> the request is "stop". It uses 5, which means "program is not
>> installed".
>
> Using 5 is correct, but special-casing "stop" is kind of useles
Magnus Hagander writes:
> Actually, I think that may be your problem - you are testing against
> EPERM instead of EACCESS. On my linux manpage, EPERM isn't even a
> valid return code from open().
Yeah, I had just come to the same conclusion upon seeing the buildfarm
still pink this morning. On m
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
... The reason for that behavior is that xpath_table runs through
the XPATH_NODESET results generated by the various XPaths and dumps the
k'th one of each into the k'th output row generated for the current
input row.
You might want to look at _dosmaperror() in src/port/win32error.c - it
contains the different win32 error ccodes that we match to EACCESS. I
don't see us mapping *anything* to EPERM.
Actually, I think that may be your problem - you are testing against
EPERM instead of EACCESS. On my linux manpage,
This isn't working. The Windows ports are all saying "permission
denied" but apparently that's not because errno is set to EPERM.
Anyone know how to detect "permission denied" errors from open() on
windows?
On Mon, Mar 1, 2010 at 12:04 AM, Greg Stark wrote:
> Log Message:
> ---
> add EPER
On mån, 2010-02-22 at 10:32 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote:
> > > Simon Riggs wrote:
> > > >
> > > > On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
> > > > > Tom Lane wrote:
> > > > > > Peter Eisentraut writes
On tor, 2009-08-20 at 10:31 -0500, Kevin Grittner wrote:
> (2) It doesn't exit with zero for a missing executable unless the
> request is "stop". It uses 5, which means "program is not installed".
Using 5 is correct, but special-casing "stop" is kind of useless. Every
other init script I have e
How about a totally different approach?
What if all queries and plans of all queries, simple and prepared, were
pre-planned and cached always, persistent?
For prepared statements with >= 1 parameters, histogram and mcv
information could be used to search the plan space for interesting
plans. M
Bruce Momjian wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Where are we on this issue?
Oops I forgot it completely.
I have a little improved version and would post it tonight.
Ah, very good. Thanks.
Attached is an improve
Takahiro Itagaki wrote:
Yeb Havinga wrote
I'm wondering if there would be community support for adding using the
execute message with a rownum > 0 in the c libpq client library, as it
is used by the jdbc driver with setFetchSize.
The setFetchSize for libpq is difficult because of the in
On 27/02/2010 07:52, Gokulakannan Somasundaram wrote:
Tom,
I just took the patch, but it seems to be in binary format. Can you send
me the patch to me?
gunzip shuould do the trick
Thanks,
Gokul.
On Sat, May 30, 2009 at 3:12 AM, Tom Lane wrote:
Josh Berkus writes:
Tom,
Is anyone in
Yeb Havinga wrote:
> I'm wondering if there would be community support for adding using the
> execute message with a rownum > 0 in the c libpq client library, as it
> is used by the jdbc driver with setFetchSize.
The setFetchSize for libpq is difficult because of the interface
mismatch -- lib
Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100:
> On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala wrote:
> > Hi all,
> >
> > I got following stack:
> >
> > fd7ffed14b70 strlen () + 40
> > fd7ffed71665 snprintf () + e5
> > fd7fff36d088 pg_GSS_startup () + 88
> > fd7fff36d43a
78 matches
Mail list logo
