date:20100407

Re: [HACKERS] [COMMITTERS] pgsql: Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset()

2010-04-07 Thread Heikki Linnakangas

Fujii Masao wrote:
> On Wed, Apr 7, 2010 at 7:23 PM, Heikki Linnakangas
>  wrote:
>> This commit is a stop-gap solution until we figure out what exactly to
>> do about that. Masao-san wrote a patch that included the TLI in the
>> string returned by pg_last_xlog_receive/replay_location() (see
>> http://archives.postgresql.org/message-id/3f0b79eb1003030603ibd0cbadjebb09fa424930...@mail.gmail.com
>> and
>> http://archives.postgresql.org/message-id/3f0b79eb1003300214r6cf98c46tc9be5d563ccf4...@mail.gmail.com),
>> but it still wasn't clear it did the right thing in corner-cases where
>> the TLI changes. Using GetRecoveryTargetTLI() for the tli returned by
>> pg_last_receive_location() seems bogus, at least.
> 
> Why? The tli of the last WAL record received is always the
> recovery target tli currently.

True.

Hmm, currently pg_last_xlog_receive_location() returns the last location
 streamed via streaming replication. Should that be changed so that it
also advances when a WAL segment is restored from archive? It seems
strange that pg_last_xlog_receive_location() can be smaller than
pg_last_xlog_replay_location().

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remaining Streaming Replication Open Items

2010-04-07 Thread Fujii Masao

On Thu, Apr 8, 2010 at 10:41 AM, Robert Haas  wrote:
> On Wed, Apr 7, 2010 at 8:17 AM, Simon Riggs  wrote:
>> OK, that looks a lot less risky than I had understood from discussions.
>> The main thing for me is it doesn't interfere with Startup or
>> WalReceiver, so assuming it works I've got no objections. Thanks for
>> chasing this down, good addition.
>
> Thanks.  Committed.

Thanks. The following TODO item should be removed?

"Redefine smart shutdown in standby mode to exist as soon as all
read-only connections are gone."
http://wiki.postgresql.org/wiki/Todo#Standby_server_mode

Or change it to something like?

"Change smart shutdown in standby mode so that it kills the startup
 and walreceiver process before waiting for the regular backends to die off"

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Streaming replication and a disk full in primary

2010-04-07 Thread Fujii Masao

Thanks for the great patch! I apologize for leaving the issue
half-finished for long time :(

On Wed, Apr 7, 2010 at 7:02 PM, Heikki Linnakangas
 wrote:
> In your version of this patch, the default was still the current
> behavior where the primary retains WAL files that are still needed by
> connected stadby servers indefinitely. I think that's a dangerous
> default, so I changed it so that if you don't set standby_keep_segments,
> the primary doesn't retain any extra segments; the number of WAL
> segments available for standby servers is determined only by the
> location of the previous checkpoint, and the status of WAL archiving.
> That makes the code a bit simpler too, as we never care how far the
> walsenders are. In fact, the GetOldestWALSenderPointer() function is now
> dead code.

It's OK for me to change the default behavior. We can remove
the GetOldestWALSenderPointer() function.

doc/src/sgml/config.sgml
-archival or to recover from a checkpoint. If standby_keep_segments
+archival or to recover from a checkpoint. If
standby_keep_segments

The word "standby_keep_segments" always needs the  tag, I think.

We should remove the document "25.2.5.2. Monitoring"?

Why is standby_keep_segments used even if max_wal_senders is zero?
In that case, ISTM we don't need to keep any WAL files in pg_xlog
for the standby.

When XLogRead() reads two WAL files and only the older of them is recycled
during being read, it might fail in checking whether the read data is valid.
This is because the variable "recptr" can advance to the newer WAL file
before the check.

When walreceiver has gotten stuck for some reason, walsender would be
unable to pass through the send() system call, and also get stuck.
In the patch, such a walsender cannot exit forever because it cannot
call XLogRead(). So I think that the bgwriter needs to send the
exit-signal to such a too lagged walsender. Thought?

The shmem of latest recycled WAL file is updated before checking whether
it's already been archived. If archiving is not working for some reason,
the WAL file which that shmem indicates might not actually have been
recycled yet. In this case, the standby cannot obtain the WAL file from
the primary because it's been marked as "latest recycled", and from the
archive because it's not been archived yet. This seems to be a big problem.
How about moving the update of the shmem to after calling XLogArchiveCheckDone()
in RemoveOldXlogFiles()?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Oddly indented raw_expression_tree_walker

2010-04-07 Thread Takahiro Itagaki

I found raw_expression_tree_walker() is oddly indented in 8.4 and HEAD.
I expected pgindent would fix those clutter, but it could not.
Should we cleanup it manually, or leave it as-is?
Also, should we backport such kind of cleanups to previous releases?

Index: src/backend/nodes/nodeFuncs.c
===
@@ -2198,7 +2198,7 @@
  * that could appear under it, but not other statement types.
  */
 bool
-   raw_expression_tree_walker(Node *node, bool (*walker) 
(), void *context)
+raw_expression_tree_walker(Node *node, bool (*walker) (), void *context)
 {
ListCell   *temp;
 

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A maze of twisty mailing lists all the same

2010-04-07 Thread Jaime Casanova

On Thu, Apr 8, 2010 at 1:11 AM, Greg Stark  wrote:
>
> Likewise I don't think we should have pgsql-performance or pgsql-sql
> or pgsql-novice -- any thread appropriate for any of these would be
> better served by sending it to pgsql-general anyways (with the

+1

-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] A maze of twisty mailing lists all the same

2010-04-07 Thread Greg Stark

I've often said in the past that we have too many mailing lists with
overlapping and vague charters. I submit the following thread as
evidence that this causes real problems.

http://archives.postgresql.org/message-id/g2o4b46b5f01004010610ib8625426uae6ee90ac1435...@mail.gmail.com

Because the poster chose to send it to pgsql-admin instead of
pgsql-general (or pgsql-bugs) very few of the usual suspects had a
chance to see it. 7 days later a question about a rather serious
database corruption problem had no responses. I've never understand
what the point of pgsql-admin is; just about every question posted is
an "admin" question of some sort.

Likewise I don't think we should have pgsql-performance or pgsql-sql
or pgsql-novice -- any thread appropriate for any of these would be
better served by sending it to pgsql-general anyways (with the
exception of pgsql-performance which has a weird combination of hacker
threads and user performance tuning threads). Sending threads to
pgsql-general would get more eyes on them and would avoid a lot of the
cross-posting headaches. What would someone subscribed to one of these
lists but not pgsql-general get anyways but some random sample of
threads that might be vaguely performance or admin related. They would
still miss most of the administration and performance questions and
discussions which happen on -general and -hackers as appropriate.

--
greg

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

50 matches

Mail list logo