On Tue, 2008-04-22 at 18:13 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
OK, so it can;t be copied to a longer lived memory context?
CopySnapshot always copies snapshots to SnapshotContext, which is a
context that lives until transaction end. There's no mechanism for
copying a
Magnus Hagander wrote:
This doesn't look like our normal coding standards, and should probably
be changed:
+ if (0 != stat(BACKUP_LABEL_FILE, stat_buf))
(there's a number of similar places)
Lacking guidelines, I now tried to copy how stat(2) is used in other parts
of the code.
Yours,
Albe Laurenz wrote:
Magnus Hagander wrote:
This doesn't look like our normal coding standards, and should
probably be changed:
+ if (0 != stat(BACKUP_LABEL_FILE, stat_buf))
(there's a number of similar places)
I see. Lacking guidelines, I now copied how stat(2) is used in
other
generate_series_timestamp.20080423.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Simon Riggs wrote:
On Tue, 2008-04-22 at 18:13 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
OK, so it can;t be copied to a longer lived memory context?
If you need that ability, please explain.
No, I wish to prevent that, not enable it.
I see. Sure, we don't have that
Tom Lane wrote:
The only reason we have memory contexts at all is to avoid the need to
track individual palloc'd objects. Since we're instituting exactly such
tracking for snapshots, there's no value in placing them in
general-purpose memory contexts.
FWIW I noticed yesterday after going to
On Wed, 2008-04-23 at 08:21 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
On Tue, 2008-04-22 at 18:13 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
OK, so it can;t be copied to a longer lived memory context?
If you need that ability, please explain.
No, I wish to
Simon Riggs wrote:
Forgive me for being dense, but what is there to stop you using a
CopySnapshot in TopMemoryContext? If you did, there would be no way to
free it, nor would we notice it had been done, AFAICS. Not anything I'm
thinking about doing, though.
Well, TopMemoryContext is no good
Albe Laurenz wrote:
Magnus Hagander wrote:
This doesn't look like our normal coding standards, and should
probably be changed:
+ if (0 != stat(BACKUP_LABEL_FILE, stat_buf))
(there's a number of similar places)
I see. Lacking guidelines, I now copied how stat(2) is used in
other
H.Harada escribió:
# This is my first time to send a patch. If I did something wrong, I
appreciate your pointing me out.
Brace positioning is off w.r.t. our conventions -- please fix that and
resubmit.
I have added this patch to the May commitfest.
--
Alvaro Herrera
Magnus Hagander wrote:
Applied with some minor changes to the error messages to make them
closer to our guidelines. (With my track record, it's not entirely
unlikely that someone will fix them further though :-P)
I think the messages should not have a newline in the middle.
Also, I am
Alvaro Herrera wrote:
Magnus Hagander wrote:
Applied with some minor changes to the error messages to make them
closer to our guidelines. (With my track record, it's not entirely
unlikely that someone will fix them further though :-P)
I think the messages should not have a newline in
Alvaro Herrera wrote:
I think the messages should not have a newline in the middle.
Also, I am wondering if in PM_WAIT_BACKUP mode we should accept new
connections from superusers only.
I spent some thought on that.
You'd need to wait until the user is authenticated before you can determine
Alvaro Herrera wrote:
FWIW I noticed yesterday after going to bed that SnapshotContext serves
no useful purpose -- we can just remove it and store snaps in
TopTransactionContext.
... which is what the attached patch does.
--
Alvaro Herrera
Magnus Hagander [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I think the messages should not have a newline in the middle.
Are you talking about the one in pg_ctl? We have other messages in
pg_ctl that already do this, so I figured it was ok there...
I concur that the messages added to
Hello,
As discussed:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01476.php
The patch does the following:
Adds an Execution line to the \? output.
Changes the help output in mainloop.c to be more useful.
Greatly reduces overall default banner output:
* shows client version and type
On Wed, 23 Apr 2008 14:41:20 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
Hello,
Per final discussion here:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01607.php
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community
2008/4/23 Alvaro Herrera [EMAIL PROTECTED]:
H.Harada escribió:
# This is my first time to send a patch. If I did something wrong, I
appreciate your pointing me out.
Brace positioning is off w.r.t. our conventions -- please fix that and
resubmit.
Here's updated version. Thanks for
Joshua D. Drake wrote:
On Wed, 23 Apr 2008 14:41:20 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
Hello,
Per final discussion here:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01607.php
Isn't this going to mean \g is listed twice?
+ fprintf(output,
Bruce Momjian wrote:
Euler, have you updated this patch yet?
Here is an updated patch. It follows the Oracle behaviour and uses a
cache mechanism to avoid calling setlocale() all the time. I unified the
localized_* and str_* functions. I didn't test it on Windows. I would
appreciate some
20 matches
Mail list logo
