On Wed, 2004-07-14 at 03:31, Christopher Kings-Lynne wrote:
Can you give us some suggestions of what kind of stuff to test? Is
there a way we can artificially kill the backend in all sorts of nasty
spots to see if recovery works? Does kill -9 simulate a 'power off'?
I was hoping some
On Tue, Jul 13, 2004 at 06:29:51PM +0200, Peter Eisentraut wrote:
Bruce Momjian wrote:
I am not sure what can be done to solve this in the future. There
are only a limited number of us who have the experience and time to
review and comment on very complex patches.
The issue as I see it
Magnus Hagander wrote:
not to mention the
more basic problem that the comments will now be wrong.
That, however, it is correct :-( Sloppy.
How about a text along the line of:
CAUTION: Configuring the system for trust authentication
allows any
local user to connect using any
On 7/13/2004 10:23 PM, Christopher Kings-Lynne wrote:
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's
To fill you in a little, I am the PostgreSQL CORE team member Jan Wieck,
who burned Afilias payroll hours to implement the ARC buffer replacement
strategy. The feature has been completed and fully contributed under the
BSD license way ahead of any possible release schedule. I have had
several
On 7/14/2004 5:00 AM, Christopher Kings-Lynne wrote:
Yes, but it has been committed, it will be released - the only thing is
that people will have to wait a few more months for it. My point was
Just a few more months? That is exactly what I was asking for, put some
of the stuff into 7.6 so it
The recovery mechanism doesn't rely upon you knowing 1 or 3. The
recovery reads pg_control (from the backup) and then attempts to
de-archive the appropriate xlog segment file and then starts
rollforward
Unfortunately this only works if pg_control was the first file to be
backed up (or by
On Wed, 2004-07-14 at 05:08, Tom Lane wrote:
Oliver Elphick [EMAIL PROTECTED] writes:
...
The point of this explanation is that as Debian maintainer I would have
to disable any procedures that attempt to edit these conffiles, or at
least ensure that their operation is under package
Simon Riggs [EMAIL PROTECTED] writes:
I've not done power off tests, yet. They need to be done just to
check...actually you don't need to do this to test PITR...
I agree, power off is not really the point here. What we need to check
into is (a) the mechanics of archiving WAL segments and (b)
My answers:
Q1: Should Portals successfully created within the failed subxact
be closed? Or should they remain open?
no for protocol level
I can understand a yes to this one for sql level, because it will be
hard to clean up by hand :-( But I like the analogy to hold cursors,
so I would
Jan Wieck wrote:
On 7/14/2004 5:00 AM, Christopher Kings-Lynne wrote:
Yes, but it has been committed, it will be released - the only thing
is that people will have to wait a few more months for it. My point was
Just a few more months? That is exactly what I was asking for, put some
of the
On 14 Jul, Simon Riggs wrote:
PITR Patch v5_1 just posted has Point in Time Recovery working
Still some rough edgesbut we really need some testers now to give
this a try and let me know what you think.
Klaus Naumann and Mark Wong are the only [non-committers] to have tried
to run
On Tue, Jul 13, 2004 at 04:57:06PM -0400, Tom Lane wrote:
I've been thinking about what to do with cursors in subtransactions.
The problem really includes both cursors (created with DECLARE CURSOR)
and portals (created with the V3-protocol Bind message) since they are
the same kind of animal
Tom,
As much as I can understand the arguments -- many of them performance-oriented
-- for handling Portals non-transactionally, I simply don't see how we can do
it and not create huge problems for anyone who uses both cursors and NTs
together ... as those who use either are liable to do.
Jan Wieck wrote:
On 7/14/2004 5:00 AM, Christopher Kings-Lynne wrote:
Yes, but it has been committed, it will be released - the only thing is
that people will have to wait a few more months for it. My point was
Just a few more months? That is exactly what I was asking for, put some
Jan Wieck wrote:
On 7/13/2004 10:23 PM, Christopher Kings-Lynne wrote:
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
Jan,
What touches me here is the fact that the PostgreSQL Open Source Project
under the BSD license seems starting to care a lot more about some press
releases and silly news splashes, than to care about real features
contributed under the terms and conditions of the BSD license by serious
I wrote:
I've worked out a scheme that should adequately detect encoding
mismatches in initdb.
Done.
Karel pointed me to some other projects that are trying to do the same
thing, and they are no smarter than what we have now.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Wed, 14 Jul 2004, Bruce Momjian wrote:
What are you talking about? Are you suggesting Fujitsu's features are
getting more attendtion than ARC for some political reason? You think
nested transactions and tablespaces are just press release features?
All those features are being developed by the
On 7/14/2004 1:13 PM, Bruce Momjian wrote:
What are you talking about? Are you suggesting Fujitsu's features are
getting more attendtion than ARC for some political reason? You think
nested transactions and tablespaces are just press release features?
All those features are being developed by
On Wed, 14 Jul 2004, Bruce Momjian wrote:
The community decides when to stop development. Neither Afilias nor any
other company has that control. If you want the development cycle cut
shorter, make your case to the community --- if you win, great, if not,
don't gripe about it.
Core decides
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, Jul 13, 2004 at 04:57:06PM -0400, Tom Lane wrote:
I've been thinking about what to do with cursors in subtransactions.
So within this proposal, a query executed by normal means will get its
resources saved in the transaction ResourceOwner?
No,
On Wed, 2004-07-14 at 16:55, [EMAIL PROTECTED] wrote:
On 14 Jul, Simon Riggs wrote:
PITR Patch v5_1 just posted has Point in Time Recovery working
Still some rough edgesbut we really need some testers now to give
this a try and let me know what you think.
Klaus Naumann and
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, Jul 13, 2004 at 04:57:06PM -0400, Tom Lane wrote:
I've been thinking about what to do with cursors in subtransactions.
So within this proposal, a query executed by normal means will get its
resources saved in the transaction
Marc G. Fournier wrote:
The big problem that I see with how this feature freeze/beta/release has
gone down is that we have *alot* of big items that are/were being worked
on (ARC, BGWriter, auto_vacuum, PITR, Nested Xacts), and only so much man
power at the reviewer stage ... we *should*
Marc G. Fournier wrote:
On Wed, 14 Jul 2004, Bruce Momjian wrote:
The community decides when to stop development. Neither Afilias nor any
other company has that control. If you want the development cycle cut
shorter, make your case to the community --- if you win, great, if not,
Mike Rylander wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, Jul 13, 2004 at 04:57:06PM -0400, Tom Lane wrote:
I've been thinking about what to do with cursors in subtransactions.
So within this proposal, a query executed by normal means will get its
resources
On Wed, 2004-07-14 at 10:57, Zeugswetter Andreas SB SD wrote:
The recovery mechanism doesn't rely upon you knowing 1 or 3. The
recovery reads pg_control (from the backup) and then attempts to
de-archive the appropriate xlog segment file and then starts
rollforward
Unfortunately this
Josh Berkus wrote:
Tom,
As much as I can understand the arguments -- many of them performance-oriented
-- for handling Portals non-transactionally, I simply don't see how we can do
it and not create huge problems for anyone who uses both cursors and NTs
together ... as those who use either are
Alvaro Herrera wrote:
On the other hand, some people supported the idea that v3 Bind portals
should behave nontransactionally, while DECLARE portals should behave
transactionally. Maybe we could make that a property of the portal, or
even a user-selectable property (where we would define a
Hi Peter,
Compile the attached test program and then run
It doesn't even compile in a OpenBSD box. The langinfo.h doesn't have 'CODESET' symbol.
for x in `locale -a`; do LC_ALL=$x ./test; done | sort -u
OpenBSD doesn't support locale at all (correct me if I'm wrong).
If you don't have a
On Tue, 2004-07-13 at 23:03, Marc G. Fournier wrote:
As a community, I don't think we should be 'supporting' anything older
then the last STABLE ...
I agree, but that message isn't clearly stated anywhere. The lists are
full of people running very old releases - and everybody keeps having
Bruce Momjian wrote:
I was thinking of something much simpler where Jan would create an ARC
patch against 7.4.X and have it either in /contrib for 7.4.X or on our
ftp servers, or on a web site. I could create a mechanism so SELECT
version() would display Jan's add-on.
:-(
I was asking to add the
On Wed, 2004-07-14 at 21:02, Bruce Momjian wrote:
Marc G. Fournier wrote:
The big problem that I see with how this feature freeze/beta/release has
gone down is that we have *alot* of big items that are/were being worked
on (ARC, BGWriter, auto_vacuum, PITR, Nested Xacts), and only so much
I noticed that compiling with 5_1 patch applied fails due to
XLOG_archive_dir being removed from xlog.c , but
src/backend/commands/tablecmds.c still uses it.
I did the following to tablecmds.c :
5408c5408
extern char XLOG_archive_dir[];
---
extern char
We can have a major feature deadline, then a minor feature deadline. I
particularly liked the idea of 1 July as the major feature deadline,
then 14 July as major-feature-tweak deadline. That funnels things better
to cater for the manpower available.
That being said, your PITR patch still hasn't
Hi, folks.
My colleages and I are planning to test PITR after the 7.5 beta release.
Now we are desinging test items, but some specification are enough clear
(to us).
For example, we are not clear which resouce manager order to store log
records.
- some access method (like B-tree) require to log
I talked to Tom on the phone today and and I think we have a procedure
for doing backup/restore in a fairly foolproof way.
As outlined below, we need to record the start/stop and checkpoint WAL
file names and offsets, and somehow pass those on to restore. I think
any system that requires users
On Thu, 15 Jul 2004, Christopher Kings-Lynne wrote:
We can have a major feature deadline, then a minor feature deadline. I
particularly liked the idea of 1 July as the major feature deadline,
then 14 July as major-feature-tweak deadline. That funnels things better
to cater for the manpower
Christopher Kings-Lynne wrote:
We can have a major feature deadline, then a minor feature deadline. I
particularly liked the idea of 1 July as the major feature deadline,
then 14 July as major-feature-tweak deadline. That funnels things better
to cater for the manpower available.
That
On Wed, Jul 14, 2004 at 03:11:54PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, Jul 13, 2004 at 04:57:06PM -0400, Tom Lane wrote:
I've been thinking about what to do with cursors in subtransactions.
So within this proposal, a query executed by normal means will
OK, I talked to Tom about this patch and I understand the issues now.
I think the best solution will be to have the postmaster start a child
process that can read the guc variables and create a log file based on
it contents. The child would be responsible to create a new log file
every X
Alvaro Herrera [EMAIL PROTECTED] writes:
Do you want me to do the legwork for this to happen, or was your initial
plan to do it yourself? Either way is OK with me ...
I'm working on it, should have it done in a day or so.
regards, tom lane
43 matches
Mail list logo
