On Thu, 2010-03-25 at 11:08 +0900, Fujii Masao wrote:
On Thu, Mar 25, 2010 at 8:23 AM, Simon Riggs si...@2ndquadrant.com wrote:
PANICing won't change the situation, so it just destroys server
availability. If we had 1 master and 42 slaves then this behaviour would
take down almost the whole
Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
OK. How about making the startup process emit WARNING, stop WAL replay and
wait for the presence of trigger file, when an invalid record is found?
Which keeps the server up for readonly queries. And if the trigger file is
found, I
On Thu, 2010-03-25 at 11:08 +0900, Fujii Masao wrote:
On Thu, Mar 25, 2010 at 8:23 AM, Simon Riggs si...@2ndquadrant.com wrote:
PANICing won't change the situation, so it just destroys server
availability. If we had 1 master and 42 slaves then this behaviour would
take down almost the whole
On Thu, 2010-03-25 at 10:11 +0200, Heikki Linnakangas wrote:
PANIC seems like the appropriate solution for now.
It definitely is not. Think some more.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Simon Riggs wrote:
On Thu, 2010-03-25 at 11:08 +0900, Fujii Masao wrote:
And if the trigger file is
found, I think that the startup process should emit a FATAL, i.e., the
server should exit immediately, to prevent the server from becoming the
primary in a half-finished state.
Please
(cc'ing docs list)
Simon Riggs wrote:
The lack of docs begins to show a lack of coherent high-level design
here.
Yeah, I think you're right. It's becoming hard to keep track of how it's
supposed to behave.
By now, I've forgotten what this thread was even about. The major
design decision in
Simon Riggs wrote:
On Thu, 2010-03-25 at 10:11 +0200, Heikki Linnakangas wrote:
PANIC seems like the appropriate solution for now.
It definitely is not. Think some more.
Well, what happens now in previous versions with pg_standby et al is
that the standby starts up. That doesn't seem
Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2010-03-25 at 10:11 +0200, Heikki Linnakangas wrote:
PANIC seems like the appropriate solution for now.
It definitely is not. Think some more.
Well, what happens now in previous versions with pg_standby et al is
that the standby starts
Fujii Masao wrote:
sources = ~failedSources;
failedSources |= readSource;
The above lines in XLogPageRead() seem not to be required in normal
recovery case (i.e., standby_mode = off). So how about the attached
patch?
*** 9050,9056 next_record_is_invalid:
--- 9047,9056
Fujii Masao wrote:
On second thought, the following lines seem to be necessary just after
calling XLogPageRead() since it reads new WAL file from another source.
if (readSource == XLOG_FROM_STREAM || readSource == XLOG_FROM_ARCHIVE)
emode = PANIC;
else
On Thu, Mar 25, 2010 at 8:55 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* If a corrupt WAL record is found in archive or streamed from master in
standby mode, throw WARNING instead of PANIC, and keep trying. In
archive recovery (ie. standby_mode=off) it's still a PANIC.
Hi,
I am trying to put the SP-Gist package, a general index framework for
space partitioning trees , into Postgresql source code.
SP-Gist was developed for postgresql 8.0. However, now it does not
work with the new version.
So, for the submitted patch, what version of postgresql is required?
On Tue, Mar 16, 2010 at 10:35 AM, Fujii Masao masao.fu...@gmail.com wrote:
Just replacing PQexec() with PQsendQuery() is pretty straightforward, we
could put that replacement in a file in port/win32. Replacing
PQconnectdb() is more complicated because you need to handle connection
timeout. I
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I have come up with the attached patch. I haven't tested it fully yet,
and I need to backport it. The gist of it is: we can't simply remove
the pg_db_role_setting tuple, we need to ask GUC to reset the settings
array, for
I wrote:
... lookee what we have here:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguardt=2010-03-24%2004:00:07
Modifying the code to print the actual timestamps resulted in a wealth
of information that can be dredged from the postmaster log here:
All,
It looks like pg_dump was never modified to include conditional
triggers. If you look in pg_dump.c, there's no provision to dump the
FOR UPDATE OF part of the trigger declaration.
This was discovered by Dave Olszewski while testing conditional triggers.
--
Josh Berkus j...@agliodbs.com writes:
It looks like pg_dump was never modified to include conditional
triggers. If you look in pg_dump.c, there's no provision to dump the
FOR UPDATE OF part of the trigger declaration.
That proves nothing; it could be relying on server-side code to produce
the
This was discovered by Dave Olszewski while testing conditional triggers.
Please show a specific example of what you're worried about.
I'll get you a reproduceable test case later today. In our testing, the
conditional part of the trigger was not being dumped.
--
On Thu, 2010-03-25 at 12:15 +0200, Heikki Linnakangas wrote:
(cc'ing docs list)
Simon Riggs wrote:
The lack of docs begins to show a lack of coherent high-level design
here.
Yeah, I think you're right. It's becoming hard to keep track of how it's
supposed to behave.
Thank you for
On Thu, 2010-03-25 at 12:26 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2010-03-25 at 10:11 +0200, Heikki Linnakangas wrote:
PANIC seems like the appropriate solution for now.
It definitely is not. Think some more.
Well, what happens now in previous versions with
On Wed, Mar 24, 2010 at 06:31:59PM +0100, A. Kretschmer wrote:
Hello @all,
I know, i can do:
select * from (select ... row_number() over (...) ...) foo where
row_number N
to limit the rows per group, but the inner select has to retrieve
the whole set of records and in the outer select
On Thu, Mar 25, 2010 at 5:17 PM, David Fetter da...@fetter.org wrote:
On Wed, Mar 24, 2010 at 06:31:59PM +0100, A. Kretschmer wrote:
Hello @all,
I know, i can do:
select * from (select ... row_number() over (...) ...) foo where
row_number N
to limit the rows per group, but the inner
Hi,
I was wondering if it might be worth making ROW/ROWS optional for
OFFSET and FETCH clauses? And can ONLY be optional too?
So:
OFFSET start { ROW | ROWS }
FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY
Would become
OFFSET start [ ROW | ROWS ]
FETCH { FIRST | NEXT } [ count ] [ ROW |
On 3/26/10 2:01 AM +0200, Thom Brown wrote:
I was wondering if it might be worth making ROW/ROWS optional for
OFFSET and FETCH clauses? And can ONLY be optional too?
AIUI the only time you'd want to use that syntax is when you want to
write (theoretically) portable code, and making parts of
On 26 March 2010 00:14, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
On 3/26/10 2:01 AM +0200, Thom Brown wrote:
I was wondering if it might be worth making ROW/ROWS optional for
OFFSET and FETCH clauses? And can ONLY be optional too?
AIUI the only time you'd want to use that syntax
2010/3/26 David Fetter da...@fetter.org:
On Wed, Mar 24, 2010 at 06:31:59PM +0100, A. Kretschmer wrote:
Hello @all,
I know, i can do:
select * from (select ... row_number() over (...) ...) foo where
row_number N
to limit the rows per group, but the inner select has to retrieve
the whole
I apologize for my silence, as I've been busy reading up more on the
internals of PostgreSQL.
From what I can tell, a big problem with my jails idea (as well as the
variables Robert described) is that there really isn't a way to store
context in the backend specifically for the end client (e.g. a
On Thu, Mar 25, 2010 at 9:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* Fix the bug of a spurious PANIC in archive recovery, if the WAL ends
in the middle of a WAL record that continues over a WAL segment boundary.
* If a corrupt WAL record is found in archive or
28 matches
Mail list logo
