On Fri, Jul 16, 2004 at 01:32:01AM -0400, lists wrote:
LOG: ReadRecord: unexpected pageaddr 0/33A4000 in log file 0, segment
5, offset 3817472
LOG: redo is not required
PANIC: XLogWrite: write request 0/53A4000 is past end of log 0/53A4000
LOG: startup process (pid 16068) was terminated
thank you for replying.
Alvaro Herrera wrote:
LOG: ReadRecord: unexpected pageaddr 0/33A4000 in log file 0, segment
5, offset 3817472
LOG: redo is not required
PANIC: XLogWrite: write request 0/53A4000 is past end of log 0/53A4000
LOG: startup process (pid 16068) was terminated by signal 6
Hi,
Can I change pg_dump to never use the AUTHORIZATION clause and use OWNER
TO instead? It would make things a lot simpler, especially in the case
when dumping that the public schema has had its ownership changed.
This is what the comment says:
* Note that ownership is shown in the
SELECT EXTRACT(EPOCH FROM TIMESTAMP '2003-01-01 11:23:44');
Yeah, but I think Michael's question had to do with going the other
way (numeric to timestamp).
Sorry,
SELECT EXTRACT(TIMESTAMP FROM EPOCH '123412341234');
Chris
---(end of broadcast)---
LOG: ReadRecord: unexpected pageaddr 0/33A4000 in log file 0, segment
5, offset 3817472
LOG: redo is not required
PANIC: XLogWrite: write request 0/53A4000 is past end of log 0/53A4000
LOG: startup process (pid 16068) was terminated by signal 6
LOG: aborting startup due to startup process
On Fri, Jul 16, 2004 at 02:09:33PM +0800, Christopher Kings-Lynne wrote:
LOG: ReadRecord: unexpected pageaddr 0/33A4000 in log file 0, segment
5, offset 3817472
LOG: redo is not required
PANIC: XLogWrite: write request 0/53A4000 is past end of log 0/53A4000
LOG: startup process (pid
On Fri, Jul 16, 2004 at 01:55:13AM -0400, lists wrote:
thank you for replying.
Alvaro Herrera wrote:
LOG: ReadRecord: unexpected pageaddr 0/33A4000 in log file 0, segment
5, offset 3817472
LOG: redo is not required
PANIC: XLogWrite: write request 0/53A4000 is past end of log 0/53A4000
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 15, 2004 10:03 PM
To: Dann Corbit
Cc: Oliver Jowett; Magnus Hagander; Hackers;
[EMAIL PROTECTED]
Subject: Re: [pgsql-hackers-win32] [HACKERS] Weird new time zone
Dann Corbit [EMAIL PROTECTED]
On Jul 16, 2004, at 3:08 PM, Christopher Kings-Lynne wrote:
SELECT EXTRACT(TIMESTAMP FROM EPOCH '123412341234');
That's a really interesting idea! Makes for a much more consistent
syntax for our other functions. ISTM this might require a native EPOCH
datatype. I wouldn't want to encourage people
On Fri, 2004-07-16 at 04:49, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2004-07-16 at 00:01, Alvaro Herrera wrote:
My manpage for signal(2) says that you shouldn't assign SIG_IGN to
SIGCHLD, according to POSIX.
So - I should be setting this to SIG_DFL and thats good
Bruce Momjian wrote:
Andreas Pflug wrote:
You do something that splits the value into directory name and file name
and removes every letter after %.
/var/log
postgresql.log.%-%-%_%%%
Another idea is to allow filename wildcards in the listing so it
becomes:
SELECT *
It occurs to me that with a check this thorough, we might
be able to
finesse the problem on Windows with the system returning very
nonstandard timezone abbreviations.
It does *not* pick up my timezone.
Drat. I assume from your domain name that Europe/Stockholm
would actually be
Hi guys,
during my study i have to du some practical work. i must extend postgresql with some
sampling algorithms. therefore i implemented some trigger functions. it works fine.
but now i have to do some changes concerning the parser, particularly analyze.c . if a
user sends an create table
I'm aiming for the minimum feature set - which means we do need to take
care over whether that set is insufficient and also to pull any part
that doesn't stand up to close scrutiny over the next few days.
As you can see, we are still chewing on NT. What PITR features are
missing? I
Over-simplistic answers are not what we need here. The
data structure
you quote cannot even tell what DST transition dates Windows thinks
are in effect this year, let alone what it thinks the dates were in
past years.
Yes, there are other calls for that, obviously. I sent to
Magnus Hagander [EMAIL PROTECTED] writes:
I thought the issue under question was to find out what the
time zone was.
Nope, we already had that. The issue is that the names are not the same
as the one used in zic/unix, so there is nothing to match on.
Right. The problem we are actually
Andreas Pflug [EMAIL PROTECTED] writes:
In-use check is easy for the backend, if the syslog process publishes
the current logfile's timestamp in sharedmem.
You really haven't absorbed any of the objections I've raised, have you?
I don't want the log process connected to shared mem at *all*,
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
We only need to tell people to backup pg_control first. The rest was only
intended to enforce
1. that pg_control is the first file backed up
2. the dba uses a large enough PIT (or xid) for restore
Right, but I think Bruce's point is that
Andreas Pflug wrote:
OK, it would be nice if we could do a sed operation like:
sed 's/%./*/g'
but I don't know a way to do that without defining a function or pulling
in a procedural language, but if we could do it we could do:
pg_dir(echo log_destination | sed
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
We only need to tell people to backup pg_control first. The rest was only
intended to enforce
1. that pg_control is the first file backed up
2. the dba uses a large enough PIT (or xid) for restore
Right, but I think Bruce's point is
Magnus Hagander [EMAIL PROTECTED] writes:
At the moment I like Oliver Jowett's idea of defining best
as the one that matches furthest back.
Sounds reasonable to me. As long as a clear warning is put in the log
whenever something is picked that is not a perfect match,
Define perfect match.
Bruce Momjian [EMAIL PROTECTED] writes:
Also, when you are in recovery mode, how do you get out of recovery
mode, meaning if you have a power failure, how do you prevent the system
from doing another recovery? Do you remove the recovery.conf file?
I do not care for the idea of a recovery.conf
then on restore once all the files are restored move the
pg_control.backup to its original name. That gives us the checkpoint
wal/offset but how do we get the start/stop information. Is that not
required?
The checkpoint wal/offset is in pg_control, that is sufficient start
information.
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Do we need a checkpoint after the archiving
starts but before the backup begins?
No.
Actually yes. You have to start at a checkpoint record when replaying
the log, so if no checkpoint occurred between starting to archive WAL
and starting
Do we need a checkpoint after the archiving
starts but before the backup begins?
No.
Actually yes.
Sorry, I did incorrectly not connect 'archiving' with the backed up xlogs :-(
So yes, you need one checkpoint after archiving starts. Imho turning on xlog
archiving should issue such a
Bruce Momjian wrote:
This seems quite involved. Can we get the basic functionality I
described first?
On the way.
Also I am not sure how all this information is going
to be passed from the logging process to the backend requesting the
information, and it seems overly complicated.
There's *no*
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
In-use check is easy for the backend, if the syslog process publishes
the current logfile's timestamp in sharedmem.
You really haven't absorbed any of the objections I've raised, have you?
I don't want the log process connected to shared
On Fri, 2004-07-16 at 16:58, Zeugswetter Andreas SB SD wrote:
Do we need a checkpoint after the archiving
starts but before the backup begins?
No.
Actually yes.
Sorry, I did incorrectly not connect 'archiving' with the backed up xlogs :-(
So yes, you need one checkpoint after
On Fri, 2004-07-16 at 15:27, Bruce Momjian wrote:
Also, when you are in recovery mode, how do you get out of recovery
mode, meaning if you have a power failure, how do you prevent the system
from doing another recovery? Do you remove the recovery.conf file?
That was the whole point of the
On Fri, 2004-07-16 at 16:25, Zeugswetter Andreas SB SD wrote:
I think the filename 'recovery.conf' is misleading, since it is not a
static configuration file, but a command file for one recovery.
How about 'recovery.command' then 'recovery.inprogress', and on recovery
completion it should
Anja Klein wrote:
how can i tell postgres. that it should only create the sample table,
when the original table to be created has the name origin or
something like that? or that it should only act, if some user wants
to create the table, not postgres itself?
You would presumably do a strcmp()
Andreas Pflug wrote:
Bruce Momjian wrote:
This seems quite involved. Can we get the basic functionality I
described first?
On the way.
Also I am not sure how all this information is going
to be passed from the logging process to the backend requesting the
information, and it
Andreas Pflug wrote:
Bruce Momjian wrote:
This seems quite involved. Can we get the basic functionality I
described first?
Current workable patch.
Some questions/limitations:
- How's the official way to restrict pg_* functions to superuser only
Very crudely :-)
Simon Riggs wrote:
On Fri, 2004-07-16 at 16:58, Zeugswetter Andreas SB SD wrote:
Do we need a checkpoint after the archiving
starts but before the backup begins?
No.
Actually yes.
Sorry, I did incorrectly not connect 'archiving' with the backed up xlogs :-(
So yes,
Tom Lane wrote:
Ian Burrell [EMAIL PROTECTED] writes:
We have user-defined aggregates written in C running inside the server.
We are running into some memory management issues and wondering what
is the best way to solve the problem.
The state of the aggregates is a structure with a pointer to
I noticed a curious thing (not sure if by design or not).
While using the PQExecPrepared interface, the statement name passed to
the function (as a const char*) has to be in lower case to get it to
work. I kind of understand why this is, but it is kind of weird that
passing the exact same
Bruce Momjian wrote:
- How's the official way to restrict pg_* functions to superuser only
Very crudely :-)
Got it.
'nother question: Is reading the logfile a task that may be allowed to
superusers only? I don't think so, though acls might apply.
Uh, that seems fine. You already check to see
Merlin Moncure wrote:
While using the PQExecPrepared interface, the statement name passed
to the function (as a const char*) has to be in lower case to get it
to work. I kind of understand why this is, but it is kind of weird
that passing the exact same statement name to PQExecPrepared and
Peter Eisentraut wrote:
Merlin Moncure wrote:
While using the PQExecPrepared interface, the statement name passed
to the function (as a const char*) has to be in lower case to get it
to work. I kind of understand why this is, but it is kind of weird
that passing the exact same statement
Merlin Moncure wrote:
Well, yes :) Just to be absolutely clear what I mean, the following
will fail (pseudocode, but you get the idea):
char stmt[] = prepare X as select 0();
PQexec(c, execute X); -- works
PQexecPrepared(c, X [...]); -- fails
You are saying this is the correct and
Andreas Pflug wrote:
Bruce Momjian wrote:
- How's the official way to restrict pg_* functions to superuser only
Very crudely :-)
Got it.
'nother question: Is reading the logfile a task that may be allowed to
superusers only? I don't think so, though acls might apply.
Yes, the
On Thu, Jul 15, 2004 at 08:41:08PM +0100, Simon Riggs wrote:
FYI
http://www.databasejournal.com/features/db2/article.php/3361941
Hmm. Basically it says that they implement SQL2003 semantics (or the
other way around: SQL2003 was written with DB2 in mind).
In the code there is a provision for
On Fri, 2004-07-16 at 19:30, Bruce Momjian wrote:
Simon Riggs wrote:
On Fri, 2004-07-16 at 16:58, Zeugswetter Andreas SB SD wrote:
Do we need a checkpoint after the archiving
starts but before the backup begins?
No.
Actually yes.
Sorry, I did incorrectly not
Bruce Momjian wrote:
Ok, no limit (but a default maximum of 50k remains). And since it's
superuser only, he hopefully knows what he does.
Huh? Why have a default maximum?
Just for convenience. Both start and size are optional parameters, but
with start=0 and size=5. Well, it's a very
Andreas Pflug wrote:
Ah wait.
Digging further behind SIGUSR1 I now *do* see a solution without pid in
shmem, using SendPostmasterSignal. Well, a little hint from gurus would
have helped...
Oops, SendPostmasterSignal uses shmem
At least, this enables syslogger.c to be free from shmem stuff,
Andreas Pflug wrote:
Bruce Momjian wrote:
Ok, no limit (but a default maximum of 50k remains). And since it's
superuser only, he hopefully knows what he does.
Huh? Why have a default maximum?
Just for convenience. Both start and size are optional parameters, but
with start=0 and
Andreas Pflug wrote:
Andreas Pflug wrote:
Ah wait.
Digging further behind SIGUSR1 I now *do* see a solution without pid in
shmem, using SendPostmasterSignal. Well, a little hint from gurus would
have helped...
Oops, SendPostmasterSignal uses shmem
At least, this
On Fri, 2004-07-16 at 16:47, Tom Lane wrote:
As far as the business about copying pg_control first goes: there is
another way to think about it, which is to copy pg_control to another
place that will be included in your backup. For example the standard
backup procedure could be
1.
Andreas Pflug wrote:
Bruce Momjian wrote:
Andreas Pflug wrote:
Right. We already have to use shared mem for the backends and
postmaster. It is the logger we are worried about.
Tom brought up the point that if the logger used shared memory, we would
have to kill/restart it if we
Bruce Momjian wrote:
Andreas Pflug wrote:
Right. We already have to use shared mem for the backends and
postmaster. It is the logger we are worried about.
Tom brought up the point that if the logger used shared memory, we would
have to kill/restart it if we need to reinitialize shared memory,
I
Bruce Momjian wrote:
Andreas Pflug wrote:
Just for convenience. Both start and size are optional parameters, but
with start=0 and size=5. Well, it's a very special function anyway,
so we could require the user to supply all parameters. I'll remove it.
Agreed, and maybe a zero value gets the
OK, I think I have some solid ideas and reasons for them.
First, I think we need server-side functions to call when we start/stop
the backup. The advantage of these server-side functions is that they
will do the required work of recording the pg_control values and
creating needed files with
Let me address you concerns about PITR getting into 7.5. I think a few
people spoke last week expressing concern about our release process and
wanting to take drastic action. However, looking at the release status
report I am about to post, you will see we are on track for an August 1
beta.
We are two weeks away from the beta freeze on August 1 so I want to give
a status report on where we are.
Right now we have two large outstanding items, and a few smaller ones.
Nested transactions (NT) is in CVS, but it is missing:
o savepoints
o cursor rollback
o
54 matches
Mail list logo
