On 2013-05-29 23:01:31 -0400, Robert Haas wrote:
On Wed, May 29, 2013 at 9:57 AM, Andres Freund and...@2ndquadrant.com wrote:
Thought about that, but given that 9.3's visibilitymap_set already will
already FPI heap pages I concluded it wouldn't really be an improvement
since it's only one
On 30.05.2013 06:43, Bruce Momjian wrote:
On Wed, May 29, 2013 at 09:59:10PM -0400, Peter Eisentraut wrote:
I think these sort of entries don't make much sense:
#wal_sender_timeout = 60s # in milliseconds; 0 disables
I think we should remove units from the comments when it's clear from
On 05/28/2013 07:52 PM, Fabien COELHO wrote:
However I'm not sure that pg_stat_replication currently has the
necessary information on either side to measure the lag (in time
transactions, but how do I know when a transaction was committed? or
number of transactions?).
The BDR codebase now
On 05/30/2013 12:01 AM, Heikki Linnakangas wrote:
We could make it mandatory to specify the unit in the value. Ie. throw
an error on wal_sender_timeout = 50:
ERROR: unit required for option wal_sender_timeout
HINT: Valid units for this parameter are ms, s, min, h, and d.
Then you wouldn't
On 05/30/2013 03:10 PM, Craig Ringer wrote:
On 05/28/2013 07:52 PM, Fabien COELHO wrote:
However I'm not sure that pg_stat_replication currently has the
necessary information on either side to measure the lag (in time
transactions, but how do I know when a transaction was committed? or
number
On Thu, May 30, 2013 at 3:52 AM, Joshua D. Drake j...@commandprompt.com wrote:
On 05/30/2013 12:01 AM, Heikki Linnakangas wrote:
We could make it mandatory to specify the unit in the value. Ie. throw
an error on wal_sender_timeout = 50:
ERROR: unit required for option wal_sender_timeout
On 2013-05-30 15:54:01 +0800, Craig Ringer wrote:
On 05/30/2013 03:10 PM, Craig Ringer wrote:
On 05/28/2013 07:52 PM, Fabien COELHO wrote:
However I'm not sure that pg_stat_replication currently has the
necessary information on either side to measure the lag (in time
transactions, but how
On 05/30/2013 12:55 AM, Magnus Hagander wrote:
I like this idea with one addition. We should have a default unit for each.
For wal_sender_timeout seconds makes sense, but for checkpoint_timeout
minutes makes sense (for example).
This sounds like a good way to make things even more confusing.
On 30.05.2013 10:52, Joshua D. Drake wrote:
On 05/30/2013 12:01 AM, Heikki Linnakangas wrote:
We could make it mandatory to specify the unit in the value. Ie. throw
an error on wal_sender_timeout = 50:
ERROR: unit required for option wal_sender_timeout
HINT: Valid units for this parameter are
On 30.05.2013 06:54, Jeff Davis wrote:
Continuation of:
http://www.postgresql.org/message-id/1353551097.11440.128.camel@sussancws0025
Rebased patch attached; no other changes.
@@ -675,6 +675,16 @@ lazy_scan_heap(Relation onerel, LVRelStats *vacrelstats,
}
/*
On 05/30/2013 01:14 AM, Heikki Linnakangas wrote:
On 30.05.2013 10:52, Joshua D. Drake wrote:
On 05/30/2013 12:01 AM, Heikki Linnakangas wrote:
We could make it mandatory to specify the unit in the value. Ie. throw
an error on wal_sender_timeout = 50:
ERROR: unit required for option
On 30.05.2013 11:26, Heikki Linnakangas wrote:
On 30.05.2013 06:54, Jeff Davis wrote:
Continuation of:
http://www.postgresql.org/message-id/1353551097.11440.128.camel@sussancws0025
Rebased patch attached; no other changes.
@@ -675,6 +675,16 @@ lazy_scan_heap(Relation onerel, LVRelStats
Joe Conway m...@joeconway.com writes:
Here's a cleaned up version, which also includes documentation. I'll
commit back to 9.1 in a day or two unless there are any objections.
Looks good to me.
Were you able to test it against an extension containing both rules and
views, to check that pg_dump
On Wed, May 29, 2013 at 10:42 AM, Andres Freund and...@2ndquadrant.com wrote:
FWIW, posix' description about posix_fallocate() doesn't actually say
*anything* about reading. The guarantee it makes is:
If posix_fallocate() returns successfully, subsequent writes to the
specified file data shall
On 5/30/13 6:49 AM, Robert Haas wrote:
On Wed, May 29, 2013 at 10:42 AM, Andres Freund and...@2ndquadrant.com wrote:
So we don't even know whether we can read. I think that means we need to
zero the file anyway...
Surely this is undue pessimism.
There have been many occasions where I've
On 2013-05-30 06:49:42 -0400, Robert Haas wrote:
On Wed, May 29, 2013 at 10:42 AM, Andres Freund and...@2ndquadrant.com
wrote:
FWIW, posix' description about posix_fallocate() doesn't actually say
*anything* about reading. The guarantee it makes is:
If posix_fallocate() returns
On 2013-05-30 06:55:16 -0400, Greg Smith wrote:
On 5/30/13 6:49 AM, Robert Haas wrote:
On Wed, May 29, 2013 at 10:42 AM, Andres Freund and...@2ndquadrant.com
wrote:
So we don't even know whether we can read. I think that means we need to
zero the file anyway...
Surely this is undue
Hi,
In
http://archives.postgresql.org/message-id/20130216164231.GA15069%40awork2.anarazel.de
I presented the need for 'indirect' toast tuples which point into memory
instead of a toast table. In the comments to that proposal, off-list and
in-person talks the wish to make that a more general
On 5/30/13 7:17 AM, Andres Freund wrote:
That argument in contrast I find not very convincing though. What was
the last incidence of such a system call that did not just error out
with ENOTSUPP or such?
http://linux.die.net/man/2/posix_fadvise talks about POSIX_FADV_NOREUSE
and
On 2013-05-30 07:48:51 -0400, Greg Smith wrote:
On 5/30/13 7:17 AM, Andres Freund wrote:
That argument in contrast I find not very convincing though. What was
the last incidence of such a system call that did not just error out
with ENOTSUPP or such?
http://linux.die.net/man/2/posix_fadvise
On Thu, May 30, 2013 at 12:06 AM, Jeff Davis pg...@j-davis.com wrote:
AFAICS, the main benefit of eliminating PD_ALL_VISIBLE is that we
eliminate one write cycle; that is, we won't dirty the page once to
hint it and then again to mark it all-visible. But as of 9.3, that
should really only be
On 5/30/13 7:52 AM, Andres Freund wrote:
fadvise is a hint which is pretty
different from a fallocate where ignoring would have way much more
severe consequences.
Yes, it will. That's why I want to see it tested. There is more than
enough past examples of bad behavior here to be skeptical
On Thu, May 30, 2013 at 7:13 AM, Andres Freund and...@2ndquadrant.com wrote:
Surely this is undue pessimism.
Why? The spec doesn't specify that case and that very well allows other
behaviour. Glibc sure does behave sensibly and zeroes the data
(sysdeps/posix/posix_fallocate64.c for the
On 2013-05-30 07:54:38 -0400, Robert Haas wrote:
On Thu, May 30, 2013 at 12:06 AM, Jeff Davis pg...@j-davis.com wrote:
AFAICS, the main benefit of eliminating PD_ALL_VISIBLE is that we
eliminate one write cycle; that is, we won't dirty the page once to
hint it and then again to mark it
On 2013-05-30 08:02:56 -0400, Robert Haas wrote:
On Thu, May 30, 2013 at 7:13 AM, Andres Freund and...@2ndquadrant.com wrote:
Surely this is undue pessimism.
Why? The spec doesn't specify that case and that very well allows other
behaviour. Glibc sure does behave sensibly and zeroes the
On 5/30/13 7:13 AM, Andres Freund wrote:
Why? The spec doesn't specify that case and that very well allows other
behaviour. Glibc sure does behave sensibly and zeroes the data
(sysdeps/posix/posix_fallocate64.c for the generic implementation) and
so does linux' fallocate() syscall, but that
On 5/30/13 8:02 AM, Robert Haas wrote:
If there's some OS out
there that chooses to fill the pre-extended pages with 0x55 or cat
/dev/urandom instead of 0x00, they probably deserve what they get.
Even that wouldn't be a problem for our purpose. The only problem would
be if you can't read from
On 2013-05-30 08:19:17 -0400, Peter Eisentraut wrote:
On 5/30/13 8:02 AM, Robert Haas wrote:
If there's some OS out
there that chooses to fill the pre-extended pages with 0x55 or cat
/dev/urandom instead of 0x00, they probably deserve what they get.
Even that wouldn't be a problem for
On 2013-05-30 08:17:28 -0400, Peter Eisentraut wrote:
On 5/30/13 7:13 AM, Andres Freund wrote:
Why? The spec doesn't specify that case and that very well allows other
behaviour. Glibc sure does behave sensibly and zeroes the data
(sysdeps/posix/posix_fallocate64.c for the generic
On 05/29/2013 06:08 PM, Cédric Villemain wrote:
I just took time to inspect our contribs, USE_PGXS is not supported by all
of them atm because of SHLIB_PREREQS (it used submake) I have a patch
pending here to fix that. Once all our contribs can build with USE_PGXS I
fix the VPATH.
I've
On 30.05.2013 15:12, Andres Freund wrote:
Now, I am far from being convinced its a good idea to get rid of
PD_ALL_VISIBLE, but I don't think it does. Except that it currently is
legal for the page level ALL_VISIBLE being set while the corresponding
visibilitymap one isn't there's not much
On 2013-05-30 15:34:04 +0300, Heikki Linnakangas wrote:
On 30.05.2013 15:12, Andres Freund wrote:
Now, I am far from being convinced its a good idea to get rid of
PD_ALL_VISIBLE, but I don't think it does. Except that it currently is
legal for the page level ALL_VISIBLE being set while the
On May 29, 2013, at 11:07 AM, Bruce Momjian wrote:
On Wed, May 29, 2013 at 08:59:42AM -0400, Ray Stell wrote:
[ moved to hacker ]
The question is whether hard-wiring these helps more than it hurts, and
which ones should be hard-wired.
I seems to me that superuser is exactly that special
* Peter Eisentraut (pete...@gmx.net) wrote:
On 5/30/13 7:13 AM, Andres Freund wrote:
Why? The spec doesn't specify that case and that very well allows other
behaviour. Glibc sure does behave sensibly and zeroes the data
(sysdeps/posix/posix_fallocate64.c for the generic implementation) and
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-05-30 08:19:17 -0400, Peter Eisentraut wrote:
On 5/30/13 8:02 AM, Robert Haas wrote:
If there's some OS out
there that chooses to fill the pre-extended pages with 0x55 or cat
/dev/urandom instead of 0x00, they probably deserve
* Andres Freund (and...@2ndquadrant.com) wrote:
But really, I am not at all concerned about some obscure values being
returned, but about a read() not being successful..
Alright, so what do we need to do to test this? We really just need a
short C program written up and then a bunch of folks
On 2013-05-30 08:53:37 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
But really, I am not at all concerned about some obscure values being
returned, but about a read() not being successful..
Alright, so what do we need to do to test this? We really just need
* Andres Freund (and...@2ndquadrant.com) wrote:
After a bit of standard perusing writing a single byte to the end of the
file after the fallocate ought to make at least the reading guaranteed
to be defined. If we did seek(last_byte); write(); posix_fallocate() we
should even always have
Le jeudi 30 mai 2013 14:32:46, Stefan Kaltenbrunner a écrit :
On 05/29/2013 06:08 PM, Cédric Villemain wrote:
I just took time to inspect our contribs, USE_PGXS is not supported by
all of them atm because of SHLIB_PREREQS (it used submake) I have a
patch pending here to fix that. Once all
On 5/30/13 8:50 AM, Stephen Frost wrote:
I don't think this solves the locking issue around the
relation extention lock, but it might help some and it may make it
easier to tweak that logic to allocate larger chunks in the future.
It might make it a bit faster, but it doesn't make it any
Since we're bashing around ideas around freezing, let me write down the
idea I've been pondering and discussing with various people for years. I
don't think I invented this myself, apologies to whoever did for not
giving credit.
The reason we have to freeze is that otherwise our 32-bit XIDs
On Thu, May 30, 2013 at 8:14 AM, Andres Freund and...@2ndquadrant.com wrote:
I don't think there's much danger of getting uninitialized data or
such. That clearly would be insane. I think somebody might interpret it
as read(2) returning an error until the page has been written to which
isn't
On Thu, May 30, 2013 at 8:12 AM, Andres Freund and...@2ndquadrant.com wrote:
As far as I understand the trick basically is that we can rely on an FPI
being logged when an action unsetting ALL_VISIBLE is performed. That
all-visible would then make sure the hint-bits marking indvidual tuples
as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/30/2013 02:02 AM, Dimitri Fontaine wrote:
Joe Conway m...@joeconway.com writes:
Here's a cleaned up version, which also includes documentation.
I'll commit back to 9.1 in a day or two unless there are any
objections.
Looks good to me.
On Wed, May 29, 2013 at 10:51 PM, Amit Langote amitlangot...@gmail.com wrote:
So, it appears, for search strings consisting of 2 (or 3)
characters, trigrams can not be utilized. No?
I think that's right. trigram means a sequence of three characters,
and what's stored in the indexes are
On Thu, May 30, 2013 at 11:47 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 29, 2013 at 10:51 PM, Amit Langote amitlangot...@gmail.com
wrote:
So, it appears, for search strings consisting of 2 (or 3)
characters, trigrams can not be utilized. No?
I think that's right. trigram
Joe Conway m...@joeconway.com writes:
Were you able to test it against an extension containing both rules
and views, to check that pg_dump has no problem with the new set
of dependencies?
PostGIS has both:
[...]
# pg_dump test /tmp/test-02.dmp
# diff /tmp/test-01.dmp /tmp/test-02.dmp
Greg Smith escribió:
The messy part of extending relations in larger chunks
is how to communicate that back into the buffer manager usefully.
The extension path causing trouble is RelationGetBufferForTuple
calling ReadBufferBI. All of that is passing a single buffer
around. There's no
On 5/30/13 11:21 AM, Alvaro Herrera wrote:
Greg Smith escribió:
The messy part of extending relations in larger chunks
is how to communicate that back into the buffer manager usefully.
The extension path causing trouble is RelationGetBufferForTuple
calling ReadBufferBI. All of that is passing
On Thu, May 30, 2013 at 11:00 AM, Amit Langote amitlangot...@gmail.com wrote:
Was there any improvement to pg_trgm in recent past that could make it
better for partial matching (the case in question I suppose) or is
partial-matching a different thing altogether?
Sorry, I am not sure.
--
2013/5/31 Amit Langote amitlangot...@gmail.com
On Thu, May 30, 2013 at 11:47 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 29, 2013 at 10:51 PM, Amit Langote amitlangot...@gmail.com
wrote:
So, it appears, for search strings consisting of 2 (or 3)
characters, trigrams can not
Testing 9.3beta, it seems that array_remove() may return an empty 1-d
array whose upper bound is lower than its lower bound. I know that we
discussed allowing this kind of array, but I don't think that
discussion reached any conclusion, other than to agree that the
current empty 0-d array
On Thu, 2013-05-30 at 11:32 +0300, Heikki Linnakangas wrote:
That could cause a torn page and checksum failure if checksums are
enabled.
Thank you, I missed that in the rebase; it should be
MarkBufferDirtyHint().
Come to think of it, even without the torn page checksum issue, do we
Heikki,
This sounds a lot like my idea for 9.3, which didn't go anywhere.
You've worked out the issues I couldn't, I think.
Another method is
to store the 32-bit xid values in tuple headers as offsets from the
per-page 64-bit value, but then you'd always need to have the 64-bit
value at hand
On Thu, May 30, 2013 at 9:33 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
The reason we have to freeze is that otherwise our 32-bit XIDs wrap around
and become ambiguous. The obvious solution is to extend XIDs to 64 bits, but
that would waste a lot space. The trick is to add a field to
On Thu, May 30, 2013 at 1:39 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 30, 2013 at 9:33 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
The reason we have to freeze is that otherwise our 32-bit XIDs wrap around
and become ambiguous. The obvious solution is to extend XIDs
Folks,
There's currently some great ideas bouncing around about eliminating the
overhead associated with FREEZE. However, I wanted to take a step back
and take a look at the big picture for VACUUM, FREEZE and ANALYZE.
Otherwise, we're liable to repeat the 8.4 problem of making one
operation
Hi,
On 2013-05-30 11:48:12 -0700, Josh Berkus wrote:
There's currently some great ideas bouncing around about eliminating the
overhead associated with FREEZE. However, I wanted to take a step back
and take a look at the big picture for VACUUM, FREEZE and ANALYZE.
Otherwise, we're liable to
On 30 May 2013 19:48, Josh Berkus j...@agliodbs.com wrote:
Folks,
There's currently some great ideas bouncing around about eliminating the
overhead associated with FREEZE. However, I wanted to take a step back
and take a look at the big picture for VACUUM, FREEZE and ANALYZE.
Otherwise,
On 30.05.2013 21:46, Merlin Moncure wrote:
On Thu, May 30, 2013 at 1:39 PM, Robert Haasrobertmh...@gmail.com wrote:
On Thu, May 30, 2013 at 9:33 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
The reason we have to freeze is that otherwise our 32-bit XIDs wrap around
and become
Problem: As of 9.3, there's a significant benefit to vacuum freezing
tables early so that index-only scan is enabled, since freezing also
updates the visibility map. However, with default settings, such
freezing only happens for data which is very old. This means that
index-only scan is less
Inhowfar did 8.4 make freezing worse? I can't remember any new problems
there?
Before the Visibility Map, we always vacuumed all pages in a relation
when it was vacuumed at all. This means that we froze tuples at
vacuum_min_freeze_age, not at autovacuum_max_freeze_age, which is when
we do it
On 2013-05-30 12:11:23 -0700, Josh Berkus wrote:
Inhowfar did 8.4 make freezing worse? I can't remember any new problems
there?
Before the Visibility Map, we always vacuumed all pages in a relation
when it was vacuumed at all. This means that we froze tuples at
vacuum_min_freeze_age,
On 2013-05-30 20:01:01 +0100, Thom Brown wrote:
Problem: As of 9.3, there's a significant benefit to vacuum freezing
tables early so that index-only scan is enabled, since freezing also
updates the visibility map. However, with default settings, such
freezing only happens for data which is
If we have reason to vacuum the relation we do it at
vacuum_freeze_table_age, not only at autovacuum_max_freeze_age. The
difference is that the latter triggers a vacuum, while the former only
changes a partial vacuum into a full one.
Calling that behaviour unconditionally worse is, err,
On 2013-05-30 14:39:46 -0400, Robert Haas wrote:
Since we're not storing 64-bit wide XIDs on every tuple, we'd still need to
replace the XIDs with FrozenXid whenever the difference between the smallest
and largest XID on a page exceeds 2^31. But that would only happen when
you're updating
On Thu, May 30, 2013 at 12:49 PM, Sawada Masahiko sawada.m...@gmail.comwrote:
following emails are discussed about partial match of pg_trgm. I hope
will this help.
http://www.postgresql.org/message-id/cahgqgwfjshvv2ngme19wdtw9tefw_w7h2ns4e+yysjkb9wd...@mail.gmail.com
as you may know, if
On 2013-05-30 12:18:29 -0700, Josh Berkus wrote:
If we have reason to vacuum the relation we do it at
vacuum_freeze_table_age, not only at autovacuum_max_freeze_age. The
difference is that the latter triggers a vacuum, while the former only
changes a partial vacuum into a full one.
On Thu, May 30, 2013 at 04:33:50PM +0300, Heikki Linnakangas wrote:
This would also be the first step in allowing the clog to grow
larger than 2 billion transactions, eliminating the need for
anti-wraparound freezing altogether. You'd still want to truncate
the clog eventually, but it would be
On Fri, May 31, 2013 at 4:25 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
On Thu, May 30, 2013 at 12:49 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
following emails are discussed about partial match of pg_trgm. I hope
will this help.
On Thu, May 30, 2013 at 3:22 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-05-30 14:39:46 -0400, Robert Haas wrote:
Since we're not storing 64-bit wide XIDs on every tuple, we'd still need to
replace the XIDs with FrozenXid whenever the difference between the
smallest
and
On Fri, May 31, 2013 at 4:25 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
On Thu, May 30, 2013 at 12:49 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
following emails are discussed about partial match of pg_trgm. I hope
will this help.
On Thu, May 30, 2013 at 2:39 PM, Robert Haas robertmh...@gmail.com wrote:
Random thought: Could you compute the reference XID based on the page
LSN? That would eliminate the storage overhead.
After mulling this over a bit, I think this is definitely possible.
We begin a new half-epoch every 2
73 matches
Mail list logo
