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
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 hard-cod
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 b
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 an
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 b
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 t
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
maintenance_
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
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
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
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 s
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.
http://wiki.postgresql.org/wiki/NTT%2
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:
http://
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 ar
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
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 <[E
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
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.
>>
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 no
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 tra
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, t
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.
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
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
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
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 rath
>
> 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
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 a
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
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 requireme
* 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
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. Unfortun
> 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
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 ex
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
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
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
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
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 th
[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) [0x81
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
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
>> o
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
Subject: Re: [HACKERS] cvs head initdb hangs on unixware
Could you generate a core and send a stacktrace?
kill SIGABRT should do
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
Subject: Re: [HACKERS] cvs head initdb hangs on unixware
Could you generate a core and send a stacktrace?
kill SIGABRT should do
Could you generate a core and send a stacktrace?
kill SIGABRT 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 hangs, po
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
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
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: /home/alvherre/Code/c
2008/12/2 Hitoshi Harada <[EMAIL PROTECTED]>:
> sample=# EXPLAIN ANALYZE SELECT LEAD(timestamp) OVER (ORDER BY id)
> FROM bigtable LIMIT 1;
>
> QUERY PLAN
>
> --
> ---
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 onc
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 autovacuu
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 syste
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
transa
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:
> 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
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
http://git.post
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
--
Sen
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 yo
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
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:
http://archives.postgresq
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]
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 insertio
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. So
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-di
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
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 US
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 counte
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 oug
68 matches
Mail list logo
