Having just tried to restore a 64 bit BSD database to a 32 bit linux
machine (using PiTR), I have now realized the (with hindsight, obvious)
error in my ways.
Now, I need to plan a way forward. From reading of other peoples similar
problems, I now realize that I need a system with identical
On Tue, 2008-12-02 at 21:37 +0900, Fujii Masao wrote:
Thanks for taking many hours to review the code!!
On Mon, Dec 1, 2008 at 8:42 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Can you confirm that all the docs on the Wiki page are up to date? There
are a few minor discrepancies that make me
I've noticed that pg_stat_all_tables returns NULL for idx_scan and
idx_tup_fetch if there are no indexes present on a table.
Is this actually intended, or is that something that should be fixed?
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Would it make sense to be able to configure maintenance_work_mem
specifically for the autovacuum processes? Given that there can be a
number of them, it might be good to be able to have one default for all
*other* processes, and a separate one from the ones kicked off by autovac?
//Magnus
--
KaiGai Kohei wrote:
-- (3) tries to open it with writable mode under transaction block.
postgres=# BEGIN;
BEGIN
postgres=# SELECT lo_open(24576, x'4'::int);
WARNING: Snapshot reference leak: Snapshot 0x96b8488 still referenced
Interesting. This is due to this patch
Alvaro Herrera wrote:
KaiGai Kohei wrote:
-- (3) tries to open it with writable mode under transaction block.
postgres=# BEGIN;
BEGIN
postgres=# SELECT lo_open(24576, x'4'::int);
WARNING: Snapshot reference leak: Snapshot 0x96b8488 still referenced
I'm investigating now.
Teodor Sigaev wrote:
- Falling back to regular insert will take long time for update of whole
table - and that was one of reasons of that patch. Users forget to drop
GIN index before a global update and query runs forever.
If *that* is a use case we're interested in, the incoming tuples could
Alvaro Herrera wrote:
I think the solution is to have each large object have its own
ResourceOwner, and store the snapshot in it. Otherwise the snapshot is
left in the calling query's resowner, which is not good.
Turns out to be overkill. This patch solves the problem, by using the
Philip Warner wrote:
Having just tried to restore a 64 bit BSD database to a 32 bit linux
machine (using PiTR), I have now realized the (with hindsight, obvious)
error in my ways.
Now, I need to plan a way forward. From reading of other peoples similar
problems, I now realize that I need a
While playing around with the GIN fast insert patch, I was puzzled why
building a GIN index seemed to take so long. The test case I use was simply:
CREATE TABLE foo (bar tsvector);
INSERT INTO foo SELECT to_tsvector('foo' || a) FROM generate_series(1,
20) a;
CREATE INDEX foogin ON foo
Seems it would make more sense to just divide maintenance_work_mem by
the number of workers for autovacuum.
This sounds familiar. Didn't we already decide to do this once?
One concern I have about this is people asking how come when I
runvacuum manually it takes x minutes but when
grovel through. The situation will only be rectified at the next vacuum,
but if there's no deletes or updates on the table, just inserts,
autovacuum won't happen until the next anti-wraparound vacuum.
There is not agreement here, see
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
Here is an update version of contrib/pg_stat_statements.
New modifications from the last version are:
1. New counters in struct Instrumentation.
2. EXPLAIN ANALYZE VERBOSE shows buffer statistics in 'actual' section.
3. Buffer statistics counsters are not reset to zero anymore.
1. New
The issue is that the GIN index build code accumulates the lexemes into
a binary tree, but there's nothing to keep the tree balanced. My test
case with almost monotonically increasing keys, happens to be a
worst-case scenario, and the tree degenerates into almost linked list
that every
Greg Stark wrote:
Seems it would make more sense to just divide maintenance_work_mem by
the number of workers for autovacuum.
While that would be a solution for some cases, it is far from certain
that's what you'd actually want.
This sounds familiar. Didn't we already decide to do this once?
Tom Lane wrote:
After thinking about it I'm inclined to feel that SS and friends should
insist on exactly 2 digits. If you want to allow 1-or-2-digits then use
FMSS, just like the error message tells you. (However, I have a vague
feeling that Oracle doesn't insist on this, and in the end we
2008/12/2 Hitoshi Harada [EMAIL PROTECTED]:
sample=# EXPLAIN ANALYZE SELECT LEAD(timestamp) OVER (ORDER BY id)
FROM bigtable LIMIT 1;
QUERY PLAN
--
---
Here's a better patch.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: src/backend/storage/large_object/inv_api.c
===
RCS file:
The skyline operator is a non-standard extension (even SQL:2008 does
not include it). Queries of that type can be expressed in standard
SQL (although a bit clumsy and the execution is slow). Others have
also worked on extending PostgreSQL with the skyline operator, see:
Hi all,
cvs head configured without --enable-debug hang in initdb while making
check.
warthog doesn't exhibit it because it's configured with debug.
when it hangs, postmaster takes 100% cpu doing nothing. initdb waits for
it while creating template db.
According to truss, the last usefull
Greg Smith [EMAIL PROTECTED] writes:
... where the Power Test seems to oscillate between degrees of good and bad
behavior seemingly at random.
Are any of the queries complicated enough to trigger GEQO planning?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hi, Simon.
Thanks for taking many hours to review the code!!
On Mon, Dec 1, 2008 at 8:42 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Can you confirm that all the docs on the Wiki page are up to date? There
are a few minor discrepancies that make me think it isn't.
Documentation is ongoing. Sorry
Heikki Linnakangas wrote:
You can also run pg_controlinfo on both systems, and compare the
results. If the Maximum data alignment, and all the values below it
in the pg_controlinfo output match, the formats are compatible.
s/pg_controlinfo/pg_controldata/
cheers
andrew
--
Sent via
Could you generate a core and send a stacktrace?
kill SIGABRT pid should do that.
Zdenek
[EMAIL PROTECTED] napsal(a):
Hi all,
cvs head configured without --enable-debug hang in initdb while making
check.
warthog doesn't exhibit it because it's configured with debug.
when it
On Tue, 2 Dec 2008, Zdenek Kotala wrote:
Date: Tue, 02 Dec 2008 17:22:25 +0100
From: Zdenek Kotala [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] cvs head initdb hangs on unixware
Could you generate a core and send a
On Tue, 2 Dec 2008, Zdenek Kotala wrote:
Date: Tue, 02 Dec 2008 17:22:25 +0100
From: Zdenek Kotala [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] cvs head initdb hangs on unixware
Could you generate a core and send a
2008/11/26 Heikki Linnakangas [EMAIL PROTECTED]:
Hitoshi Harada wrote:
I read more, and your spooling approach seems flexible for both now
and the furture. Looking at only current release, the frame with ORDER
BY is done by detecting peers in WinFrameGetArg() and add row number
of peers to
On Tue, 2008-12-02 at 16:21 +0200, Heikki Linnakangas wrote:
initdb on one platform, copy the data directory over to the other
system, and try to start postmaster. It will complain if the on-disk
format is not compatible.
You can also run pg_controlinfo on both systems, and compare the
[EMAIL PROTECTED] wrote:
Suivi de pile correspondant à p1, Programme postmaster
*[0] fsm_rebuild_page( présumé: 0xbd9731a0, 0, 0xbd9731a0) [0x81e6a97]
[1] fsm_search_avail( présumé: 0x2, 0x6, 0x1) [0x81e68d9]
[2] fsm_set_and_search(0x84b2250, 0, 0, 0x2e, 0x5, 0x6, 0x2e,
0x8047416, 0xb4)
On Tue, 2008-12-02 at 23:02 +1100, Philip Warner wrote:
In the specific instance I am working with, I'd like to copy from 64
bit AMD BSD system to a 64 bit Linux system.
I wouldn't recommend it. Midnight is the wrong time to find out that
there was a difference that mattered after all. Is the
On Tue, 2008-12-02 at 11:08 -0800, Jeff Davis wrote:
On Tue, 2008-12-02 at 13:09 +, Simon Riggs wrote:
Is it dangerous to abort the transaction with replication continued when
the timeout occurs? I think that the WAL consistency between two servers
might be broken. Because the WAL
On Tue, 2008-12-02 at 13:09 +, Simon Riggs wrote:
Is it dangerous to abort the transaction with replication continued when
the timeout occurs? I think that the WAL consistency between two servers
might be broken. Because the WAL writing and sending are done concurrently,
and the
Fujii Masao wrote:
On Wed, Oct 8, 2008 at 10:23 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Minor bug fix for pg_stop_backup() to prevent it waiting longer than
necessary in certain circumstances.
Why don't you use XLByteToPrevSeg like pg_xlogfile_name?
I think that we should uniform the logic
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Dann Corbit [EMAIL PROTECTED] writes:
I also do not believe that there is any value that will be the right
answer. But a table of data might be useful both for people who want to
toy with altering the values and also for those who
Mark,
Generally
speaking, it seems like on un-tuned systems increasing the
default_statistics_target for this workload doesn't have a clear
benefit.
Do you have any idea how skewed the distribution of data for DBT3 is? If
values are being generated in relatively equal proportion, I'd
Breaking down of patch into sections works very well for review. Should
allow us to get different reviewers on different parts of the code -
review wranglers please take note: Dave, Josh.
Fujii-san, could you break the patch up into several parts? We have quite
a few junior reviewers who
Jeff,
Even if that could be made safe, in the event of a real network failure,
you'd just wait the full timeout every transaction, because it still
thinks it's replicating.
Hmmm. I'd suggest that if we get timeouts for more than 10xTimeout value
in a row, that replication stops.
* Josh Berkus [EMAIL PROTECTED] [081202 15:54]:
Do you have any idea how skewed the distribution of data for DBT3 is? If
values are being generated in relatively equal proportion, I'd expect
increasing DST to have little effect. The databases where higher DST is
useful is ones with
On Thu, Nov 27, 2008 at 11:09 AM, Emmanuel Cecchet [EMAIL PROTECTED] wrote:
I have been following that discussion very closely but it seems that we are
debating solutions without a good specification of the problem/requirements.
I would suggest that we collect all the partitioning requirements
Jeff Davis wrote:
On Tue, 2008-12-02 at 16:21 +0200, Heikki Linnakangas wrote:
initdb on one platform, copy the data directory over to the other
system, and try to start postmaster. It will complain if the on-disk
format is not compatible.
You can also run pg_controlinfo on both
On Wed, 2008-12-03 at 10:15 +1100, Philip Warner wrote:
wow...that's a little scary. Sounds like there is no trustworthy test I
can run. Other than the case of collation differences, are there any
other kinds of problems that would not be detected by even a postmaster
restart?
I can't
But, as Simon pointed out, is it really worth the risk? PITR is closer
to a physical process, and it's probably wise to just assume it's not
portable.
Yeah...I am getting that impression ;-). From this I will assume we need:
- same OS (and OS minor version?)
- same CPU architecture
I
Magnus Hagander [EMAIL PROTECTED] writes:
I've noticed that pg_stat_all_tables returns NULL for idx_scan and
idx_tup_fetch if there are no indexes present on a table.
Is this actually intended, or is that something that should be fixed?
Hmm. I suspect it's an implementation artifact rather
Magnus Hagander [EMAIL PROTECTED] writes:
Greg Stark wrote:
One concern I have about this is people asking how come when I
runvacuum manually it takes x minutes but when autovacuum runs it it
tale 5x minutes?
As long as the default is the same, people would get at least an initial
clue that
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the solution is to have each large object have its own
ResourceOwner, and store the snapshot in it. Otherwise the snapshot is
left in the calling query's resowner, which is not good.
That's not gonna scale to transactions that touch lots of
Heikki Linnakangas [EMAIL PROTECTED] writes:
Teodor Sigaev wrote:
- Falling back to regular insert will take long time for update of whole
table - and that was one of reasons of that patch. Users forget to drop
GIN index before a global update and query runs forever.
If *that* is a use
On Tue, Nov 25, 2008 at 4:03 PM, Stephen Frost [EMAIL PROTECTED] wrote:
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
I had a look at aclchk.c and didn't like your change to
objectNamesToOids; seems rather baroque. I changed it per the attached
patch.
I've incorporated this change.
Moreover
Peter Eisentraut wrote:
On Tuesday 25 November 2008 15:09:37 Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
While hacking on parser/gram.y just now I noticed in passing that the
automatically generated ecpg parser had 402 shift/reduce conflicts.
(Don't panic, the parser in
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the solution is to have each large object have its own
ResourceOwner, and store the snapshot in it. Otherwise the snapshot is
left in the calling query's resowner, which is not good.
That's not gonna scale to transactions
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, this is going to make it hard for developers to test CVS changes
until they get their grammar cleaned up; perhaps add a comment on how
to disable the check?
Well, the point is that their grammar changes are broken if that check
fails, so I'm not
On Wed, Dec 3, 2008 at 5:13 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Fujii Masao wrote:
On Wed, Oct 8, 2008 at 10:23 PM, Simon Riggs [EMAIL PROTECTED]
wrote:
Minor bug fix for pg_stop_backup() to prevent it waiting longer than
necessary in certain circumstances.
Why don't you use
Hi,
On Wed, Dec 3, 2008 at 6:03 AM, Josh Berkus [EMAIL PROTECTED] wrote:
Breaking down of patch into sections works very well for review. Should
allow us to get different reviewers on different parts of the code -
review wranglers please take note: Dave, Josh.
Fujii-san, could you break the
Hi,
As to checkpoint timeout, yes, this measurement is hard for FPW=on
case. I'll do the similar measurement for checkpoint timeout = 5min
and post the result. I expect that the recoevry time will be almost
the same in the case FPW=on, lesslog=yes and prefetpch = yes.
2008/12/2 Simon Riggs
I'd like to have the new one too to test.
2008/11/27 Robert Haas [EMAIL PROTECTED]:
On Wed, Nov 26, 2008 at 4:38 PM, Jaime Casanova
[EMAIL PROTECTED] wrote:
i get lost with this one... i thought there were two patches that get
merged into one, but i don't find nor the merged version nor the
Hi,
I found that no one is registered as hot standby reviewer. I'd like
to review the patch, mainly by testing through some benchmark test.
Regards;
2008/11/2 Simon Riggs [EMAIL PROTECTED]:
Hot Standby patch, including all major planned features.
Allows users to connect to server in
Fujii-san,
Yes, I divided the patch into 9 pieces. Do I need to divide it further?
That's plenty. Where do reviews find the 9 pieces?
--
Josh Berkus
PostgreSQL
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hi,
On Wed, Dec 3, 2008 at 3:21 PM, Josh Berkus [EMAIL PROTECTED] wrote:
Fujii-san,
Yes, I divided the patch into 9 pieces. Do I need to divide it further?
That's plenty. Where do reviews find the 9 pieces?
The latest patch set (v4) is on wiki.
Hello,
On Tue, Dec 2, 2008 at 10:09 PM, Simon Riggs [EMAIL PROTECTED] wrote:
The reaction to replication_timeout may need to be configurable. I might
not want to keep on processing if the information didn't reach the
standby.
OK. I will add new GUC variable (PGC_SIGHUP) to specify the
Hi,
On Thu, Nov 27, 2008 at 9:04 PM, Koichi Suzuki [EMAIL PROTECTED] wrote:
Please find enclosed a revised version of pg_readahead and a patch to
invoke pg_readahead.
Some similar functions are in xlog.c and pg_readahead.c (for example,
RecordIsValid). I think that we should unify them as a
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
If *that* is a use case we're interested in, the incoming tuples could
be accumulated in backend-private memory, and inserted into the index at
commit. That would be a lot simpler, with no need to worry about
concurrent inserts or
On Wed, Dec 3, 2008 at 11:00 AM, Koichi Suzuki [EMAIL PROTECTED] wrote:
Hi,
I found that no one is registered as hot standby reviewer. I'd like
to review the patch, mainly by testing through some benchmark test.
You can yourself edit the Wiki page, though you need to register first. But
On Wed, Dec 3, 2008 at 2:00 AM, Tom Lane [EMAIL PROTECTED] wrote:
It seems like mostly a confusion-generator to me. Is there any actual
evidence that autovac should use a different maintenance_work_mem than
other processes?
IMHO, the point is that we were used to consider the
Hi,
On Wed, Dec 3, 2008 at 4:08 AM, Jeff Davis [EMAIL PROTECTED] wrote:
Even if that could be made safe, in the event of a real network failure,
you'd just wait the full timeout every transaction, because it still
thinks it's replicating.
If walsender detects a real network failure, the
Thank you for your advise. I'll edit the Wiki page.
2008/12/3 Pavan Deolasee [EMAIL PROTECTED]:
On Wed, Dec 3, 2008 at 11:00 AM, Koichi Suzuki [EMAIL PROTECTED] wrote:
Hi,
I found that no one is registered as hot standby reviewer. I'd like
to review the patch, mainly by testing
Since this whole in-place upgrade thing is going nowhere until there's
also a good solution for ye olde The database cluster was initialized
with CATALOG_VERSION_NO ... error, I spent some time today touring
through what everybody else has done there and have some initial review
commentary and
Greg,
On Mon, Dec 1, 2008 at 3:17 AM, Greg Smith [EMAIL PROTECTED] wrote:
./pgtune -i ~/data/postgresql.conf
First, thanks for your work: it will really help a lot of people to
have a decent default configuration.
A couple of comments from reading the code (I didn't run it yet):
- it would be
Greg Smith napsal(a):
The main thing you'll find there is a ksh script that handles most of
the upgrade, presuming there's no page format changes. It looks like it
was originally aimed at 8.1-8.2 upgrades (easy as long as you don't use
INET/CIDR in your database) and still has some
Zdenek Kotala wrote:
Greg Smith napsal(a):
-There are 10 TODO items listed for the pg_migrator project, most or
all of which look like should be squashed before this is really
complete. Any chance somebody (Korry?) has an improved version of this
floating around beyond what's in the pgfoundry
68 matches
Mail list logo
