Re: [HACKERS] augmenting MultiXacts to improve foreign keys

On Tue, Aug 09, 2011 at 01:01:04PM -0400, Alvaro Herrera wrote: > KEY UPDATEFOR UPDATE FOR SHARE KEY SHARE > KEY UPDATE X XX X > FOR UPDATE X XX > FOR SHAREX X > KEY SHAREX > > DE

Re: [HACKERS] augmenting MultiXacts to improve foreign keys

On Aug9, 2011, at 22:40 , Tom Lane wrote: > Alvaro Herrera writes: >> Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011: >>> Right now, FKs aren't really very special, they are mostly just >>> syntactic sugar (right?). This proposal would make FKs special internal >>> mechanisms

Re: [HACKERS] augmenting MultiXacts to improve foreign keys

On Aug10, 2011, at 08:45 , Noah Misch wrote: > On Tue, Aug 09, 2011 at 09:41:00PM +0200, Florian Pflug wrote: >> Couldn't we simply give the user a way to specify, per column, whether or >> not that column is a "KEY" column? Creating a foreign key constraint could >> still implicitly mark all refer

Re: [HACKERS] Reduced power consumption in autovacuum launcher process

On 10 August 2011 01:35, Tom Lane wrote: > Actually, I'm nearly done with it already.  Perhaps you could start > thinking about the other polling loops. Fair enough. I'm slightly surprised that there doesn't need to be some bikeshedding about my idea to treat the PGPROC latch as the generic, per-

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

On 09.08.2011 19:07, Tom Lane wrote: Heikki Linnakangas writes: On 09.08.2011 18:20, Alvaro Herrera wrote: How about making the new backup_label field optional? If absent, assume current behavior. That's how I actually did it in the patch. However, the problem wrt. requiring initdb is not

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

On Tue, Aug 9, 2011 at 18:07, Tom Lane wrote: > Heikki Linnakangas writes: >> On 09.08.2011 18:20, Alvaro Herrera wrote: >>> How about making the new backup_label field optional?  If absent, assume >>> current behavior. > >> That's how I actually did it in the patch. However, the problem wrt. >>

Re: [HACKERS] some missing internationalization in pg_basebackup

On Tue, Aug 9, 2011 at 13:38, Peter Eisentraut wrote: > I noticed that the progress reporting code in pg_basebackup does not > allow for translation.  This would normally be easy to fix, but this > code has a number of tricky issues, including the INT64_FORMAT, possibly > some plural concerns, and

Re: [HACKERS] WIP: Fast GiST index build

Hi! Here is last verion of the patch. List of changes: 1) Neighbor relocation and prefetch were removed. They will be supplied as separate patches. 2) Final emptying now using standart lists of all buffers by levels. 3) Automatic switching again use simple comparison of index size and effective_ca

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

On 10.08.2011 12:29, Magnus Hagander wrote: On Tue, Aug 9, 2011 at 18:07, Tom Lane wrote: Heikki Linnakangas writes: On 09.08.2011 18:20, Alvaro Herrera wrote: How about making the new backup_label field optional? If absent, assume current behavior. That's how I actually did it in the pa

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas wrote: > On 10.08.2011 12:29, Magnus Hagander wrote: >> >> On Tue, Aug 9, 2011 at 18:07, Tom Lane  wrote: >>> >>> Heikki Linnakangas  writes: On 09.08.2011 18:20, Alvaro Herrera wrote: > > How about making the new backup_label fie

Re: [HACKERS] SSL-mode error reporting in libpq

On Sun, Jul 24, 2011 at 20:48, Tom Lane wrote: > In testing the fix for the SSL problem that Martin Pihlak reported, I > realized that libpq doesn't really cope very well with errors reported > by OpenSSL.  In the case at hand, SSL_write returns an SSL_ERROR_SSL > code, which pqsecure_write quite

Re: [HACKERS] longstanding mingw warning

On Tue, Jul 26, 2011 at 15:20, Andrew Dunstan wrote: > > Why do we get this warning on Mingw?: > >   x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -Wformat-security > -fno-strict-aliasing -fwrapv -g -I../../../../src/include >

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander wrote: > On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas > wrote: >> On 10.08.2011 12:29, Magnus Hagander wrote: >>> >>> On Tue, Aug 9, 2011 at 18:07, Tom Lane  wrote: Heikki Linnakangas  writes: > > On 09.08.2011 18:20, Alvaro

Re: [HACKERS] index sizes: single table vs partitioned

On Mon, Aug 8, 2011 at 1:38 PM, Andrew Hammond wrote: > For a large table, should there be a difference in index sizes between a > single table representation and representation based on multiple partitions > with identical indexes? This isn't really the right mailing list for this question; this

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

On Wed, Aug 10, 2011 at 1:19 PM, Robert Haas wrote: > On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander wrote: >> On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas >> wrote: >>> On 10.08.2011 12:29, Magnus Hagander wrote: On Tue, Aug 9, 2011 at 18:07, Tom Lane  wrote: > > Heikki

Re: [HACKERS] Review of VS 2010 support patches

On Sun, Jul 31, 2011 at 03:25, Andrew Dunstan wrote: > > > On 07/06/2011 08:26 PM, Brar Piening wrote: >> >> Original Message   >> Subject: Re: [HACKERS] Review of VS 2010 support patches >> From: Andrew Dunstan >> To: Brar Piening >> Date: 06.07.2011 22:58 >> I'll remove m

Re: [HACKERS] Review of VS 2010 support patches

On Wed, Aug 10, 2011 at 9:03 AM, Magnus Hagander wrote: > I am no perl expert, but I see we are using this already today - in > code written by you in one case ;) I'd assume it was just following > the same standard... If the other way is the way to do it today, I see > no reason not to change it

Re: [HACKERS] Review of VS 2010 support patches

On 08/10/2011 09:03 AM, Magnus Hagander wrote: On Sun, Jul 31, 2011 at 03:25, Andrew Dunstan wrote: On 07/06/2011 08:26 PM, Brar Piening wrote: Original Message Subject: Re: [HACKERS] Review of VS 2010 support patches From: Andrew Dunstan To: Brar Piening Date: 06.07.2011

Re: [HACKERS] Review of VS 2010 support patches

On 08/10/2011 09:21 AM, Robert Haas wrote: On Wed, Aug 10, 2011 at 9:03 AM, Magnus Hagander wrote: I am no perl expert, but I see we are using this already today - in code written by you in one case ;) I'd assume it was just following the same standard... If the other way is the way to do it

Re: [HACKERS] Review of VS 2010 support patches

On Wed, Aug 10, 2011 at 15:25, Andrew Dunstan wrote: > > > On 08/10/2011 09:03 AM, Magnus Hagander wrote: >> >> On Sun, Jul 31, 2011 at 03:25, Andrew Dunstan  wrote: >>> >>> On 07/06/2011 08:26 PM, Brar Piening wrote: Original Message   Subject: Re: [HACKERS] Review

Re: [HACKERS] Reduced power consumption in autovacuum launcher process

Peter Geoghegan writes: > On 10 August 2011 01:35, Tom Lane wrote: >> Actually, I'm nearly done with it already.  Perhaps you could start >> thinking about the other polling loops. > Fair enough. I'm slightly surprised that there doesn't need to be some > bikeshedding about my idea to treat the

Re: [HACKERS] longstanding mingw warning

On 08/10/2011 08:08 AM, Magnus Hagander wrote: On Tue, Jul 26, 2011 at 15:20, Andrew Dunstan wrote: Why do we get this warning on Mingw?: x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasi

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

On 10.08.2011 15:34, Simon Riggs wrote: On Wed, Aug 10, 2011 at 1:19 PM, Robert Haas wrote: On Wed, Aug 10, 2011 at 6:53 AM, Magnus Hagander wrote: On Wed, Aug 10, 2011 at 12:44, Heikki Linnakangas wrote: On 10.08.2011 12:29, Magnus Hagander wrote: On Tue, Aug 9, 2011 at 18:07, Tom Lane

[HACKERS] gcc 4.6 warnings in HEAD?

Hi, I'm seeing a bunch of warnings I don't remember seeing before in the master branch: /pgsql/source/HEAD/src/backend/executor/execQual.c: In function 'GetAttributeByNum': /pgsql/source/HEAD/src/backend/executor/execQual.c:1104:11: warning: the comparison will always evaluate as 'true' for the

Re: [HACKERS] Reduced power consumption in autovacuum launcher process

Peter Geoghegan writes: > Attached is revision of this patch that now treats the latch in > PGPROC, waitLatch, as the generic "process latch", rather than just > using it for sync rep; It is initialised appropriately as a shared > latch generically, within InitProcGlobal(), and ownership is > subs

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On 08/09/2011 04:32 PM, Tom Lane wrote: Andrew Dunstan writes: On 08/09/2011 12:22 PM, Tom Lane wrote: No. As I pointed out upthread, the instant somebody changes the SIGALRM handler to a non-Postgres-aware one, you are already at risk of failure. Setting it back later is just locking the b

Re: [HACKERS] Policy on pulling in code from other projects?

On Aug 9, 2011, at 6:00 PM, Peter van Hardenberg wrote: > In conclusion, this is a serious operational concern for me and my team and I > will be personally dealing with fires caused by this for years to come > regardless of the outcome of this thread. Do you have an interest in funding develop

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On Aug 10, 2011, at 9:44 AM, Andrew Dunstan wrote: > After some experimentation, I found that, at least on my system, if LWP uses > Crypt::SSLeay for https requests then it sets an alarm handler, but if > instead it uses IO::Socket::SSL an alarm handler is not set. So the answer to > the OP's o

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

Andrew Dunstan writes: > On 08/09/2011 04:32 PM, Tom Lane wrote: >> [ shrug... ] Installing a perl module that mucks with the signal >> handlers is in the "don't do that" category. A kluge such as you >> suggest will not get it out of that category; all it will do is add >> useless overhead for

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

Heikki Linnakangas writes: > Hmm, that's not possible for the 'tar' output, but would work for 'dir' > output. Another similar idea would be to withhold the control file in > memory until the end of backup, and append it to the output as last. The > backup can't be restored until the control fi

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

On Wed, Aug 10, 2011 at 1:45 PM, Tom Lane wrote: > Heikki Linnakangas writes: >> Hmm, that's not possible for the 'tar' output, but would work for 'dir' >> output. Another similar idea would be to withhold the control file in >> memory until the end of backup, and append it to the output as last.

Re: [HACKERS] gcc 4.6 warnings in HEAD?

On ons, 2011-08-10 at 12:37 -0400, Alvaro Herrera wrote: > I'm seeing a bunch of warnings I don't remember seeing before in the > master branch: > > /pgsql/source/HEAD/src/backend/executor/execQual.c: In function > 'GetAttributeByNum': > /pgsql/source/HEAD/src/backend/executor/execQual.c:1104:11:

[HACKERS] SHOW command always returns text field

I was slightly surprised the other day that the SHOW command always returns a field of type text even if the underlying parameter has one of the other types (int, real, etc.). Is this intentional? Would it be worth refining? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Reduced power consumption in autovacuum launcher process

On Wed, Aug 10, 2011 at 3:08 PM, Tom Lane wrote: > Peter Geoghegan writes: >> On 10 August 2011 01:35, Tom Lane wrote: >>> Actually, I'm nearly done with it already.  Perhaps you could start >>> thinking about the other polling loops. > >> Fair enough. I'm slightly surprised that there doesn't n

[HACKERS] sha1, sha2 functions into core?

I would like to see whether there is support for adding sha1 and sha2 functions into the core. These are obviously well-known and widely used functions, but currently the only way to get them is either through pgcrypto or one of the PLs. We could say that's OK, but then we do support md5 in core,

Re: [HACKERS] SHOW command always returns text field

Peter Eisentraut writes: > I was slightly surprised the other day that the SHOW command always > returns a field of type text even if the underlying parameter has one of > the other types (int, real, etc.). Is this intentional? Would it be > worth refining? I'm disinclined to mess with it. One

Re: [HACKERS] Enforcing that all WAL has been replayed after restoring from backup

On Wed, Aug 10, 2011 at 19:45, Tom Lane wrote: > Heikki Linnakangas writes: >> Hmm, that's not possible for the 'tar' output, but would work for 'dir' >> output. Another similar idea would be to withhold the control file in >> memory until the end of backup, and append it to the output as last. T

Re: [HACKERS] sha1, sha2 functions into core?

Peter Eisentraut writes: > I would like to see whether there is support for adding sha1 and sha2 > functions into the core. I can't get excited about that, but could put up with it as long as there wasn't scope creep ... > One thing that might be reasonable would be to move the digest() > functi

Re: [HACKERS] longstanding mingw warning

On Wed, Aug 10, 2011 at 17:25, Andrew Dunstan wrote: > > > On 08/10/2011 08:08 AM, Magnus Hagander wrote: >> >> On Tue, Jul 26, 2011 at 15:20, Andrew Dunstan  wrote: >>> >>> Why do we get this warning on Mingw?: >>> >>>   x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith >>> -W

Re: [HACKERS] sha1, sha2 functions into core?

On 08/10/2011 02:06 PM, Peter Eisentraut wrote: I would like to see whether there is support for adding sha1 and sha2 functions into the core. These are obviously well-known and widely used functions, but currently the only way to get them is either through pgcrypto or one of the PLs. We coul

Re: [HACKERS] sha1, sha2 functions into core?

On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstan wrote: > It's come up before: > I was about to wonder out loud if we might be trying to hit a moving target -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterp

Re: [HACKERS] SHOW command always returns text field

Excerpts from Tom Lane's message of mié ago 10 14:12:49 -0400 2011: > Peter Eisentraut writes: > > I was slightly surprised the other day that the SHOW command always > > returns a field of type text even if the underlying parameter has one of > > the other types (int, real, etc.). Is this intent

Re: [HACKERS] sha1, sha2 functions into core?

On Wed, Aug 10, 2011 at 7:06 PM, Peter Eisentraut wrote: > I would like to see whether there is support for adding sha1 and sha2 > functions into the core.  These are obviously well-known and widely used > functions, but currently the only way to get them is either through > pgcrypto or one of the

Re: [HACKERS] sha1, sha2 functions into core?

On ons, 2011-08-10 at 19:29 +0100, Dave Page wrote: > On Wed, Aug 10, 2011 at 7:06 PM, Peter Eisentraut wrote: > > I would like to see whether there is support for adding sha1 and sha2 > > functions into the core. These are obviously well-known and widely used > > functions, but currently the onl

[HACKERS] "pgstat wait timeout" warnings

We occasionally see $SUBJECT in the buildfarm, and I've also recently had reports of them from Red Hat customers. The obvious theory is that these reflect high load preventing the stats collector from responding, but it would really take pretty crushing load to make that happen if there were not a

Re: [HACKERS] sha1, sha2 functions into core?

On ons, 2011-08-10 at 14:26 -0400, Robert Haas wrote: > On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstan wrote: > > It's come up before: > > > > I was about to wonder out loud if we might be trying to hit a moving > target I

Re: [HACKERS] SHOW command always returns text field

Alvaro Herrera writes: > Excerpts from Tom Lane's message of mié ago 10 14:12:49 -0400 2011: >> Peter Eisentraut writes: >>> I was slightly surprised the other day that the SHOW command always >>> returns a field of type text even if the underlying parameter has one of >>> the other types (int,

Re: [HACKERS] "pgstat wait timeout" warnings

On 10.08.2011 21:45, Tom Lane wrote: We occasionally see $SUBJECT in the buildfarm, and I've also recently had reports of them from Red Hat customers. The obvious theory is that these reflect high load preventing the stats collector from responding, but it would really take pretty crushing load

[HACKERS] Possible Bug in pg_upgrade

Beginning with commit 002c105a0706bd1c1e939fe0f47ecdceeae6c52d pg_upgrade will fail if there are orphaned temp tables in the current database with the message 'old and new databases "postgres" have a different number of relations' On line 41 of pg_upgrade/info.c pg_upgrade checks that the number

Re: [HACKERS] sha1, sha2 functions into core?

On 10.08.2011 21:45, Peter Eisentraut wrote: On ons, 2011-08-10 at 14:26 -0400, Robert Haas wrote: On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstan wrote: It's come up before: I was about to wonder out loud if we might be try

Re: [HACKERS] sha1, sha2 functions into core?

On Wed, Aug 10, 2011 at 21:02, Heikki Linnakangas wrote: > On 10.08.2011 21:45, Peter Eisentraut wrote: >> >> On ons, 2011-08-10 at 14:26 -0400, Robert Haas wrote: >>> >>> On Wed, Aug 10, 2011 at 2:24 PM, Andrew Dunstan >>>  wrote: It's come up before:

Re: [HACKERS] Possible Bug in pg_upgrade

Dave Byrne writes: > Beginning with commit 002c105a0706bd1c1e939fe0f47ecdceeae6c52d > pg_upgrade will fail if there are orphaned temp tables in the current > database with the message 'old and new databases "postgres" have a > different number of relations' > On line 41 of pg_upgrade/info.c pg_up

Re: [HACKERS] WIP: Fast GiST index build

Manual and readme updates. -- With best regards, Alexander Korotkov. gist_fast_build-0.12.0.patch.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/mailpref/pgsql-hac

Re: [HACKERS] WIP: Fast GiST index build

On 10.08.2011 13:19, Alexander Korotkov wrote: Hi! Here is last verion of the patch. List of changes: 1) Neighbor relocation and prefetch were removed. They will be supplied as separate patches. unloadNodeBuffers() is now dead code. 2) Final emptying now using standart lists of all buffers b

[HACKERS] wal_sender_delay (WalSndDelay) has served its purpose

AFAICS we could get rid of WalSndDelay: there is no longer any reason for the walsender loop to wake up unless it's received a latch event. (Its WaitLatch call is missing WL_POSTMASTER_DEATH right now, but that is easily fixed.) Is anyone sufficiently attached to that GUC to not want to see it go

Re: [HACKERS] wal_sender_delay (WalSndDelay) has served its purpose

On Wed, Aug 10, 2011 at 10:23 PM, Tom Lane wrote: > AFAICS we could get rid of WalSndDelay: there is no longer any reason > for the walsender loop to wake up unless it's received a latch event. > (Its WaitLatch call is missing WL_POSTMASTER_DEATH right now, but that > is easily fixed.)  Is anyone

Re: [HACKERS] mosbench revisited

Robert Haas writes: > However, it doesn't really do anything to solve this problem. The > problem here is not that the size of the relation is changing too > frequently - indeed, it's not changing at all in this test case. The > problem is rather that testing whether or not the size has in fact

Re: [HACKERS] Possible Bug in pg_upgrade

Attached is a patch that skips orphaned temporary relations in pg_upgrade if they are lingering around. It works for 9.0 -> 9.1 upgrades, however I wasn't able to tell when pg_class.relistemp was added so if it was unavailable in versions prior to 9.0 an additional check will have to be added.

Re: [HACKERS] Possible Bug in pg_upgrade

Dave Byrne writes: > Attached is a patch that skips orphaned temporary relations in pg_upgrade if > they are lingering around. It works for 9.0 -> 9.1 upgrades, however I wasn't > able to tell when pg_class.relistemp was added so if it was unavailable in > versions prior to 9.0 an additional ch

Re: [HACKERS] wal_sender_delay (WalSndDelay) has served its purpose

On Wed, Aug 10, 2011 at 5:29 PM, Simon Riggs wrote: > On Wed, Aug 10, 2011 at 10:23 PM, Tom Lane wrote: > >> AFAICS we could get rid of WalSndDelay: there is no longer any reason >> for the walsender loop to wake up unless it's received a latch event. >> (Its WaitLatch call is missing WL_POSTMAST

Re: [HACKERS] mosbench revisited

2011/8/10 Dimitri Fontaine : > Robert Haas writes: >> However, it doesn't really do anything to solve this problem. The >> problem here is not that the size of the relation is changing too >> frequently - indeed, it's not changing at all in this test case. The >> problem is rather that testing w

Re: [HACKERS] mosbench revisited

Excerpts from Robert Haas's message of mié ago 10 21:27:08 -0400 2011: > 2011/8/10 Dimitri Fontaine : > > Robert Haas writes: > >> However, it doesn't really do anything to solve this problem. The > >> problem here is not that the size of the relation is changing too > >> frequently - indeed, it'

Re: [HACKERS] mosbench revisited

On Wed, Aug 10, 2011 at 9:46 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mié ago 10 21:27:08 -0400 2011: >> 2011/8/10 Dimitri Fontaine : >> > Robert Haas writes: >> >> However, it doesn't really do anything to solve this problem.  The >> >> problem here is not that the size

Re: [HACKERS] WIP: Fast GiST index build

Split of an internal node works like this: 1. Gather all the existing tuples on the page, plus the new tuple being inserted. 2. Call picksplit on the tuples, to divide them into pages 3. Go through all tuples on the buffer associated with the page, and divide them into buffers on the new pages