Re: [HACKERS] JSON for PG 9.2

On Tue, Dec 13, 2011 at 1:13 PM, Merlin Moncure wrote: > Mozilla SpiderMonkey seems like a good fit: it compiles to a > dependency free .so, has excellent platform support, has a stable C > API, and while it's C++ internally makes no use of exceptions (in > fact, it turns them off in the c++ compi

Re: [HACKERS] review: CHECK FUNCTION statement

Pavel Stehule wrote: > so removed "quite" option > and removed multiple check regression tests also - there is missing > explicit order of function checking, so regress tests can fail :( There seems to be a problem with the SET clause of CREATE FUNCTION: ftest=# CREATE OR REPLACE FUNCTION a(integ

Re: [HACKERS] review: CHECK FUNCTION statement

Hello 2011/12/15 Albe Laurenz : > Pavel Stehule wrote: >> so removed "quite" option >> and removed multiple check regression tests also - there is missing >> explicit order of function checking, so regress tests can fail :( > > There seems to be a problem with the SET clause of CREATE FUNCTION: >

Re: [HACKERS] includeifexists in configuration file

On 12/12/2011 04:47 PM, Andrew Dunstan wrote: I have briefly looked at the code (but not tried to apply or build it), and modulo the naming issue it looks OK to me. Unless there is some other issue let's just get it applied. It looks like almost a no-brainer to me. It isn't very fancy, but is

Re: [HACKERS] IDLE in transaction introspection

This patch seems closing in on being done, but it's surely going to take at least one more round of review to make sure all the naming and documentation is up right. I can work on that again whenever Scott gets another version necessary, and Magnus is already poking around with an eye toward p

Re: [HACKERS] Measuring relation free space

On 11/28/2011 05:40 AM, Greg Smith wrote: Ignoring fillfactor seems to have even more downsides as I see it. Certainly deserves a doc improvement, as well as fixing the description of the value so it's clearly a ratio rather than a true percentage. So: I'm very clear on what to do here now:

Re: [HACKERS] patch : Allow toast tables to be moved to a different tablespace

On 12/13/2011 12:29 PM, Julien Tachoires wrote: 2011/12/13 Robert Haas: On Tue, Dec 13, 2011 at 12:02 PM, Julien Tachoires wrote: Right, it seems to happen when the destination tablespace is the same as the database's tbs, because, in this case, relation's tbs is set to InvalidOid :

Re: [HACKERS] review: CHECK FUNCTION statement

Hello one small update - better emulation of environment for security definer functions Regards Pavel check_function-2011-12-15-2.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://ww

Re: [HACKERS] Race condition in HEAD, possibly due to PGPROC splitup

On Wed, Dec 14, 2011 at 3:20 PM, Tom Lane wrote: > Pavan Deolasee writes: >> Looking at CommitTransaction(), it seems quite clear to me that we >> call ProcArrayEndTransaction() before releasing the locks held by the >> transaction. So its quite possible that when >> GetRunningTransactionLocks go

[HACKERS] why do we need create tuplestore for each fetch?

Hi everyone, I found this several days ago when I try to debug a "fetch" of cursor. And I have sent a mail to this list, but no one reply... Maybe this is a very simple problem, please help me, thanks a lot... Here is the example: create table t (a int); insert into t values (1),(3),(5),(

Re: [HACKERS] patch : Allow toast tables to be moved to a different tablespace

Excerpts from Julien Tachoires's message of mar dic 13 14:29:56 -0300 2011: > 2011/12/13 Robert Haas : > > On Tue, Dec 13, 2011 at 12:02 PM, Julien Tachoires wrote: > >> Right, it seems to happen when the destination tablespace is the same > >> as the database's tbs, because, in this case, relati

[HACKERS] Moving more work outside WALInsertLock

I've been looking at various ways to make WALInsertLock less of a bottleneck on multi-CPU servers. The key is going to be to separate the two things that are done while holding the WALInsertLock: a) allocating the required space in the WAL, and b) calculating the CRC of the record header and co

Re: [HACKERS] Race condition in HEAD, possibly due to PGPROC splitup

On Thu, Dec 15, 2011 at 8:19 AM, Simon Riggs wrote: > Comments? I think there is a small bug here: + TransactionId xid = pgxact->xid; + + /* +* Don't record locks for transactions if we know they have already +

Re: [HACKERS] Moving more work outside WALInsertLock

On Thursday, December 15, 2011 02:51:33 PM Heikki Linnakangas wrote: > I've been looking at various ways to make WALInsertLock less of a > bottleneck on multi-CPU servers. The key is going to be to separate the > two things that are done while holding the WALInsertLock: a) allocating > the required

Re: [HACKERS] Command Triggers

On Wed, Dec 14, 2011 at 5:44 PM, Dimitri Fontaine wrote: > Robert Haas writes: >>> I can get behind this argument: force all stuff through ProcessUtility >>> for regularity, and not necessarily in the first patch for this feature. >> >> That seems like a pretty heavy dependency on an implementati

Re: [HACKERS] unite recovery.conf and postgresql.conf

On Wed, Dec 14, 2011 at 8:56 PM, Josh Berkus wrote: > So for streaming replication, will I need to have a standby.enabled > file, or will there be a parameter in postgresql.conf (or included > files) which controls whether or not that server is a standby, available? > > In the best of all possible

Re: [HACKERS] Race condition in HEAD, possibly due to PGPROC splitup

On Thu, Dec 15, 2011 at 2:13 PM, Robert Haas wrote: > On Thu, Dec 15, 2011 at 8:19 AM, Simon Riggs wrote: >> Comments? > > I think there is a small bug here: > > +                       TransactionId xid = pgxact->xid; > + > +                       /* > +                        * Don't record loc

Re: [HACKERS] Command Triggers

On Thursday, December 15, 2011 03:36:25 PM Robert Haas wrote: > On Wed, Dec 14, 2011 at 5:44 PM, Dimitri Fontaine > > wrote: > > Robert Haas writes: > >>> I can get behind this argument: force all stuff through ProcessUtility > >>> for regularity, and not necessarily in the first patch for this

Re: [HACKERS] splitting plpython into smaller parts

How to people feel about naming the files (as proposed) ! OBJS = plpython.o plpython_io.o plpython_procedure.o plpython_exec.o \ !plpython_plpy.o plpython_spi.o plpython_result.o plpython_cursor.o \ !plpython_plan.o plpython_subtransaction.o plpython_functions.o \ !plpython

Re: [HACKERS] splitting plpython into smaller parts

Excerpts from Peter Eisentraut's message of jue dic 15 12:00:13 -0300 2011: > How to people feel about naming the files (as proposed) > > ! OBJS = plpython.o plpython_io.o plpython_procedure.o plpython_exec.o \ > !plpython_plpy.o plpython_spi.o plpython_result.o plpython_cursor.o \ > !

Re: [HACKERS] splitting plpython into smaller parts

Alvaro Herrera writes: > Excerpts from Peter Eisentraut's message of jue dic 15 12:00:13 -0300 2011: >> How to people feel about naming the files (as proposed) >> >> ! OBJS = plpython.o plpython_io.o plpython_procedure.o plpython_exec.o \ >> !plpython_plpy.o plpython_spi.o plpython_result

Re: [HACKERS] Moving more work outside WALInsertLock

Heikki Linnakangas writes: > I've been experimenting with different approaches to do that, but one > thing is common among all of them: you need to know the total amount of > WAL space needed for the record, including backup blocks, before you > take the lock. So, here's a patch to move things

Re: [HACKERS] Command Triggers

Hi, Thank your Robert for this continued review, I think we're making good progress in a community discussion that needs to happen! Robert Haas writes: >> Given ProcessUtility_hook, how much of an implementation detail rather >> than a public API are we talking about? > > I think that a hook and

Re: [HACKERS] Command Triggers

On Thursday, December 15, 2011 04:53:15 PM Dimitri Fontaine wrote: > Hi, > > Thank your Robert for this continued review, I think we're making good > progress in a community discussion that needs to happen! > > Robert Haas writes: > >> Given ProcessUtility_hook, how much of an implementation det

Re: [HACKERS] Moving more work outside WALInsertLock

On Thu, Dec 15, 2011 at 7:34 AM, Tom Lane wrote: > Heikki Linnakangas writes: >> I've been experimenting with different approaches to do that, but one >> thing is common among all of them: you need to know the total amount of >> WAL space needed for the record, including backup blocks, before you

Re: [HACKERS] Command Triggers

Andres Freund writes: >> create trigger foo after command CREATE TABLE … >> create trigger foo after top level command CREATE TABLE … >> create trigger foo after nested command CREATE TABLE … >> >> Either we add support for that kind of syntax now (and not implementing >> it in 9.3 would se

Re: [HACKERS] Moving more work outside WALInsertLock

Jeff Janes writes: > On Thu, Dec 15, 2011 at 7:34 AM, Tom Lane wrote: >> This patch may or may not be useful, but this description of it is utter >> nonsense, because we already do compute that before taking the lock. >> Please try again to explain what you're doing? > Currently the CRC of all t

[HACKERS] pgstat wait timeout

Hi, I am having a scenario where I get consistent warnings in the pglog folder: 2011-12-11 00:00:03 JST WARNING: pgstat wait timeout 2011-12-11 00:00:14 JST WARNING: pgstat wait timeout 2011-12-11 00:00:24 JST WARNING: pgstat wait timeout 2011-12-11 00:00:31 JST WARNING: pgstat wait timeout 2

Re: [HACKERS] IDLE in transaction introspection

On Thu, Dec 15, 2011 at 13:18, Greg Smith wrote: > This patch seems closing in on being done, but it's surely going to take at > least one more round of review to make sure all the naming and documentation > is up right.  I can work on that again whenever Scott gets another version > necessary, an

Re: [HACKERS] pgstat wait timeout

On 15 Prosinec 2011, 17:55, pratikchirania wrote: > Hi, > > I am having a scenario where I get consistent warnings in the pglog > folder: > > 2011-12-11 00:00:03 JST WARNING: pgstat wait timeout > 2011-12-11 00:00:14 JST WARNING: pgstat wait timeout > 2011-12-11 00:00:24 JST WARNING: pgstat wait

Re: [HACKERS] pgstat wait timeout

On Thu, Dec 15, 2011 at 18:13, Tomas Vondra wrote: > On 15 Prosinec 2011, 17:55, pratikchirania wrote: >> Hi, >> >> I am having a scenario where I get consistent warnings in the pglog >> folder: >> >> 2011-12-11 00:00:03 JST WARNING:  pgstat wait timeout >> 2011-12-11 00:00:14 JST WARNING:  pgstat

Re: [HACKERS] pgstat wait timeout

On 15 Prosinec 2011, 18:19, Magnus Hagander wrote: > On Thu, Dec 15, 2011 at 18:13, Tomas Vondra wrote: >> On 15 Prosinec 2011, 17:55, pratikchirania wrote: >>> Hi, >>> >>> I am having a scenario where I get consistent warnings in the pglog >>> folder: >>> >>> 2011-12-11 00:00:03 JST WARNING:  pgs

Re: [HACKERS] JSON for PG 9.2

On Tue, Dec 13, 2011 at 8:15 AM, Joey Adams wrote: > Issues we've encountered include: > >  * Should JSON be stored as binary or as text? Text >  * How do we deal with Unicode escapes and characters if the server or > client encoding is not UTF-8?  Some (common!) character encodings have > code

Re: [HACKERS] pgstat wait timeout

Size of pgstat.stat file: 86KB I did not understand the second part. Where do I get "iostat -x 1" message? (Its not present in any file in the pg_log folder) I am using postgres 9.0.1 -- View this message in context: http://postgresql.1045698.n5.nabble.com/pgstat-wait-timeout-tp5078125p5078391

Re: [HACKERS] Moving more work outside WALInsertLock

On 15.12.2011 18:48, Tom Lane wrote: Jeff Janes writes: On Thu, Dec 15, 2011 at 7:34 AM, Tom Lane wrote: This patch may or may not be useful, but this description of it is utter nonsense, because we already do compute that before taking the lock. Please try again to explain what you're doing?

Re: [HACKERS] pgstat wait timeout

On 15 Prosinec 2011, 19:42, pratikchirania wrote: > Size of pgstat.stat file: 86KB That's pretty small. > I did not understand the second part. Where do I get "iostat -x 1" > message? > (Its not present in any file in the pg_log folder) iostat is not part of PostgreSQL, it's a tool used to displ

Re: [HACKERS] Moving more work outside WALInsertLock

On 15.12.2011 17:34, Tom Lane wrote: Heikki Linnakangas writes: I've been experimenting with different approaches to do that, but one thing is common among all of them: you need to know the total amount of WAL space needed for the record, including backup blocks, before you take the lock. So, h

Re: [HACKERS] CommitFest 2011-11 Update

On Sat, Dec 10, 2011 at 1:07 PM, Greg Smith wrote: > There's a normal sized plate lined up for Robert since he's been keeping up > better; in no particular order: > > -More review on the always a new surprise "Fix Leaky Views Problem, again" > -Extra fun with "Tuplesort comparison overhead reducti

Re: [HACKERS] IDLE in transaction introspection

On Thu, Dec 15, 2011 at 12:10 PM, Magnus Hagander wrote: > On Thu, Dec 15, 2011 at 13:18, Greg Smith wrote: > > This patch seems closing in on being done, but it's surely going to take > at > > least one more round of review to make sure all the naming and > documentation > > is up right. I can

Re: [HACKERS] Command Triggers

On Thu, Dec 15, 2011 at 05:46:05PM +0100, Dimitri Fontaine wrote: > Andres Freund writes: > >> Yes, we need to make a decision about that now. Do we want any > >> ???operation??? to go through ProcessUtility so that hooks and command > >> triggers can get called? > > I personally think thats a goo

Re: [HACKERS] Command Triggers

On Thu, Dec 15, 2011 at 10:53 AM, Dimitri Fontaine wrote: > Yes, we need to make a decision about that now. Do we want any > “operation” to go through ProcessUtility so that hooks and command > triggers can get called? No. That's 100% backwards. We should first decide what functionality we want

Re: [HACKERS] Command Triggers

Robert Haas writes: > No. That's 100% backwards. We should first decide what functionality > we want, and then decide how we're going to implement it. If we > arbitrarily decide to force everything that someone might want to > write a trigger on through ProcessUtility_hook, then we're going to

Re: [HACKERS] Measuring relation free space

On Sun, Nov 06, 2011 at 10:20:49PM +0100, Bernd Helmle wrote: > --On 6. November 2011 01:08:11 -0200 Greg Smith wrote: > >> Attached patch adds a new function to the pageinspect extension for measuring >> total free space, in either tables or indexes. > > I wonder if that should be done in the pgs

Re: [HACKERS] JSON for PG 9.2

On 12/15/2011 01:34 PM, Simon Riggs wrote: On Tue, Dec 13, 2011 at 8:15 AM, Joey Adams wrote: Issues we've encountered include: * Should JSON be stored as binary or as text? Text Works for me. * How do we deal with Unicode escapes and characters if the server or client encoding is

Re: [HACKERS] Moving more work outside WALInsertLock

On Thu, Dec 15, 2011 at 7:06 PM, Heikki Linnakangas wrote: >> Please try again to explain what you're doing? > > > Ok: I'm moving the creation of rdata entries for backup blocks outside the > critical section, so that it's done before grabbing the lock. I'm also > moving the CRC calculation so th

Re: [HACKERS] Moving more work outside WALInsertLock

On Thu, Dec 15, 2011 at 6:50 PM, Heikki Linnakangas wrote: >> unless you are proposing to remove >> the prev_link from the scope of the CRC, which is not exactly a >> penalty-free change. > > > We could CRC the rest of the record header before getting the lock, though, > and only include the prev

Re: [HACKERS] RangeVarGetRelid()

On Fri, Dec 9, 2011 at 5:41 PM, Noah Misch wrote: > It also seems my last explanation didn't convey the point.  Yes, nearly every > command has a different set of permissions checks.  However, we don't benefit > equally from performing each of those checks before acquiring a lock. > Consider renam

Re: [HACKERS] Patch to allow users to kill their own queries

On Tue, Dec 13, 2011 at 5:59 AM, Greg Smith wrote: > Same-user cancels, but not termination.  Only this, and nothing more. +1 from me on this approach. I think enough people have clamored for this simple approach which solves the common-case. > There's one obvious and questionable design decisio

Re: [HACKERS] includeifexists in configuration file

On 12/15/2011 06:54 AM, Greg Smith wrote: On 12/12/2011 04:47 PM, Andrew Dunstan wrote: I have briefly looked at the code (but not tried to apply or build it), and modulo the naming issue it looks OK to me. Unless there is some other issue let's just get it applied. It looks like almost a no-

Re: [HACKERS] Moving more work outside WALInsertLock

Simon Riggs writes: > You missed your cue to discuss leaving the prev link out of the CRC > altogether. > On its own that sounds dangerous, but its not. When we need to confirm > the prev link we already know what we expect it to be, so CRC-ing it > is overkill. That isn't true of any other part

Re: [HACKERS] Storing hot members of PGPROC out of the band

On Mon, Nov 7, 2011 at 7:28 AM, Robert Haas wrote: > On Mon, Nov 7, 2011 at 6:45 AM, Heikki Linnakangas > wrote: >> While looking at GetSnapshotData(), it occurred to me that when a PGPROC >> entry does not have its xid set, ie. xid == InvalidTransactionId, it's >> pointless to check the subxid a

Re: [HACKERS] includeifexists in configuration file

On 12/15/2011 08:16 PM, Andrew Dunstan wrote: I changed the elog() call to use ereport(): you're not supposed to use elog() for things we expect might well happen and cause log entries - see bottom of . I've probably

Re: [HACKERS] Patch to allow users to kill their own queries

On 12/15/2011 07:36 PM, Josh Kupershmidt wrote: The only niggling concern I have about this patch (and, I think, all similar ones proposed) is the possible race condition between the permissions checking and the actual call of kill() inside pg_signal_backend(). This is a problem with the existi

Re: [HACKERS] Measuring relation free space

On 12/15/2011 04:11 PM, Noah Misch wrote: Is one of those index figures simply wrong, or do they measure two senses of free space, both of which are interesting to DBAs? I think the bigger one--the one I was aiming to measure--also includes fill-factor space. It should be possible to isol

Re: [HACKERS] [PATCH] Caching for stable expressions with constant arguments v3

I think what would be helpful here next is a self-contained benchmarking script. You posted an outline of what you did for the original version at http://archives.postgresql.org/message-id/cabrt9rc-1wgxzc_z5mwkdk70fgy2drx3slxzdp4vobkukpz...@mail.gmail.com It doesn't sound like it would be har