[HACKERS] Online base backup from the hot-standby

> I will provide a patch which can exeute pg_start/stop_backup > including to solve above comment and conditions in next stage. > Then please review. done. * Procedure 1. Call pg_start_backup('x') on the standby. 2. Take a backup of the data dir. 3. Call pg_stop_backup() on the standby. 4. Copy

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

On 05.08.2011 04:23, Jeff Davis wrote: On Thu, 2011-08-04 at 20:55 -0400, Bruce Momjian wrote: It would act like COPY, meaning the table would have to be truncated or created in the same transaction. Well, in that case it could work for any INSERT. No need for a SELECT to be involved. For that

[HACKERS] Re: [GENERAL] Odd VACUUM behavior when it is expected to truncate last empty pages

Thank you very much, your explanation helped a lot. This is the tool I needed the solution for http://code.google.com/p/pc-tools/ if you are interested. On 4 August 2011 01:10, Pavan Deolasee wrote: > On Wed, Aug 3, 2011 at 12:33 PM, Pavan Deolasee > wrote: >> >> >> The only problem, other than

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

On Thu, Aug 4, 2011 at 19:40, Andrew Dunstan wrote: > Let's slow down a bit. Nobody that we know of has encountered the problem > Tom's referring to, over all the years plperlu has been available. The > changes you're proposing have the potential to downgrade the usefulness of > plperlu considera

Re: [HACKERS] PQescapeByteaConn - returns wrong string for PG9.1 Beta3

Florian Pflug writes: > Just to clarify what's going on here, in case the OP is still puzzled. > [ lots o detail snipped ] Right. Thanks for writing out what I didn't have time for today... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgre

Re: [HACKERS] psql: display of object comments

On Thu, Aug 4, 2011 at 12:26 PM, Robert Haas wrote: > On Tue, Jul 26, 2011 at 8:38 PM, Josh Kupershmidt wrote: >> [new patch] > > I've committed the portion of this that displays comments on languages > and casts. Thanks! > For domains and conversions, I am wondering if we should display the >

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

On 08/04/2011 08:44 PM, Alex Hunsaker wrote: On Thu, Aug 4, 2011 at 17:52, Tom Lane wrote: Alex Hunsaker writes: On Thu, Aug 4, 2011 at 16:34, David E. Wheeler wrote: On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote: 3) local %SIG before we call their trigger function. This lets signals s

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

On Thu, 2011-08-04 at 20:55 -0400, Bruce Momjian wrote: > It would act like COPY, meaning the table would have to be truncated or > created in the same transaction. Well, in that case it could work for any INSERT. No need for a SELECT to be involved. For that matter, why not make it work for DELET

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

On Thu, Aug 4, 2011 at 8:55 PM, Bruce Momjian wrote: > Jeff Davis wrote: >> On Thu, 2011-08-04 at 17:46 -0400, Bruce Momjian wrote: >> > Right.  I brought up SELECT INTO because you could make the argument >> > that INSERT ... SELECT is not a utility command like the other ones and >> > therefore

Re: [HACKERS] psql: bogus descriptions displayed by \d+

On Thu, 2011-08-04 at 14:20 -0500, Kevin Grittner wrote: > Peter Eisentraut wrote: > > > According to scientific-ish database literature, a table is a > > relation and vice versa. > > I've generally understood the terms more like what is described near > the top of this page: > > http://en.w

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

Jeff Davis wrote: > On Thu, 2011-08-04 at 17:46 -0400, Bruce Momjian wrote: > > Right. I brought up SELECT INTO because you could make the argument > > that INSERT ... SELECT is not a utility command like the other ones and > > therefore can't be done easily, but CREATE TABLE AS is internal SELECT

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

On Thu, 2011-08-04 at 17:46 -0400, Bruce Momjian wrote: > Right. I brought up SELECT INTO because you could make the argument > that INSERT ... SELECT is not a utility command like the other ones and > therefore can't be done easily, but CREATE TABLE AS is internal SELECT > INTO and implemented in

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

On Thu, Aug 4, 2011 at 17:52, Tom Lane wrote: > Alex Hunsaker writes: >> On Thu, Aug 4, 2011 at 16:34, David E. Wheeler wrote: >>> On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote: 3) local %SIG before we call their trigger function. This lets signals still work while "in trigger scope"

Re: [HACKERS] Transient plans versus the SPI API

On Wed, 2011-08-03 at 13:07 -0400, Robert Haas wrote: > A little OT here, but (as I think Simon said elsewhere) I think we > really ought to be considering the table statistics when deciding > whether or not to replan. It seems to me that the overwhelmingly > common case where this is going to com

Re: [HACKERS] Transient plans versus the SPI API

On Wed, 2011-08-03 at 12:19 -0400, Tom Lane wrote: > Of course we could address the worst cases by providing some mechanism > to tell the plancache code "always use a generic plan for this query" > or "always use a custom plan". I'm not entirely thrilled with that, > because it's effectively a pla

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

Alex Hunsaker writes: > On Thu, Aug 4, 2011 at 16:34, David E. Wheeler wrote: >> On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote: >>> 3) local %SIG before we call their trigger function. This lets signals >>> still work while "in trigger scope" (like we do for %_TD) >> +1 > That seems to be wha

Re: [HACKERS] error: could not find pg_class tuple for index 2662

Ahh ... you know what, never mind about stack traces, let's just see if the attached patch doesn't fix it. I still haven't reproduced the behavior here, but I think I see what must be happening: we are getting an sinval reset while attempting to open pg_class_oid_index. The latter condition cause

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

On Thu, Aug 4, 2011 at 16:34, David E. Wheeler wrote: > On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote: > >> Mainly the options im thinking about are: >> 1) if anyone touches %SIG die >> 2) turn %SIG into a regular hash so people can set/play with %SIG, but >> it has no real effect. > > These wou

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

On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote: > Mainly the options im thinking about are: > 1) if anyone touches %SIG die > 2) turn %SIG into a regular hash so people can set/play with %SIG, but > it has no real effect. These would disable stuff like $SIG{__WARN__} and $SIG{__DIE__}, which wou

Re: [HACKERS] Transient plans versus the SPI API

On Tue, 2011-08-02 at 16:47 -0400, Tom Lane wrote: > The most straightforward way to reimplement things within spi.c would be > to redefine SPI_prepare as just doing the parse-and-rewrite steps, with > planning always postponed to SPI_execute. In the case where you just > prepare and then execute

Re: [HACKERS] mosbench revisited

On Thu, Aug 4, 2011 at 5:09 PM, Aidan Van Dyk wrote: > On Wed, Aug 3, 2011 at 5:04 PM, Robert Haas wrote: > >>      And hoping that the Linux guys decide to do something about it. >>  This isn't really our bug - lseek is quite cheap in the uncontended >> case. > > Has anyone tried this on a recen

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

On Thu, Aug 4, 2011 at 09:11, Andrew Dunstan wrote: >> What *I'd* like is a way to prevent libperl from touching the host >> application's signal handlers at all.  Sadly, Perl does not actually >> think of itself as an embedded library, and therefore thinks it owns all >> resources of the process

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

Simon Riggs wrote: > On Thu, Aug 4, 2011 at 10:46 PM, Bruce Momjian wrote: > > > Right. ?I brought up SELECT INTO because you could make the argument > > that INSERT ... SELECT is not a utility command like the other ones and > > therefore can't be done easily, but CREATE TABLE AS is internal SEL

Re: [HACKERS] PQescapeByteaConn - returns wrong string for PG9.1 Beta3

On Aug4, 2011, at 22:54 , Tom Lane wrote: > "Petro Meier" writes: >> INSERT INTO "testtable" ("ID", "BinaryContents") values (1, >> E'\xea2abd8ef3'); >> returns "invalid byte sequence". > >> '\xea2abd8ef3' is the string delivered by the PG 9.1 Beta3 serve

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

On Thu, Aug 4, 2011 at 10:46 PM, Bruce Momjian wrote: > Right.  I brought up SELECT INTO because you could make the argument > that INSERT ... SELECT is not a utility command like the other ones and > therefore can't be done easily, but CREATE TABLE AS is internal SELECT > INTO and implemented in

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

Andrew Dunstan wrote: > > > On 08/04/2011 04:55 PM, Tom Lane wrote: > > Bruce Momjian writes: > >> One thing we don't optimize is INSERT ... SELECT when the table is > >> created or truncated in the same transaction. Seems we could. > >> We optimize CREATE TABLE AS which is effectively SELECT .

Re: [HACKERS] error: could not find pg_class tuple for index 2662

daveg writes: > On Thu, Aug 04, 2011 at 04:16:08PM -0400, Tom Lane wrote: >> If this theory is correct then all of the file-related errors ought to >> match up to recently-vacuumed mapped catalogs or indexes (those are the >> ones with relfilenode = 0 in pg_class). Do you want to expand your >> l

Re: [HACKERS] error: could not find pg_class tuple for index 2662

On Thu, Aug 04, 2011 at 04:16:08PM -0400, Tom Lane wrote: > daveg writes: > > We are seeing "cannot read' and 'cannot open' errors too that would be > > consistant with trying to use a vanished file. > > Yeah, these all seem consistent with the idea that the failing backend > somehow missed an up

Re: [HACKERS] mosbench revisited

On Wed, Aug 3, 2011 at 5:04 PM, Robert Haas wrote: >  And hoping that the Linux guys decide to do something about it. >  This isn't really our bug - lseek is quite cheap in the uncontended > case. Has anyone tried this on a recent kernel (i.e. 2.6.39 or later), where they've finally remove t

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

On 08/04/2011 04:55 PM, Tom Lane wrote: Bruce Momjian writes: One thing we don't optimize is INSERT ... SELECT when the table is created or truncated in the same transaction. Seems we could. We optimize CREATE TABLE AS which is effectively SELECT ... INTO using a different syntax. Is this a

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

Bruce Momjian writes: > One thing we don't optimize is INSERT ... SELECT when the table is > created or truncated in the same transaction. Seems we could. > We optimize CREATE TABLE AS which is effectively SELECT ... INTO using a > different syntax. Is this a TODO? Considering that SELECT INTO

Re: [HACKERS] PQescapeByteaConn - returns wrong string for PG9.1 Beta3

"Petro Meier" writes: > INSERT INTO "testtable" ("ID", "BinaryContents") values (1, > E'\xea2abd8ef3'); > returns "invalid byte sequence". > '\xea2abd8ef3' is the string delivered by the PG 9.1 Beta3 server > when calling PQescapeByteaConn(). It canno

Re: [HACKERS] Further news on Clang - spurious warnings

Can we please commit a fix for this problem? -- Peter Geoghegan       http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mai

Re: [HACKERS] PQescapeByteaConn - returns wrong string for PG9.1 Beta3

On Wed, Aug 03, 2011 at 03:19:06PM +0200, Petro Meier wrote: > Normal021false > falsefalseDEX-NONEX-NONE > >

Re: [HACKERS] error: could not find pg_class tuple for index 2662

daveg writes: > We are seeing "cannot read' and 'cannot open' errors too that would be > consistant with trying to use a vanished file. Yeah, these all seem consistent with the idea that the failing backend somehow missed an update for the relation mapping file. You would get the "could not find

Re: [HACKERS] cataloguing NOT NULL constraints

Excerpts from Peter Eisentraut's message of jue ago 04 13:57:54 -0400 2011: > On tis, 2011-08-02 at 23:40 -0400, Alvaro Herrera wrote: > > Thanks. I've done the other changes you suggested, but I don't see that > > it's desirable to have gram.y emit AT_AddConstraint directly. It seems > > cleaner

Re: [HACKERS] possible new feature: asynchronous sql or something like oracles dbms_job.submit

On 08/03/2011 09:20 AM, Vorarlberger wrote: > sadly what i realy miss is the possibility of asynchronous sql. which > means the need to perform an sql in a completely different new session. > something i could do in oracle with dbms_job.submit. Would this work for you? http://www.postgresql.org/do

Re: [HACKERS] error: could not find pg_class tuple for index 2662

On Thu, Aug 04, 2011 at 12:28:31PM -0400, Tom Lane wrote: > daveg writes: > > Summary: the failing process reads 0 rows from 0 blocks from the OLD > > relfilenode. > > Hmm. This seems to mean that we're somehow missing a relation mapping > invalidation message, or perhaps not processing it soon

[HACKERS] Reduce WAL logging of INSERT SELECT

We currently have reduced WAL logging for wal_level = minimum for these commands: CREATE TABLE AS CREATE INDEX CLUSTER COPY into tables that were created or truncated in the same transaction One thing we don't optimize is INSERT ... SELECT when the table is

[HACKERS] PQescapeByteaConn - returns wrong string for PG9.1 Beta3

Normal021false falsefalseDEX-NONEX-NONE MicrosoftInternetExplorer4

[HACKERS] possible new feature: asynchronous sql or something like oracles dbms_job.submit

hi i switched back from oracle xe for many reasons and because the lack of pl/java in oralce xe. and posgesql is the best open source db i know! sadly what i realy miss is the possibility of asynchronous sql. which means the need to perform an sql in a completely different new session. something i

Re: [HACKERS] error: could not find pg_class tuple for index 2662

On Thu, Aug 04, 2011 at 12:28:31PM -0400, Tom Lane wrote: > daveg writes: > > Summary: the failing process reads 0 rows from 0 blocks from the OLD > > relfilenode. > > Hmm. This seems to mean that we're somehow missing a relation mapping > invalidation message, or perhaps not processing it soon

Re: [HACKERS] psql: bogus descriptions displayed by \d+

Peter Eisentraut wrote: > According to scientific-ish database literature, a table is a > relation and vice versa. I've generally understood the terms more like what is described near the top of this page: http://en.wikipedia.org/wiki/Relation_%28database%29 "In SQL, [...] a relation varia

Re: [HACKERS] Transient plans versus the SPI API

Peter Eisentraut writes: > How about a new function like SPI_parse that has the new semantics? Yeah, I'd considered that idea (and even exactly that name for it). Howver, the disadvantage of inventing a separate entry point is that it isn't going to be nice for multi-level call chains, of which t

Re: [HACKERS] psql: bogus descriptions displayed by \d+

On Thu, Aug 4, 2011 at 2:26 PM, Peter Eisentraut wrote: > On ons, 2011-07-27 at 17:57 -0400, Josh Kupershmidt wrote: >> > I think table_name is fine, and if you are very worried, add below >> that >> > a table_name also includes views (or whatever). >> >> It includes tables, views, composite types

Re: [HACKERS] psql: bogus descriptions displayed by \d+

On Thu, Aug 4, 2011 at 2:30 PM, Peter Eisentraut wrote: > On ons, 2011-07-27 at 18:08 -0400, Robert Haas wrote: >> Also, while it may be true that we haven't used the term specifically >> in SQL sypnoses, it's been extensively used in other parts of the >> documentation, in the names of system fun

Re: [HACKERS] psql: bogus descriptions displayed by \d+

On ons, 2011-07-27 at 18:08 -0400, Robert Haas wrote: > Also, while it may be true that we haven't used the term specifically > in SQL sypnoses, it's been extensively used in other parts of the > documentation, in the names of system functions such as > pg_relation_size(), Well, that thing is just

Re: [HACKERS] psql: bogus descriptions displayed by \d+

On ons, 2011-07-27 at 17:57 -0400, Josh Kupershmidt wrote: > > I think table_name is fine, and if you are very worried, add below > that > > a table_name also includes views (or whatever). > > It includes tables, views, composite types, and foreign tables. Is > "table" really an appropriate descri

Re: [HACKERS] Transient plans versus the SPI API

On tis, 2011-08-02 at 16:47 -0400, Tom Lane wrote: > The most straightforward way to reimplement things within spi.c would > be to redefine SPI_prepare as just doing the parse-and-rewrite steps, > with planning always postponed to SPI_execute. In the case where you > just prepare and then execute

Re: [HACKERS] patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c

On Thu, Aug 4, 2011 at 1:53 PM, Phil Sorber wrote: > Ok, here is the patch that just moves the ALTER/SET pieces to the end. > Can we get this included in the next commit fest? Yep, just make yourself an account and add it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] mosbench revisited

On Wed, Aug 3, 2011 at 9:16 PM, Robert Haas wrote: > Spinlocks seem to have a very ugly "tipping point". And on that note, here are oprofile results from "pgbench -n -T 300 -S -c 64 -j 64 -M prepared" on the latest master branch, compiled with "-O2 -fno-omit-frame-pointer". shared_buffers=8GB, 6

Re: [HACKERS] patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c

On Tue, Aug 2, 2011 at 5:05 PM, Tom Lane wrote: > Phil Sorber writes: >> I have included two patches in this email. The first >> (dump_user_config_last_with_set_role.patch) is an extension of my >> first patch. In addition to moving the ALTER ROLE statements after the >> CREATE ROLE statements it

Re: [HACKERS] TRUE/FALSE vs true/false

On tor, 2011-08-04 at 14:44 +0200, Boszormenyi Zoltan wrote: > 2011-08-04 14:32 keltezéssel, Robert Haas írta: > > 2011/8/4 Boszormenyi Zoltan : > >> Shouldn't these get fixed to be consistent? > > I believe I already did. See commit > > 85b436f7b1f06a6ffa8d2f29b03d6e440de18784. > > I meant a ma

Re: [HACKERS] cataloguing NOT NULL constraints

On tis, 2011-08-02 at 23:40 -0400, Alvaro Herrera wrote: > Thanks. I've done the other changes you suggested, but I don't see that > it's desirable to have gram.y emit AT_AddConstraint directly. It seems > cleaner to be able to turn a NOT NULL constraint into AT_SetNotNull > in parse_utilcmd inst

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

On Thu, 2011-08-04 at 10:28 -0400, Tom Lane wrote: > Hannu Krosing writes: > > On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote: > >> On 08/04/2011 09:07 AM, Hannu Krosing wrote: > >>> The crash is related to something leaving begind a bad SIGALARM handler, > > >> So doesn't this look like

Re: [HACKERS] lazy vxid locks, v3

On Thu, Aug 4, 2011 at 11:29 AM, Jeff Davis wrote: > On Mon, 2011-08-01 at 12:12 -0400, Robert Haas wrote: >> I guess you could look at that way.  It just seemed like the obvious >> way to write the code: we do LockRefindAndRelease() only if we have a >> fast-path lock that someone else has pushed

Re: [HACKERS] error: could not find pg_class tuple for index 2662

daveg writes: > Summary: the failing process reads 0 rows from 0 blocks from the OLD > relfilenode. Hmm. This seems to mean that we're somehow missing a relation mapping invalidation message, or perhaps not processing it soon enough during some complex set of invalidations. I did some testing

Re: [HACKERS] WAL logging volume and CREATE TABLE

Patch applied. --- Bruce Momjian wrote: > Alvaro Herrera wrote: > > Excerpts from Bruce Momjian's message of mar ago 02 22:46:55 -0400 2011: > > > > > I have created a documentation patch to clarify this, and to mention > >

Re: [HACKERS] lazy vxid locks, v3

On Mon, 2011-08-01 at 12:12 -0400, Robert Haas wrote: > I guess you could look at that way. It just seemed like the obvious > way to write the code: we do LockRefindAndRelease() only if we have a > fast-path lock that someone else has pushed into the main table. OK, looks good to me. Marked "read

Re: [HACKERS] Postgres / plpgsql equivalent to python's getattr() ?

On Wed, Aug 3, 2011 at 4:19 PM, James Robinson wrote: > Hackers, > > Python's getattr() allows for dynamic lookup of attributes on an object, as > in: > >        inst = MyClass(x=12, y=24) >        v = getattr(inst, 'x') >        assert v == 12 > > Oftentimes in writing data validating trigger fun

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

On 08/04/2011 10:28 AM, Tom Lane wrote: How can anything like that possibly work with any reliability whatsoever? If the signal comes in, you don't know whether it was triggered by the event Postgres expected, or the event the perl module expected, and hence there's no way to deliver it to the

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

On Aug 4, 2011, at 5:25 PM, Alvaro Herrera wrote: > Excerpts from Hannu Krosing's message of jue ago 04 09:53:40 -0400 2011: >> On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote: >>> >>> On 08/04/2011 09:07 AM, Hannu Krosing wrote: > I have been helping some people to debug a SIGALAR

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

On 08/04/2011 09:53 AM, Hannu Krosing wrote: What happens if you wrap the calls to the module like this?: { local $SIG{ALRM}; # do LWP stuff here } return 'OK'; That should restore the old handler on exit from the block. I think if you use a perl modu

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

Hannu Krosing writes: > On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote: >> On 08/04/2011 09:07 AM, Hannu Krosing wrote: >>> The crash is related to something leaving begind a bad SIGALARM handler, >> So doesn't this look like a bug in the perl module that sets the signal >> handler and

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

Excerpts from Hannu Krosing's message of jue ago 04 09:53:40 -0400 2011: > On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote: > > > > On 08/04/2011 09:07 AM, Hannu Krosing wrote: > > > I have been helping some people to debug a SIGALARM related crash > > > induced by using pl/perlu http get

Re: [HACKERS] cataloguing NOT NULL constraints

Excerpts from Nikhil Sontakke's message of jue ago 04 04:23:59 -0400 2011: > Some nit-picking. > > AFAICS above, we seem to be only using 'tbinfo' to identify the object > type here - 'table' visavis 'domain'. We could probably reduce the > above two elses to a single one and use the check of tbi

Re: [HACKERS] Postgres / plpgsql equivalent to python's getattr() ?

On Aug 4, 2011, at 4:55 AM, Florian Pflug wrote: @OP: Here's my implementation of the feature you desire as a set of C-language functions: https://github.com/fgp/pg_record_inspect. Other people did code up similar things in the past, but I currently cannot find any links to their w

Re: [HACKERS] Postgres / plpgsql equivalent to python's getattr() ?

On Wed, 2011-08-03 at 18:48 -0400, Tom Lane wrote: > James Robinson writes: > > Python's getattr() allows for dynamic lookup of attributes on an > > object, as in: > > > inst = MyClass(x=12, y=24) > > v = getattr(inst, 'x') > > assert v == 12 > > > Oftentimes in writing data valida

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

On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote: > > On 08/04/2011 09:07 AM, Hannu Krosing wrote: > > Hi > > > > I have been helping some people to debug a SIGALARM related crash > > induced by using pl/perlu http get functionality > > > > I have been so far able to repeat the crash only o

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

On Thu, 2011-08-04 at 15:07 +0200, Hannu Krosing wrote: > Hi > > I have been helping some people to debug a SIGALARM related crash > induced by using pl/perlu http get functionality > > I have been so far able to repeat the crash only on Debian 64 bit > computers. DB create script and instruction

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

On 08/04/2011 09:07 AM, Hannu Krosing wrote: Hi I have been helping some people to debug a SIGALARM related crash induced by using pl/perlu http get functionality I have been so far able to repeat the crash only on Debian 64 bit computers. DB create script and instructions for reproducing the

Re: [HACKERS] Compressing the AFTER TRIGGER queue

Robert Haas wrote: > On Wed, Aug 3, 2011 at 6:05 PM, Jim Nasby wrote: >> Not sure how much this relates to this discussion, but I have >> often wished we had AFTER FOR EACH STATEMENT triggers that >> provided OLD and NEW recordsets you could make use of. Sometimes >> it's very valuably to be able

Re: [HACKERS] TRUE/FALSE vs true/false

On 4 August 2011 13:57, Robert Haas wrote: > Oh, I see.  Well, I don't care either way, so I'll let others weigh > in.  The way it is doesn't bother me, but fixing it doesn't bother me > either. Idiomatic win32 code uses BOOL and TRUE/FALSE. They are macros defined somewhere or other. -- Peter

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

Hi I have been helping some people to debug a SIGALARM related crash induced by using pl/perlu http get functionality I have been so far able to repeat the crash only on Debian 64 bit computers. DB create script and instructions for reproducing the crash attached The crash is related to somethin

Re: [HACKERS] TRUE/FALSE vs true/false

On Thu, Aug 4, 2011 at 8:44 AM, Boszormenyi Zoltan wrote: > 2011-08-04 14:32 keltezéssel, Robert Haas írta: >> 2011/8/4 Boszormenyi Zoltan : >>> Shouldn't these get fixed to be consistent? >> I believe I already did.  See commit >> 85b436f7b1f06a6ffa8d2f29b03d6e440de18784. > > I meant a mass "sed

Re: [HACKERS] TRUE/FALSE vs true/false

2011-08-04 14:32 keltezéssel, Robert Haas írta: > 2011/8/4 Boszormenyi Zoltan : >> Shouldn't these get fixed to be consistent? > I believe I already did. See commit 85b436f7b1f06a6ffa8d2f29b03d6e440de18784. I meant a mass "sed -e 's/TRUE/true/g' -e 's/FALSE/false/g'" run so all the ~200 occurren

Re: [HACKERS] TRUE/FALSE vs true/false

2011/8/4 Boszormenyi Zoltan : > Shouldn't these get fixed to be consistent? I believe I already did. See commit 85b436f7b1f06a6ffa8d2f29b03d6e440de18784. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-ha

[HACKERS] TRUE/FALSE vs true/false

Hi, I looked at b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4 and I noticed that it's using TRUE, FALSE, true and false inconsistently: @@ -248,6 +249,7 @@ CreateSharedInvalidationState(void) shmInvalBuffer->procState[i].nextMsgNum = 0;/* meaningless */ shmInvalBuf

Re: [HACKERS] Postgres / plpgsql equivalent to python's getattr() ?

2011/8/4 Florian Pflug : > On Aug4, 2011, at 00:48 , Tom Lane wrote: >> James Robinson writes: >>> Python's getattr() allows for dynamic lookup of attributes on an >>> object, as in: >> >>>      inst = MyClass(x=12, y=24) >>>      v = getattr(inst, 'x') >>>      assert v == 12 >> >>> Oftentimes in

Re: [HACKERS] Transient plans versus the SPI API

On 2011-08-03 21:19, Tom Lane wrote: Robert Haas writes: This seems like a good design. Now what would be really cool is if you could observe a stream of queries like this: SELECT a, b FROM foo WHERE c = 123 SELECT a, b FROM foo WHERE c = 97 SELECT a, b FROM foo WHERE c = 236 ...and say, hey,

Re: [HACKERS] SYNONYMS (again)

2011-06-23 20:44 keltezéssel, Gurjeet Singh írta: > On Wed, Jun 22, 2011 at 3:37 PM, Joshua D. Drake > wrote: > > Per: > > http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php > > It seems we did come up with a use case in the procpid discuss

Re: [HACKERS] error: could not find pg_class tuple for index 2662

On Wed, Aug 03, 2011 at 11:18:20AM -0400, Tom Lane wrote: > Evidently not, if it's not logging anything, but now the question is > why. One possibility is that for some reason RelationGetNumberOfBlocks > is persistently lying about the file size. (We've seen kernel bugs > before that resulted in

Re: [HACKERS] cataloguing NOT NULL constraints

On 4 August 2011 09:23, Nikhil Sontakke wrote: >> So after writing the code to handle named NOT NULL constraints for >> tables, I'm thinking that dumpConstraints needs to be fixed thusly: >> >> @@ -12888,6 +12968,27 @@ dumpConstraint(Archive *fout, ConstraintInfo >> *coninfo) >>                  

Re: [HACKERS] Postgres / plpgsql equivalent to python's getattr() ?

On Aug4, 2011, at 00:48 , Tom Lane wrote: > James Robinson writes: >> Python's getattr() allows for dynamic lookup of attributes on an >> object, as in: > >> inst = MyClass(x=12, y=24) >> v = getattr(inst, 'x') >> assert v == 12 > >> Oftentimes in writing data validating trigger

Re: [HACKERS] WIP: Fast GiST index build

Uhh, my bad, really stupid bug. Many thanks. -- With best regards, Alexander Korotkov. On Wed, Aug 3, 2011 at 8:31 PM, Heikki Linnakangas < heikki.linnakan...@enterprisedb.com> wrote: > On 03.08.2011 11:18, Alexander Korotkov wrote: > >> I found that in previous version of patch I missed Pag

Re: [HACKERS] Further news on Clang - spurious warnings

On 4 August 2011 07:08, Tom Lane wrote: > Peter Geoghegan writes: >> On 3 August 2011 21:03, Tom Lane wrote: >>> I mean that it's unclear what you'll get if status has a bitpattern >>> equivalent to a negative integer.  If the compiler implements the >>> comparison as signed, the test will yield

Re: [HACKERS] cataloguing NOT NULL constraints

> So after writing the code to handle named NOT NULL constraints for > tables, I'm thinking that dumpConstraints needs to be fixed thusly: > > @@ -12888,6 +12968,27 @@ dumpConstraint(Archive *fout, ConstraintInfo > *coninfo) >                         NULL, NULL); >        } >    } > +   else if (c

Re: [HACKERS] cataloguing NOT NULL constraints

On 3 August 2011 22:26, Alvaro Herrera wrote: > Excerpts from Dean Rasheed's message of sáb jul 23 04:37:06 -0400 2011: >> On 22 July 2011 22:28, Robert Haas wrote: > >> >> mine was that we need a command such as >> >> >> >> ALTER TABLE foo ALTER COLUMN bar SET NOT NULL name_of_notnull_constr >>