Re: [HACKERS] Synchronous Log Shipping Replication

understand that paragraph. Who's the user? Do we need to expose some new information to the client so that it can do something? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] WIP patch: Collation support

Martijn van Oosterhout wrote: On Wed, Sep 10, 2008 at 11:29:14AM +0300, Heikki Linnakangas wrote: Radek Strnad wrote: - because of pg_collation and pg_charset are catalogs individual for each database, if you want to create a database with collation other than specified, create it in template1

Re: [HACKERS] New FSM patch

by the FSM should be insignificant in volume compared to all the other WAL traffic. But Simon will probably demand some hard evidence of that ;-). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Interesting glitch in autovacuum

. lazy_scan_heap() calls the regular pruning function heap_page_prune() to deal with those before doing the normal scan of line pointers. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Transaction Snapshots and Hot Standby

up to a point. -- 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: [PATCHES] [HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker)

in text_position_setup(). Together they account for ~10% of CPU time in both tests, so a small difference there would be insignificant anyway in that test case. I think we're fine. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Postgresql coding conventions

of the source tree, mainly for historical reasons. The rule of thumb is to see what style is used in the surrounding code, and follow that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] [Review] pgbench duration option

. -- 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] New FSM patch

correct? If yes maybe extra note in fsm_internal.h about it could be helpful. Yes, that's right. I'll add a note on that if it helps. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Transaction Snapshots and Hot Standby

of failover the slave will fast-forward before starting up as the new master. Of course, if it has fallen 3 days behind because of a giant reporting query, it can take a while to replay all the WAL that has accumulated. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com

Re: [HACKERS] Transaction Snapshots and Hot Standby

, but if the slave is seriously busy, that might never happen. Nevertheless, I think it's a much nicer approach. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Transaction Snapshots and Hot Standby

Csaba Nagy wrote: On Thu, 2008-09-11 at 15:23 +0300, Heikki Linnakangas wrote: I'd imagine that even if applying the WAL on the slave is blocked, it's still streamed from the master to the slave, and in case of failover the slave will fast-forward before starting up as the new master. Which

Re: [HACKERS] Transaction Snapshots and Hot Standby

Csaba Nagy wrote: On Thu, 2008-09-11 at 15:42 +0300, Heikki Linnakangas wrote: One problem with this, BTW, is that if there's a continuous stream of medium-length transaction in the slave, each new snapshot taken will prevent progress in the WAL replay, so the WAL replay will advance in baby

Re: [HACKERS] Transaction Snapshots and Hot Standby

think that can happen, because for such a scenario to arise, in the corresponding point in time in the master, there would've been a scenario where the vacuum would've removed a tuple that would have been visible to a newly starting transaction. Which can't happen. I think.. -- Heikki

Re: [HACKERS] Transaction Snapshots and Hot Standby

at a Commit and Abort record. And clear them all at a shutdown record. -- 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] Synchronous Log Shipping Replication

and to the slave in synchronous mode. I agree that having to get a new base backup to get the old master catch up with the new master sucks, so I hope someone sees a way around that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] [Review] pgbench duration option

it myself. Also, should we be using pqsignal at all? It's not clear to me what it is, to be honest, but there's a note in pqsignal.h that says This shouldn't be in libpq, but the monitor and some other things need it... -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com

Re: [HACKERS] Transaction Snapshots and Hot Standby

Gregory Stark wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: BTW, we haven't talked about how to acquire a snapshot in the slave. You'll somehow need to know which transactions have not yet committed, but will in the future. I'm not sure why you need to know which ones will commit

Re: [HACKERS] no XLOG during COPY?

there was. Could someone please point me at where this optimization was committed? I'm having trouble locating it. http://archives.postgresql.org/pgsql-committers/2007-01/msg00296.php -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Better auth errors from libpq

the pgversion macro? We don't put URLs in error messages. The hint needs to be a real sentence. -- 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

Re: [HACKERS] New FSM patch

Heikki Linnakangas wrote: I've also been working on a low level benchmark using a C user-defined function that exercises just the FSM, showing the very raw CPU performance vs. current implementation. More on that later, but ATM it looks like the new implementation can be faster or slower than

Re: [HACKERS] Synchronous Log Shipping Replication

. Probably not in the first phase, though.. -- 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] New FSM patch

in tests.sh is probably overkill. Thanks! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com fsmtest.tar.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] New FSM patch

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Let me describe this test case first: - The test program calls RecordAndGetPageWithFreeSpace in a tight loop, with random values. What's the distribution of the random values, exactly? In particular, how do the request sizes

Re: [HACKERS] Synchronous Log Shipping Replication

and authentication etc. -- 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] Synchronous Log Shipping Replication

for sure... Which one initiates the connection, the master or slave, is a different question. I believe we've all assumed that it's the slave that connects to the master, and I think that makes the most sense. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via

Re: [HACKERS] New FSM allocation policy

of free space, as close as possible to page Y. -- 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] PLUGINS Functionlity in Win32 build scripts

plugin.patch file. Thanks. We'll need the same logic on Unix-platforms as well. I've added this to the November commitfest Wiki page. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] rmgr hooks and contrib/rmgr_hook

. -- 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] Review Report: propose to include 3 new functions into intarray and intagg

, as Markus pointed out, the SGML docs need to be updated. -- 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] Synchronous Log Shipping Replication

Alvaro Herrera wrote: Simon Riggs escribió: On Fri, 2008-09-12 at 17:08 +0300, Heikki Linnakangas wrote: It should be clear that to make this work you must run with a base backup that was derived correctly on the current master. You can do that by re-copying everything, or you can do

Re: [HACKERS] Transaction Snapshots and Hot Standby

in the first phase, but should be straightforward to add after the basics are working. In any case, we'll need the capability in the slave to notice when it's about to remove a tuple that's still visible to a snapshot in the slave. -- Heikki Linnakangas EnterpriseDB http

Re: [HACKERS] rmgr hooks and contrib/rmgr_hook

to the bitmap index patch? IIRC, there was some non-trivial changes to indexam API in there, as well as issues with VACUUM. If anything, that patch supports the assumption that anything that needs WAL-logging is working at such a low-level that it needs to be in core anyway. -- Heikki Linnakangas

Re: [HACKERS] Synchronous Log Shipping Replication

Fujii Masao wrote: On Fri, Sep 12, 2008 at 12:17 AM, Heikki Linnakangas [EMAIL PROTECTED] wrote: Hmm. There's more problems than the TLI with that. For the original master to catch up by replaying WAL from the new slave, without restoring from a full backup, the original master must not write

Re: [HACKERS] NDirectFileRead and Write

precedence to calling those things temp. -- 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] WIP patch: Collation support

Martijn van Oosterhout wrote: On Wed, Sep 10, 2008 at 12:51:02PM +0300, Heikki Linnakangas wrote: Since the set of collations isn't exactly denumerable, we need some way to allow the user to specify the collation they want. The only collation PostgreSQL knows about is the C collation. Anything

Re: [HACKERS] Subtransaction commits and Hot Standby

there? Hmm, I don't see anything immediately wrong with that. -- 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] Autovacuum and Autoanalyze

= on). -- 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] text search patch status update?

'); ts_headline -- 1 2 3 4 b5/b (1 row) -- 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] Autovacuum and Autoanalyze

Alvaro Herrera wrote: Simon Riggs wrote: On Wed, 2008-09-17 at 10:09 +0300, Heikki Linnakangas wrote: Isn't autoanalyze a waste of time during a bulk load? Seems better to run ANALYZE manually at the end. Its not a waste of time because it catches tables immediately they have been loaded

Re: [HACKERS] optimizing CleanupTempFiles

)) ret = unlink(path); else { -- 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] optimizing CleanupTempFiles

Simon Riggs wrote: On Thu, 2008-09-18 at 09:23 +0300, Heikki Linnakangas wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: BTW in testing this patch I was surprised by the fact that temp tables files are removed at checkpoint time, [ blink... ] Doesn't look like that should

Re: [HACKERS] EncodeDateTime performance

with other stuff, and never got the chance to follow up with that for gcc, or with a patch to PostgreSQL. It does seem like it would be worthwhile to do something about this. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] optimizing CleanupTempFiles

Simon Riggs wrote: On Thu, 2008-09-18 at 10:19 +0300, Heikki Linnakangas wrote: Simon Riggs wrote: An unfortunate choice of words! Harmless is not how your average DBA would describe it when their disk fills and they are apparently unable to reduce space consumption. So there is still

Re: [HACKERS] Adding new flags to XLogRecord

precision. That way xl_prev only needs to be as big as the biggest possible WAL record we can have. Not that I think the precision in your scheme isn't enough, but I find the delta easier to comprehend. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers

Re: [BUGS] [HACKERS] 0x1A in control file on Windows

PG_BINARY_W w #endif I don't see anything wrong with the patch, but I wonder if there's more open() calls that need the same treatment? Like the one in pg_resetxlog.c/ReadControlFile(). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list

Re: [HACKERS] FSM patch - performance test

Zdenek Kotala wrote: My conclusion is that new implementation is about 8% slower in OLTP workload. Thanks. That's very disappointing :-( -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] FSM patch - performance test

Zdenek Kotala wrote: My conclusion is that new implementation is about 8% slower in OLTP workload. Can you do some analysis of why that is? Looks like I need to blow the dust off my DBT-2 test rig and try to reproduce that as well. -- Heikki Linnakangas EnterpriseDB http

Re: [HACKERS] optimizing CleanupTempFiles

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Looks like we didn't make an exception for temporary tables. Although it's harmless, we could put an isTempOrToastNamespace() test in there: Bad, bad idea to have md.c doing any catalog access. isTempOrToastNamespace() doesn't

Re: [HACKERS] WIP patch: Collation support

Gregory Stark wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Well, I proposed disallowing using a different collation than the source database, except for using template0 as the source. That's pretty limited, but is trivial to implement and still let's you have databases with different

Re: [HACKERS] FSM patch - performance test

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Zdenek Kotala wrote: My conclusion is that new implementation is about 8% slower in OLTP workload. Thanks. That's very disappointing :-( One thing that jumped out at me is that you call FreeSpaceMapExtendRel every time a rel

Re: [HACKERS] New FSM patch

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Here's a new patch, updated per your comments. I did a read-through of the portions of this patch that change the rest of the system (ie, not the guts of the new FSM itself). Mostly it looks pretty nice, but I have a few gripes

Re: [HACKERS] New FSM patch

of indexfsm.c about using one bit per page should be recast as a possible future improvement? Yep. I also noted that the code in GetIndexFreeSpace() didn't match the comment above it. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list

Re: [HACKERS] New FSM patch

. -- 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] WIP patch: Collation support

, and we could start using ICU without the catalog changes. -- 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] 8.3.1 autovacuum stopped doing anything months ago

, and then set it back. It will require a restart, though. -- 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] WIP patch: Collation support

now)? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml index f484db8..1e1786a 100644 --- a/doc/src/sgml/charset.sgml +++ b/doc/src/sgml/charset.sgml @@ -130,23 +130,24 @@ initdb --locale=sv_SE para

Re: [HACKERS] PostgreSQL future ideas

Gevik Babakhani wrote: Has there been any idea to port PG to a more modern programming language like C++? No. (You can take your M16 and start shooting now) My pleasure ;-). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] FSM patch - performance test

Zdenek Kotala wrote: Zdenek Kotala napsal(a): Heikki Linnakangas napsal(a): Zdenek Kotala wrote: My conclusion is that new implementation is about 8% slower in OLTP workload. Can you do some analysis of why that is? I tested it several times and last test was surprise for me. I run

Re: [HACKERS] WIP patch: Collation support

Heikki Linnakangas wrote: Here's an updated version of the stripped-down patch, now with documentation changes, plus a couple of minor bug fixes. Another update, marching towards committing. Now with pg_dump/pg_dumpall support, and collation/ctype is also shown in psql \l output. I wonder

Re: [HACKERS] WIP patch: Collation support

Martijn van Oosterhout wrote: On Fri, Sep 19, 2008 at 10:13:43AM +0300, Heikki Linnakangas wrote: It's not like the patch is going to disappear from planet Earth if it doesn't get committed for 8.4. It's still valuable and available when the new catalogs are needed. I just prefer

Re: [HACKERS] WIP patch: Collation support

supported it at initdb time for ages. -- 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] WIP patch: Collation support

Zdenek Kotala wrote: Heikki Linnakangas napsal(a): For anyone counting, Firebird added support for ICU more than three years ago. ICU is orthogonal to this patch. This patch didn't provide ICU support, and we could start using ICU without the catalog changes. This patch should allow

Re: [HACKERS] FSM patch - performance test

that. see the patch I just posted on a separate thread. -- 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] WIP patch: Collation support

could simply remove support for per-database encodings altogether and fix it at initdb time, as Martijn suggest earlier, but now that we have per-database locales, per-database encodings is a lot more useful as well. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent

Re: [HACKERS] WIP patch: Collation support

Martijn van Oosterhout wrote: On Mon, Sep 22, 2008 at 10:22:35AM +0300, Heikki Linnakangas wrote: BTW, the original patch didn't have any provision for creating rows in pg_collation reflecting the locales available in the OS, but I think we'd need that. Otherwise the DBA would need to manually

Re: [HACKERS] WIP patch: Collation support

to whatever internal names we invent for them, though, so I'm not sure if the pg_collation catalog helps much, but just moves the problem elsewhere. The pg_dump output of the CREATE COLLATION statements still wouldn't be portable from one OS to another. -- Heikki Linnakangas EnterpriseDB

Re: [HACKERS] FSM, now without WAL-logging

Simon Riggs wrote: On Mon, 2008-09-22 at 20:43 +0300, Heikki Linnakangas wrote: Attached is a revamped version of the FSM rewrite. WAL-logging is now gone. Any inconsistencies between levels of the FSM is fixed during vacuum, and by searchers when they run into a dead end because

Re: [HACKERS] Initial prefetch performance testing

requests the I/O subsystem can handle, without referring to any specific technology. That concept applies to SANs and RAM drives as well. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] FSM, now without WAL-logging

Zdenek Kotala wrote: Heikki Linnakangas napsal(a): There's one known bug left. If we crash after truncating a relation, and the truncation of the FSM doesn't hit the disk but the truncation of the main fork does, we can end up with an FSM that shows that there's free space on pages

Re: [HACKERS] FSM, now without WAL-logging

Zdenek Kotala wrote: Heikki Linnakangas napsal(a): It would be simple to update the FSM at every heap insert and update record, but that then might be an unacceptable amount of overhead at recovery. Also, the index FSM is not yet updated during recovery. I expect locking problems

Re: [HACKERS] pgsql: Make LC_COLLATE and LC_CTYPE database-level settings.

pg_dump -s slonyregress1 Thanks, fixed. I changed the column names from collate and ctype to datcollate and datctype at the last minute, and clearly didn't test pg_dump after that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] FSM, now without WAL-logging

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Zdenek Kotala wrote: What's about truncate FSM during WAL replay of main fork truncation record? That would work, except that there's no WAL record for truncating the main fork. Whaddya mean there's no WAL record

Re: [HACKERS] FSM, now without WAL-logging

test results, and I'll try to zip them up and FTP somewhere (~500 MB uncompressed). I've also tried various pgbench tests, on a RAM disk and otherwise, as well as the table population test I ran earlier, and don't see any difference in performance. -- Heikki Linnakangas EnterpriseDB http

Re: [HACKERS] FSM rewrite: doc changes

by PagetGetFreeSpace, to fit a tuple of MaxHeapTupleSize bytes. -- 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] FSM rewrite: doc changes

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Tom Lane wrote: In fsm_rebuild_page, surely we needn't check if (lchild NodesPerPage). Yes, we do. But the loop starting point is such that you must be visiting a parent with at least one child, no? Hmm, true, and that means

Re: [HACKERS] Index size increases after VACUUM FULL

increased. That's normal. VACUUM FULL creates new index pointers for the tuples it moves, which can lead to a bigger index. If it bothers, REINDEX will pack the indexes tighter again. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list

[HACKERS] FSM rewrite committed, loose ends

to view the contents of the FSM in detail, but should VACUUM VERBOSE still print something about the amount of free space on the relation? Perhaps the total amount of free space in the relation? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers

Re: [HACKERS] Index size increases after VACUUM FULL

Gurjeet Singh wrote: On Tue, Sep 30, 2008 at 3:09 PM, Heikki Linnakangas [EMAIL PROTECTED] wrote: That's normal. VACUUM FULL creates new index pointers for the tuples it moves, which can lead to a bigger index. If it bothers, REINDEX will pack the indexes tighter again. That explains

Re: [HACKERS] FSM rewrite committed, loose ends

) No, it didn't change that. Regular VACUUMing or autovacuum is still needed. -- 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] FSM rewrite committed, loose ends

='foo'; -- 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] FSM rewrite committed, loose ends

Dimitri Fontaine wrote: Le mardi 30 septembre 2008, Heikki Linnakangas a écrit : Dimitri Fontaine wrote: Question for the slow readers: this new FSM scheme being dynamic, it's no longer possible to have table bloat, right? (where table bloat is full of dead-for-any-transaction tuples, and you

Re: [HACKERS] FSM rewrite committed, loose ends

Dimitri Fontaine wrote: Le mardi 30 septembre 2008, Heikki Linnakangas a écrit : You forgot the toast size. Yeah, pg_total_relation_size() - pg_relation_size() is not equal to the total size of indexes because of that. Oops. Thanks for pointing this to me... But you can do SUM

Re: [HACKERS] Index size increases after VACUUM FULL

Gurjeet Singh wrote: On Tue, Sep 30, 2008 at 4:49 PM, Heikki Linnakangas [EMAIL PROTECTED] wrote: Gurjeet Singh wrote: On Tue, Sep 30, 2008 at 3:09 PM, Heikki Linnakangas [EMAIL PROTECTED] wrote: That's normal. VACUUM FULL creates new index pointers for the tuples it moves, which can

Re: [HACKERS] Block-level CRC checks

, calculate the checksum, and compare it to the one stored in the CRC fork. Surely it would be much simpler to just add a field to the page header. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Block-level CRC checks

of the new page version makes it to disk (= torn page). The CRC would not match, even though the page is actually valid. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] WAL recovery is broken by FSM patch

. -- 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] Block-level CRC checks

in index pages during a scan, and the new FSM pages. Currently, a torn page when writing a hint-bit-updated page doesn't matter, but it would break the checksum. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] FSM rewrite committed, loose ends

Dave Page wrote: On Tue, Sep 30, 2008 at 2:53 PM, Heikki Linnakangas [EMAIL PROTECTED] wrote: Should pg_relation_indexes_size() include the FSMs of the indexes? Should pg_relation_toast_size() include the toast index and FSM as well? It might be worth revisiting the near identical discussions

Re: [HACKERS] FSM rewrite committed, loose ends

Zdenek Kotala wrote: Heikki Linnakangas napsal(a): The FSM is not updated during WAL replay. That means that after crash recovery, the FSM won't be completely up-to-date, but at roughly the state it was at last checkpoint. In a warm stand-by, the FSM will reflect the situation at last full

Re: [HACKERS] trivial patch for pg_freespacemap documentation

hubert depesz lubaczewski wrote: while reading documentation for pg_freespacemap contrib module i found a small mistake - the functions are names pg_freespace and not pg_freespacemap. attached patch changes the sgml file with documentation. Fixed, thanks. -- Heikki Linnakangas

Re: [HACKERS] Block-level CRC checks

slower. The buffer manager would have to know what kind of a page it's dealing with, heap or index or FSM or what, to know where the hint bits are. Then it would have to follow the line pointers to locate the hint bits, and mask them out for the CRC calculation. -- Heikki Linnakangas

Re: [HACKERS] Block-level CRC checks

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Brian Hurt wrote: Another possibility is to just not checksum the hint bits... That would work. But I'm afraid it'd make the implementation a lot more invasive, and also slower. The buffer manager would have to know what kind

Re: [HACKERS] Block-level CRC checks

bits in pd_flags. But isn't it a bit dangerous to have a single flag on the page indicating whether the CRC is valid or not? Any corruption that flips that bit would make the CRC check to be skipped. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers

Re: [HACKERS] FSM rewrite committed, loose ends

Robert Treat wrote: On Thursday 02 October 2008 08:37:59 Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: There's currently two variants of both pg_relation_size and pg_total_relation_size, one takes an OID and one takes a relation name as argument. Any objections to having just

Re: [HACKERS] pgsql: Add relation fork support to pg_relation_size() function.

to be segmented. Does anyone have a problem with a filename with two dots? Shouldn't be a problem, I guess. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] pgsql: Add relation fork support to pg_relation_size() function.

Gregory Stark wrote: Magnus Hagander [EMAIL PROTECTED] writes: Heikki Linnakangas wrote: If we go with the .fsm extension, we'll get 12345.fsm.1 when the FSM grows large enough to be segmented. Does anyone have a problem with a filename with two dots? Shouldn't be a problem, I guess. We

Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

it really gets deleted. I would welcome any pointer. In mdpostckpt(). The trivial fix is to just force a checkpoint in ALTER TABLE SET TABLESPACE. Can we do better than that? Perhaps only force a checkpoint when we find that the file already exists. -- Heikki Linnakangas EnterpriseDB http

Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

Guillaume Lelarge wrote: Tom Lane a écrit : Heikki Linnakangas [EMAIL PROTECTED] writes: The trivial fix is to just force a checkpoint in ALTER TABLE SET TABLESPACE. Can we do better than that? Perhaps only force a checkpoint when we find that the file already exists. If ALTER TABLE SET

Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Yeah, seems like we need to allocate a new relfilenode in the new tablespace. I looked into tablecmds.c and verified that ATExecSetTableSpace doesn't worry about selecting a new relfilenode. I'm also noticing a number

<    1   2   3   4   5   6   7   8   9   10   >