Re: [HACKERS] Freezing without write I/O

On Thu, May 30, 2013 at 2:39 PM, Robert Haas 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 billion transactio

Re: [HACKERS] Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries

On Fri, May 31, 2013 at 4:25 AM, Alexander Korotkov wrote: > On Thu, May 30, 2013 at 12:49 PM, Sawada Masahiko > wrote: >> >> following emails are discussed about partial match of pg_trgm. I hope >> will this help. >> >>

Re: [HACKERS] Freezing without write I/O

On Thu, May 30, 2013 at 3:22 PM, Andres Freund 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 largest XID on

Re: [HACKERS] Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries

On Fri, May 31, 2013 at 4:25 AM, Alexander Korotkov wrote: > On Thu, May 30, 2013 at 12:49 PM, Sawada Masahiko > wrote: >> >> following emails are discussed about partial match of pg_trgm. I hope >> will this help. >> >>

Re: [HACKERS] Freezing without write I/O

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

Re: [HACKERS] Vacuum, Freeze and Analyze: the big picture

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 on

Re: [HACKERS] Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries

On Thu, May 30, 2013 at 12:49 PM, Sawada Masahiko wrote: > 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 search string

Re: [HACKERS] Freezing without write I/O

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 up

Re: [HACKERS] Vacuum, Freeze and Analyze: the big picture

> 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, er

Re: [HACKERS] Vacuum, Freeze and Analyze: the big picture

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

Re: [HACKERS] Vacuum, Freeze and Analyze: the big picture

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_freez

Re: [HACKERS] Vacuum, Freeze and Analyze: the big picture

> 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

Re: [HACKERS] Vacuum, Freeze and Analyze: the big picture

> "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

Re: [HACKERS] Freezing without write I/O

On 30.05.2013 21:46, Merlin Moncure wrote: On Thu, May 30, 2013 at 1:39 PM, Robert Haas wrote: On Thu, May 30, 2013 at 9:33 AM, Heikki Linnakangas 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

Re: [HACKERS] Vacuum, Freeze and Analyze: the big picture

On 30 May 2013 19:48, Josh Berkus 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, we're liable to

Re: [HACKERS] Vacuum, Freeze and Analyze: the big picture

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 t

[HACKERS] Vacuum, Freeze and Analyze: the big picture

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 bette

Re: [HACKERS] Freezing without write I/O

On Thu, May 30, 2013 at 1:39 PM, Robert Haas wrote: > On Thu, May 30, 2013 at 9:33 AM, Heikki Linnakangas > 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 lo

Re: [HACKERS] Freezing without write I/O

On Thu, May 30, 2013 at 9:33 AM, Heikki Linnakangas 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 the page header > in

Re: [HACKERS] Freezing without write I/O

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 h

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

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 >

[HACKERS] 9.3: Empty arrays returned by array_remove()

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 behaviour

Re: [HACKERS] Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries

2013/5/31 Amit Langote > > On Thu, May 30, 2013 at 11:47 PM, Robert Haas wrote: > > On Wed, May 29, 2013 at 10:51 PM, Amit Langote > > wrote: > >> So, it appears, for search strings consisting of 2 (or < 3) > >> characters, trigrams can not be utilized. No? > > > > I think that's right. "trigr

Re: [HACKERS] Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries

On Thu, May 30, 2013 at 11:00 AM, Amit Langote 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. -- Robert Haas EnterpriseDB:

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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

Re: [HACKERS] pg_dump with postgis extension dumps rules separately

Joe Conway 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 > .. Per

Re: [HACKERS] Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries

On Thu, May 30, 2013 at 11:47 PM, Robert Haas wrote: > On Wed, May 29, 2013 at 10:51 PM, Amit Langote > 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

Re: [HACKERS] Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries

On Wed, May 29, 2013 at 10:51 PM, Amit Langote 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 three-character sequences

Re: [HACKERS] pg_dump with postgis extension dumps rules separately

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/30/2013 02:02 AM, Dimitri Fontaine wrote: > Joe Conway 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

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

On Thu, May 30, 2013 at 8:14 AM, Andres Freund 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 completely crazy. I

Re: [HACKERS] removing PD_ALL_VISIBLE

On Thu, May 30, 2013 at 8:12 AM, Andres Freund 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 frozen would hit di

[HACKERS] Freezing without write I/O

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 wr

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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 easier

Re: [HACKERS] PostgreSQL 9.3 beta breaks some extensions "make install"

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. O

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

* 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 def

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

* 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

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

* 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

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

* 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

Re: [HACKERS] [GENERAL] pg_upgrade -u

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 s

Re: [HACKERS] removing PD_ALL_VISIBLE

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 t

Re: [HACKERS] removing PD_ALL_VISIBLE

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 prohibi

Re: [HACKERS] PostgreSQL 9.3 beta breaks some extensions "make install"

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. > >

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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 impl

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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 proble

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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 fr

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

On 2013-05-30 08:02:56 -0400, Robert Haas wrote: > On Thu, May 30, 2013 at 7:13 AM, Andres Freund 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 > > (sysd

Re: [HACKERS] removing PD_ALL_VISIBLE

On 2013-05-30 07:54:38 -0400, Robert Haas wrote: > On Thu, May 30, 2013 at 12:06 AM, Jeff Davis 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.

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

On Thu, May 30, 2013 at 7:13 AM, Andres Freund 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 generic implementation)

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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 th

Re: [HACKERS] removing PD_ALL_VISIBLE

On Thu, May 30, 2013 at 12:06 AM, Jeff Davis 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 a problem

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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 POSIX_FADV_WIL

[HACKERS] extensible external toast tuple support

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 concep

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

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 > >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. >

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

On 2013-05-30 06:49:42 -0400, Robert Haas wrote: > On Wed, May 29, 2013 at 10:42 AM, Andres Freund > 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

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

On 5/30/13 6:49 AM, Robert Haas wrote: On Wed, May 29, 2013 at 10:42 AM, Andres Freund 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 found the Linux kernel de

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

On Wed, May 29, 2013 at 10:42 AM, Andres Freund 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 not fail due to t

Re: [HACKERS] pg_dump with postgis extension dumps rules separately

Joe Conway 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 has no problem wi

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

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 *va

Re: [HACKERS] units in postgresql.conf comments

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 "wal_

Re: [HACKERS] Eliminating PD_ALL_VISIBLE, take 2

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, } /*

Re: [HACKERS] units in postgresql.conf comments

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

Re: [HACKERS] units in postgresql.conf comments

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.

Re: [HACKERS] [PATCH] add --throttle to pgbench (submission 3)

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 > >> transactio

Re: [HACKERS] units in postgresql.conf comments

On Thu, May 30, 2013 at 3:52 AM, 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: V

Re: [HACKERS] [PATCH] add --throttle to pgbench (submission 3)

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 >

Re: [HACKERS] units in postgresql.conf comments

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 y

Re: [HACKERS] [PATCH] add --throttle to pgbench (submission 3)

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 n

Re: [HACKERS] units in postgresql.conf comments

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 th