On Thu, Mar 25, 2010 at 9:55 PM, Heikki Linnakangas
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 streamed from master in
> standby mod
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
2010/3/26 David Fetter :
> 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 wh
On 26 March 2010 00:14, Marko Tiikkaja 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 is when you want to w
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 t
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 Thu, Mar 25, 2010 at 5:17 PM, David Fetter 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 sel
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 out
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 ver
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
>> 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.
--
Josh Berkus 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 declaration.
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.
--
I wrote:
> ... lookee what we have here:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguar&dt=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:
http://buildfarm.postgresql.org/
Tom Lane wrote:
> Alvaro Herrera 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 which it checks s
On Tue, Mar 16, 2010 at 10:35 AM, Fujii Masao 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 suggest that we
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?
And,
On Thu, Mar 25, 2010 at 8:55 AM, Heikki Linnakangas
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. We can make
> it a WARNING too, wh
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
>>
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 ---
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 sta
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
(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
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.
>
> Pl
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
On Thu, 2010-03-25 at 11:08 +0900, Fujii Masao wrote:
> On Thu, Mar 25, 2010 at 8:23 AM, Simon Riggs 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 server farm at
Tom Lane wrote:
> Fujii Masao 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 think that the st
On Thu, 2010-03-25 at 11:08 +0900, Fujii Masao wrote:
> On Thu, Mar 25, 2010 at 8:23 AM, Simon Riggs 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 server farm at
28 matches
Mail list logo