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 perf
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.
PITR
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 litt
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
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
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/resta
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. [so
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 l
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
> wi
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, e
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 specia
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.
> > >
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 f
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 appl
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 corr
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 st
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
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
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 stateme
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
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 back
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 :-)
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
> > info
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 str
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 shoul
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: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 on
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 m
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* info
> >> 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 issu
"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 sta
> 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.
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.
"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 "pe
> "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 Br
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
lists <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>>> this is 7.3.3 (PGDG rpm's) on red hat 7.2
>>
>> Get 7.3.6 and try again. IIRC this is a known bug that was repaired in
>> 7.3.4.
> to get the data back, is it a matter of just upgrading and starting the
> db (ie will it perform recov
> >> 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 faced with is to identi
"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
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*,
"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 actu
> > 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 se
> > 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
> missin
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 comm
> >> 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
> wo
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 *
F
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
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
48 matches
Mail list logo
