Re: [HACKERS] Archive recovery won't be completed on some situation.

Hello, thank you for the discussion. At Tue, 1 Apr 2014 11:41:20 -0400, Robert Haas wrote >> I don't find that very radical at all. The backup_label file is >> *supposed* to be removed on the master if it crashes during the >> backup; and it should never be removed from the backup itself. At >>

Re: [HACKERS] Autonomous Transaction (WIP)

On 14 April 2014 20:10, Simon Riggs wrote: >>Autonomous Transaction Storage: >>As for main transaction, structure PGXACT is used to store main transactions, >>which are created in shared memory of size: >> (Number of process)*sizeof(struct PGXACT) >>Similarly a new structure will be def

Re: [HACKERS] Minor improvements in alter_table.sgml

(2014/04/14 23:53), Robert Haas wrote: On Fri, Apr 11, 2014 at 5:00 AM, Etsuro Fujita wrote: Attached is an updated version of the patch. I applied the first two hunks of this, which seem like clear oversights; and also the bit fixing the constraint_name language. I think the other changes d

Re: [HACKERS] integrate pg_upgrade analyze_new_cluster.sh into vacuumdb

Committed, with your suggestions. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On 4/14/14, 7:43 PM, Stephen Frost wrote: * Jim Nasby (j...@nasby.net) wrote: I think it's important to mention that OS implementations (at least all I know of) have multiple page pools, each of which has it's own clock. IIRC one of the arguments for us supporting a count>1 was we could get th

Re: [HACKERS] Dynamic Shared Memory stuff

On Mon, Apr 14, 2014 at 10:03 PM, Robert Haas wrote: > On Sat, Apr 12, 2014 at 1:32 AM, Amit Kapila wrote: >> I have checked that other place in code also check handle to >> decide if API has failed. Refer function PGSharedMemoryIsInUse(). >> So I think fix to call GetLastError() after checking

Re: [HACKERS] PostgreSQL in Windows console and Ctrl-C

On Tue, Apr 15, 2014 at 4:21 AM, Bruce Momjian wrote: > On Mon, Apr 14, 2014 at 09:34:14AM +0530, Amit Kapila wrote: >> The problem can be solved this way, but the only question here is whether >> it is acceptable for users to have a new console window for server. >> >> Can others also please shar

Re: [HACKERS] PostgreSQL in Windows console and Ctrl-C

On Mon, Apr 14, 2014 at 11:46 AM, Christian Ullrich wrote: > * From: Amit Kapila >> Do you mean to say use some existing environment variable? >> Introducing an environment variable to solve this issue or infact using >> some existing environ variable doesn't seem to be the best way to pass >> suc

Re: [HACKERS] [COMMITTERS] pgsql: Add TAP tests for client programs

On 04/14/2014 10:30 PM, Andrew Dunstan wrote: On 04/14/2014 10:17 PM, Tom Lane wrote: Peter Eisentraut writes: Add TAP tests for client programs I assume the buildfarm would need to be taught about this? Yes. It probably won't be a huge change, but it will need a bit of code. And

[HACKERS] Fwd: [BUGS] Debug strategy for musl Postgres?

On Mon, Apr 14, 2014 at 2:06 PM, Stefan Kaltenbrunner < ste...@kaltenbrunner.cc> wrote: > On 04/13/2014 10:19 PM, John Mudd wrote: > > > > On Sun, Apr 13, 2014 at 12:04 PM, Euler Taveira > > wrote: > > > > On 13-04-2014 00:40, John Mudd wrote: > > > I built Po

Re: [HACKERS] [COMMITTERS] pgsql: Add TAP tests for client programs

On 04/14/2014 10:17 PM, Tom Lane wrote: Peter Eisentraut writes: Add TAP tests for client programs I assume the buildfarm would need to be taught about this? Yes. It probably won't be a huge change, but it will need a bit of code. cheers andrew -- Sent via pgs

Re: [HACKERS] JSONB in-place updates?

On Tue, Apr 15, 2014 at 5:16 AM, Josh Berkus wrote: > On 04/14/2014 09:27 AM, kelas wrote: >> Are there any plans to add "in-place at-depth" update operator for JSONB >> type, e.g.: >> >> UPDATE test SET attrs->'anwser' = 42 where attrs->'answer' = 41 >> > > Plans, yes. But not until 9.5, or mayb

Re: [HACKERS] assertion failure 9.3.4

On 04/14/2014 10:02 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: and here the stack trace: #0 0x00361ba36285 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00361ba37b9b in __GI_abort () at abort.c:91 #2 0x0075c157 in ExceptionalC

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I've uploaded the latest patch, rebased against master, with my changes > > to here: http://snowman.net/~sfrost/rls_ringerc_sf.patch.gz as I don't > > believe it'd clear the mailing list (it's 29k). > > Please actually post it, fo

Re: [HACKERS] [COMMITTERS] pgsql: Add TAP tests for client programs

Peter Eisentraut writes: > Add TAP tests for client programs I assume the buildfarm would need to be taught about this? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.o

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

Stephen Frost writes: > I've uploaded the latest patch, rebased against master, with my changes > to here: http://snowman.net/~sfrost/rls_ringerc_sf.patch.gz as I don't > believe it'd clear the mailing list (it's 29k). Please actually post it, for the archives' sake. 29k is far below the list li

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Mon, Apr 14, 2014 at 05:45:56PM -0700, Peter Geoghegan wrote: > On Mon, Apr 14, 2014 at 5:30 PM, Bruce Momjian wrote: > > I am glad you are looking at this. You are right that it requires a > > huge amount of testing, but clearly our code needs improvement in this > > area. > > Thanks. > > D

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

Craig, Tom, all, I've been through the RLS code over the past couple of days which I pulled from Craig's repo and have a bunch of minor updates. In general, the patch seems pretty reasonable- except for the issues discussed below. Quite a bit of this patch is tied up in plan invalidation and tra

Re: [HACKERS] assertion failure 9.3.4

Andrew Dunstan wrote: > and here the stack trace: > >#0 0x00361ba36285 in __GI_raise (sig=6) at >../nptl/sysdeps/unix/sysv/linux/raise.c:64 >#1 0x00361ba37b9b in __GI_abort () at abort.c:91 >#2 0x0075c157 in ExceptionalCondition >(conditionName=, errorType=,

Re: [HACKERS] tests for client programs

On 4/4/14, 10:44 AM, Andres Freund wrote: > I personally would very much like to get this patch commited. It doesn't > have much risk in destabilizing stuff, rather the contrary. > > Peter, what's you opinion about the current state? I opine it's committed. ;-) -- Sent via pgsql-hackers mailin

Re: [HACKERS] PostgreSQL hang on FreeBSD,with CFLAGS='-O2 -pthread' workaround

Jov writes: > I find some problems when use pg on FreeBSD.On FreeBSD,If installed > extension which pthread lib is used,for example plv8,pljava,imcs etc,when > query touch these extenstions,the PG backend will hang. > there is a solution,which configure postgresql with CFLAGS='-O2 -pthread' > an

Re: [HACKERS] assertion failure 9.3.4

On 04/14/2014 09:28 PM, Andrew Dunstan wrote: With a client's code I have just managed to produce the following assertion failure on 9.3.4: 2014-04-15 01:02:46 GMT [19854] 76299: LOG: execute : select * from "asp_ins_event_task_log"( job_id:=1, event_id:=3164, task_name:='EventUtcC

Re: [HACKERS] [GENERAL] CLOB & BLOB limitations in PostgreSQL

Bruce Momjian writes: > Uh, I had not thought of this before but I think we need oids for toast > storage, which would explain this wiki text: > https://wiki.postgresql.org/wiki/BinaryFilesInDB > Storing binary data using bytea or text data types > Minus >

Re: [HACKERS] [GENERAL] CLOB & BLOB limitations in PostgreSQL

Bruce Momjian wrote > On Mon, Apr 14, 2014 at 02:01:19PM +0200, Ivan Voras wrote: >> On 11/04/2014 16:45, Jack.O' > Sullivan@ > wrote: >> >> > With point two, does this mean that any table with a bytea datatype is >> > limited to 4 billion rows (which would seem in conflict with the >> > "unlim

[HACKERS] assertion failure 9.3.4

With a client's code I have just managed to produce the following assertion failure on 9.3.4: 2014-04-15 01:02:46 GMT [19854] 76299: LOG: execute : select * from "asp_ins_event_task_log"( job_id:=1, event_id:=3164, task_name:='EventUtcComputeTask', task_status_code:='VALID' , task

Re: [HACKERS] Excessive WAL generation and related performance issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/14/2014 05:40 PM, Stephen Frost wrote: > This sounds like a great example of the unlogged table -> logged > table use-case and makes me wonder if we could provide an > optimization similar to the existing CREATE TABLE + COPY under > wal_level = m

[HACKERS] PostgreSQL hang on FreeBSD,with CFLAGS='-O2 -pthread' workaround

hi~ pg hackers, I find some problems when use pg on FreeBSD.On FreeBSD,If installed extension which pthread lib is used,for example plv8,pljava,imcs etc,when query touch these extenstions,the PG backend will hang. there is a solution,which configure postgresql with CFLAGS='-O2 -pthread' and compi

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

> Simon Riggs writes: > > [ assorted comments about custom-scan patch, but particularly ] > > > * The prune hook makes me feel very uneasy. It seems weirdly specific > > implementation detail, made stranger by the otherwise lack of data > > maintenance API calls. Calling that for every dirty page

Re: [HACKERS] [GENERAL] CLOB & BLOB limitations in PostgreSQL

On Mon, Apr 14, 2014 at 02:01:19PM +0200, Ivan Voras wrote: > On 11/04/2014 16:45, Jack.O'sulli...@tessella.com wrote: > > > With point two, does this mean that any table with a bytea datatype is > > limited to 4 billion rows (which would seem in conflict with the > > "unlimited rows" shown by htt

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Mon, Apr 14, 2014 at 5:30 PM, Bruce Momjian wrote: > I am glad you are looking at this. You are right that it requires a > huge amount of testing, but clearly our code needs improvement in this > area. Thanks. Does anyone recall the original justification for the recommendation that shared_b

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

* Jim Nasby (j...@nasby.net) wrote: > I think it's important to mention that OS implementations (at least all I > know of) have multiple page pools, each of which has it's own clock. IIRC one > of the arguments for us supporting a count>1 was we could get the benefits of > multiple page pools wi

Re: [HACKERS] Excessive WAL generation and related performance issue

* Joe Conway (m...@joeconway.com) wrote: > That's the thing. I'm sure there is tuning and other things to improve > this particular case, but creating over 20 times as much WAL as real > data seems like pathological behavior to me. Setting things up such that you are updating a single value on eac

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Mon, Apr 14, 2014 at 10:11:53AM -0700, Peter Geoghegan wrote: > Has anyone thought about this in the last few years? I know that Tom > examined the LRU-K paper back in 2000 [5], but was discouraged by some > kind of contention or CPU overhead (although he did say he intended to > revisit the que

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

> On 24 March 2014 10:25, Kouhei Kaigai wrote: > > > Brief summary of the current approach that has been revised from my > > original submission through the discussion on pgsql-hackers: > > > > The plannode was renamed to CustomPlan, instead of CustomScan, because > > it dropped all the hardcoded

Re: [HACKERS] Excessive WAL generation and related performance issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/14/2014 04:25 PM, Andres Freund wrote: > On 2014-04-14 16:22:48 -0700, Joe Conway wrote: >> That'll help performance, but lets say I generally keep WAL files >> for PITR and don't turn that off before starting -- shouldn't I >> be very surprised

Re: [HACKERS] Excessive WAL generation and related performance issue

On 2014-04-14 16:22:48 -0700, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/14/2014 04:17 PM, Tom Lane wrote: > > Andres Freund writes: > >> On 2014-04-14 14:33:03 -0700, Joe Conway wrote: > >>> checkpoint_segments = 96 checkpoint_timeout = 10min > > > >> I bet yo

Re: [HACKERS] Excessive WAL generation and related performance issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/14/2014 04:17 PM, Tom Lane wrote: > Andres Freund writes: >> On 2014-04-14 14:33:03 -0700, Joe Conway wrote: >>> checkpoint_segments = 96 checkpoint_timeout = 10min > >> I bet you'll see noticeably - while still not great - better >> performanc

Re: [HACKERS] Excessive WAL generation and related performance issue

Andres Freund writes: > On 2014-04-14 14:33:03 -0700, Joe Conway wrote: >> checkpoint_segments = 96 >> checkpoint_timeout = 10min > I bet you'll see noticeably - while still not great - better performance > by setting checkpoint_timeout to an hour (with a corresponding increase > in checkpoint_se

Re: [HACKERS] Including replication slot data in base backups

On Tue, Apr 15, 2014 at 1:55 AM, Robert Haas wrote: > On Mon, Apr 14, 2014 at 9:26 AM, Fujii Masao wrote: >> This makes me think that it's safer to just remove replication slot files >> at the beginning of the recovery when both backup_label and recovery.conf >> exist. > > Well, we could do that,

Re: [HACKERS] Excessive WAL generation and related performance issue

On 4/14/14, 5:51 PM, Joe Conway wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/14/2014 03:17 PM, Jim Nasby wrote: On 4/14/14, 4:50 PM, Andres Freund wrote: On 2014-04-14 14:33:03 -0700, Joe Conway wrote: I realize there are many things that can be done to improve my specific scena

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On 4/14/14, 12:11 PM, Peter Geoghegan wrote: I have some theories about the PostgreSQL buffer manager/clock sweep. To motivate the reader to get through the material presented here, I present up-front a benchmark of a proof-of-concept patch of mine: http://postgres-benchmarks.s3-website-us-east-

Re: [HACKERS] Excessive WAL generation and related performance issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/14/2014 03:17 PM, Jim Nasby wrote: > On 4/14/14, 4:50 PM, Andres Freund wrote: >> On 2014-04-14 14:33:03 -0700, Joe Conway wrote: >>> I realize there are many things that can be done to improve my >>> specific scenario, e.g. drop indexes before

Re: [HACKERS] PostgreSQL in Windows console and Ctrl-C

On Mon, Apr 14, 2014 at 09:34:14AM +0530, Amit Kapila wrote: > The problem can be solved this way, but the only question here is whether > it is acceptable for users to have a new console window for server. > > Can others also please share their opinion if this fix (start server in new > console)

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On 4/14/14, 12:44 PM, Tom Lane wrote: Andres Freund writes: >On 2014-04-14 13:06:21 -0400, Tom Lane wrote: >>In particular I'm not sold on the use-case >>for being able to tell that a process is waiting without being able to >>tell what it's waiting for. I can figure that much out already.

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On 4/14/14, 12:06 PM, Tom Lane wrote: One concrete reason not to do the proposed trivial hack is that the lock readout views are asynchronous. Right now, if someone sees a process that claims to be waiting but they don't see any entry in pg_locks, they know they saw inconsistent state. If we ad

Re: [HACKERS] Excessive WAL generation and related performance issue

On 4/14/14, 4:50 PM, Andres Freund wrote: Hi, On 2014-04-14 14:33:03 -0700, Joe Conway wrote: checkpoint_segments = 96 checkpoint_timeout = 10min I realize there are many things that can be done to improve my specific scenario, e.g. drop indexes before loading, change various configs, etc. M

Re: [HACKERS] Excessive WAL generation and related performance issue

Hi, On 2014-04-14 14:33:03 -0700, Joe Conway wrote: > checkpoint_segments = 96 > checkpoint_timeout = 10min > I realize there are many things that can be done to improve my > specific scenario, e.g. drop indexes before loading, change various > configs, etc. My purpose for this post is to ask if

[HACKERS] Excessive WAL generation and related performance issue

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have run into a situation where bulk loading a table with fairly narrow rows and two indexes causes WAL to be generated at about 20:1 or higher ratio to the actual heap data (table plus indexes). There are 560 million loaded rows which ultimately pr

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

Simon Riggs writes: > [ assorted comments about custom-scan patch, but particularly ] > * The prune hook makes me feel very uneasy. It seems weirdly specific > implementation detail, made stranger by the otherwise lack of data > maintenance API calls. Calling that for every dirty page sounds like

Re: [HACKERS] JSONB in-place updates?

On 04/14/2014 09:27 AM, kelas wrote: > Are there any plans to add "in-place at-depth" update operator for JSONB > type, e.g.: > > UPDATE test SET attrs->'anwser' = 42 where attrs->'answer' = 41 > Plans, yes. But not until 9.5, or maybe as an extension. -- Josh Berkus PostgreSQL Experts Inc. h

[HACKERS] JSONB in-place updates?

Are there any plans to add "in-place at-depth" update operator for JSONB type, e.g.: UPDATE test SET attrs->'anwser' = 42 where attrs->'answer' = 41

Re: [HACKERS] Create function prototype as part of PG_FUNCTION_INFO_V1

Peter Eisentraut writes: > What is the difference (on affected platforms) between > Datum funcname(PG_FUNCTION_ARGS); > and writing (effectively) > PGDLLEXPORT Datum funcname(PG_FUNCTION_ARGS); > Datum funcname(PG_FUNCTION_ARGS); > or for that matter > Datum funcname(PG_FUNCTION_ARGS); > PGDL

Re: [HACKERS] Patch to add support of "IF NOT EXISTS" to others "CREATE" statements

On Tue, Apr 1, 2014 at 2:46 PM, Robert Haas wrote: > > >> Where this is a bit more interesting is in the case of sequences, where > >> resetting the sequence to zero may cause further inserts into an > >> existing table to fail. > > > > Yeah. Sequences do have contained data, which makes COR hard

Re: [HACKERS] Create function prototype as part of PG_FUNCTION_INFO_V1

On 4/4/14, 10:07 AM, Andres Freund wrote: > If > somebody previously tried to do the correct thing and attached > PGDLLEXPORT to their own *function* prototoype, it would cause problems > now. What is the difference (on affected platforms) between Datum funcname(PG_FUNCTION_ARGS); and writing (e

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 04/14/2014 07:51 PM, Tom Lane wrote: I'd prefer to leave the prepare sequence alone and instead find a way to reject COMMIT PREPARED until after the source transaction is safely clear of the race conditions. The upthread idea of looking at vxid instead of xid might help, except that I see we

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On Mon, Apr 14, 2014 at 1:26 PM, Andres Freund wrote: > On 2014-04-14 13:06:21 -0400, Tom Lane wrote: >> Andres Freund writes: >> > On 2014-04-14 12:21:09 -0400, Robert Haas wrote: >> >> AFAICS, the big advantage of something like this is that we'd get >> >> proper deadlock detection, and that's

Re: [HACKERS] Signaling of waiting for a cleanup lock?

Andres Freund writes: > On 2014-04-14 13:06:21 -0400, Tom Lane wrote: >> In particular I'm not sold on the use-case >> for being able to tell that a process is waiting without being able to >> tell what it's waiting for. I can figure that much out already. > You can? How? It could also be io or

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 2014-04-14 13:47:35 -0400, Tom Lane wrote: > Andres Freund writes: > > I wonder if the most natural way to express this wouldn't be to have a > > heavyweight lock for every 2pc xact > > 'slot'. ResourceOwnerRelease(RESOURCE_RELEASE_LOCKS) should be scheduled > > correctly to make error handling

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

Andres Freund writes: > I wonder if the most natural way to express this wouldn't be to have a > heavyweight lock for every 2pc xact > 'slot'. ResourceOwnerRelease(RESOURCE_RELEASE_LOCKS) should be scheduled > correctly to make error handling for this work. That seems like not a bad idea. Could

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 2014-04-14 12:51:02 -0400, Tom Lane wrote: > The whole thing feels like we are solving the wrong problem, anyway. > IIUC, the complaint arises because we are allowing COMMIT PREPARED > to occur before the source transaction has reported successful prepare > to its client. Surely that does not n

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On 2014-04-14 13:06:21 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-04-14 12:21:09 -0400, Robert Haas wrote: > >> AFAICS, the big advantage of something like this is that we'd get > >> proper deadlock detection, and that's not a trivial point. > > > Hm. Is this actually something we

Re: [HACKERS] Signaling of waiting for a cleanup lock?

Andres Freund writes: > On 2014-04-14 12:21:09 -0400, Robert Haas wrote: >> AFAICS, the big advantage of something like this is that we'd get >> proper deadlock detection, and that's not a trivial point. > Hm. Is this actually something we need? I am not aware of deadlock prone > scenarios involv

Re: [HACKERS] Signaling of waiting for a cleanup lock?

Tom Lane wrote: > In an ideal world, when we needed to wait for a cleanup lock, we'd cause > the lock manager to set up pre-granted sharable page locks for all the > processes currently holding buffer pins, and then wait for an exclusive > page lock. The current hack of signaling when you're the

Re: [HACKERS] Including replication slot data in base backups

On Mon, Apr 14, 2014 at 9:26 AM, Fujii Masao wrote: > This makes me think that it's safer to just remove replication slot files > at the beginning of the recovery when both backup_label and recovery.conf > exist. Well, we could do that, but that would preempt anyone who *does* want to keep those

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On 2014-04-14 12:21:09 -0400, Robert Haas wrote: > AFAICS, the big advantage of something like this is that we'd get > proper deadlock detection, and that's not a trivial point. Hm. Is this actually something we need? I am not aware of deadlock prone scenarios involving buffer pins during normal p

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

Heikki Linnakangas writes: >> I think we'll need to transfer of the locks earlier, before the >> transaction is marked as fully prepared. I'll take a closer look at this >> tomorrow. > Here's a patch to do that. It's very straightforward, I just moved the > calls to transfer locks earlier, befor

Re: [HACKERS] Minor improvements in create_foreign_table.sgml

On Mon, Apr 14, 2014 at 5:03 AM, Etsuro Fujita wrote: > Attached is a small patch to improve create_foreign_table.sgml. OK, committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Sun, Apr 13, 2014 at 2:23 PM, Tom Lane wrote: > * I also left out the table documenting which aggregates have this > optimization. That's not the kind of thing we ordinarily document, > and it seems inevitable to me that such a table would be noteworthy > mostly for wrong/incomplete/obsolete i

Re: [HACKERS] Idea for aggregates

On 5 April 2014 04:18, Tom Lane wrote: > Greg Stark writes: >> Well in many cases stype will just be internal for many of them. That >> doesn't mean they're the same. > >> Hm, I suppose it might if they have the same sfunc. > >> This is actually where I started but we concluded that we needed som

Re: [HACKERS] Dynamic Shared Memory stuff

On Sat, Apr 12, 2014 at 1:32 AM, Amit Kapila wrote: > On Wed, Apr 9, 2014 at 9:20 PM, Robert Haas wrote: >> On Wed, Apr 9, 2014 at 7:41 AM, Amit Kapila wrote: >>> I am just not sure whether it is okay to rearrange the code and call >>> GetLastError() only if returned handle is Invalid (NULL) or

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On 2014-04-14 12:02:22 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-04-14 11:30:02 -0400, Tom Lane wrote: > >> I wonder whether we should not try to fix this by making the process wait > >> on a heavyweight lock, if it has to wait. That would also get us out of > >> the rather grott

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On Mon, Apr 14, 2014 at 12:02 PM, Tom Lane wrote: > Andres Freund writes: >> On 2014-04-14 11:30:02 -0400, Tom Lane wrote: >>> I wonder whether we should not try to fix this by making the process wait >>> on a heavyweight lock, if it has to wait. That would also get us out of >>> the rather grot

Re: [HACKERS] Signaling of waiting for a cleanup lock?

Andres Freund writes: > On 2014-04-14 11:30:02 -0400, Tom Lane wrote: >> I wonder whether we should not try to fix this by making the process wait >> on a heavyweight lock, if it has to wait. That would also get us out of >> the rather grotty business of using a special-purpose signal to wake it

Re: [HACKERS] server vs foreign server inconsistency

Jaime Casanova writes: > A few days ago i was wondering why we use CREATE/DROP SERVER but then > when we want to GRANT/REVOKE we need to use FOREIGN SERVER. Because the SQL standard says so. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgr

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On 2014-04-14 11:30:02 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-04-14 15:45:45 +0100, Simon Riggs wrote: > >> On 13 April 2014 16:44, Andres Freund wrote: > >>> What I am not sure about is how... It's trivial to set > >>> pg_stat_activity.waiting = true, but without a correspond

[HACKERS] server vs foreign server inconsistency

Hi, A few days ago i was wondering why we use CREATE/DROP SERVER but then when we want to GRANT/REVOKE we need to use FOREIGN SERVER. of course options are: 1) modify both to accept both forms 2) modify one of them to accept both forms and use that way in all our examples in docs 3) do nothing a

Re: [HACKERS] Signaling of waiting for a cleanup lock?

Andres Freund writes: > On 2014-04-14 15:45:45 +0100, Simon Riggs wrote: >> On 13 April 2014 16:44, Andres Freund wrote: >>> What I am not sure about is how... It's trivial to set >>> pg_stat_activity.waiting = true, but without a corresponding description >>> what the backend is waiting for it's

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On Mon, Apr 14, 2014 at 10:50 AM, Andres Freund wrote: > On 2014-04-14 15:45:45 +0100, Simon Riggs wrote: >> On 13 April 2014 16:44, Andres Freund wrote: >> > On 2014-04-12 17:40:34 -0400, Robert Haas wrote: >> >> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund >> >> wrote: >> >> > VACUUM somet

Re: [HACKERS] four minor proposals for 9.5

Pavel Stehule writes: > 2014-04-14 14:57 GMT+02:00 Robert Haas : >> I agree. I don't think the idea of pushing this into the >> log_line_prefix stuff as a one-off is a very good one. Sure, we could >> wedge it in there, but we've got an existing precedent that everything >> that you can get with

Re: [HACKERS] Minor improvements in alter_table.sgml

On Fri, Apr 11, 2014 at 5:00 AM, Etsuro Fujita wrote: > Attached is an updated version of the patch. I applied the first two hunks of this, which seem like clear oversights; and also the bit fixing the constraint_name language. I think the other changes deserve to be considered separately, and i

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On 2014-04-14 15:45:45 +0100, Simon Riggs wrote: > On 13 April 2014 16:44, Andres Freund wrote: > > On 2014-04-12 17:40:34 -0400, Robert Haas wrote: > >> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund > >> wrote: > >> > VACUUM sometimes waits synchronously for a cleanup lock on a heap > >> > pa

Re: [HACKERS] Signaling of waiting for a cleanup lock?

On 13 April 2014 16:44, Andres Freund wrote: > On 2014-04-12 17:40:34 -0400, Robert Haas wrote: >> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund >> wrote: >> > VACUUM sometimes waits synchronously for a cleanup lock on a heap >> > page. Sometimes for a long time. Without reporting it externall

Re: [HACKERS] HEAD seems to generate larger WAL regarding GIN index

Fujii Masao writes: > On Tue, Apr 1, 2014 at 1:41 AM, Robert Haas wrote: >> Should we try to install some hack around fastupdate for 9.4? I fear >> the divergence between reasonable values of work_mem and reasonable >> sizes for that list is only going to continue to get bigger. I'm sure >> the

Re: [HACKERS] Autonomous Transaction (WIP)

On 7 April 2014 05:06, Rajeev rastogi wrote: > *Autonomous Transaction Storage:* > > As for main transaction, structure PGXACT is used to store main > transactions, which are created in shared memory of size: > > (Number of process)*sizeof(struct PGXACT) > > Similarly a n

Re: [HACKERS] HEAD seems to generate larger WAL regarding GIN index

On Tue, Apr 1, 2014 at 1:41 AM, Robert Haas wrote: > On Thu, Mar 20, 2014 at 1:12 PM, Jesper Krogh wrote: >> On 15/03/14 20:27, Heikki Linnakangas wrote: >>> That said, I didn't expect the difference to be quite that big when you're >>> appending to the end of the table. When the new entries go t

Re: [HACKERS] Patch: add psql tab completion for event triggers

On Mon, Apr 14, 2014 at 9:46 PM, Robert Haas wrote: > On Wed, Apr 9, 2014 at 8:58 PM, Ian Barwick wrote: >> Apologies again, that was ill-thought out. Revised patch attached with only >> the additions related to event triggers, and the small fix for ALTER TRIGGER >> mentioned above which ensures

Re: [HACKERS] four minor proposals for 9.5

2014-04-14 14:57 GMT+02:00 Robert Haas : > On Tue, Apr 8, 2014 at 12:34 PM, Gregory Smith > wrote: > > On 4/6/14 2:46 PM, Pavel Stehule wrote: > >> Proposed options are interesting for "enterprise" using, when you have a > >> some more smart tools for log entry processing, and when you need a > c

Re: [HACKERS] Including replication slot data in base backups

On Thu, Apr 10, 2014 at 12:36 AM, Robert Haas wrote: > On Tue, Apr 8, 2014 at 3:08 AM, Michael Paquier > wrote: >> On Tue, Apr 8, 2014 at 1:18 AM, Robert Haas wrote: >>> Not sure if this is exactly the right way to do it, but I agree that >>> something along those lines is a good idea. I also t

Re: [HACKERS] four minor proposals for 9.5

On Tue, Apr 8, 2014 at 12:34 PM, Gregory Smith wrote: > On 4/6/14 2:46 PM, Pavel Stehule wrote: >> Proposed options are interesting for "enterprise" using, when you have a >> some more smart tools for log entry processing, and when you need a complex >> view about performance of billions queries -

Re: [HACKERS] Patch: add psql tab completion for event triggers

On Wed, Apr 9, 2014 at 8:58 PM, Ian Barwick wrote: > Apologies again, that was ill-thought out. Revised patch attached with only > the additions related to event triggers, and the small fix for ALTER TRIGGER > mentioned above which ensures "RENAME TO" is applied only when "ALTER > TRIGGER ON " wa

Re: [HACKERS] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

On 14 April 2014 03:31, Tom Lane wrote: > David Rowley writes: > > On this thread > > http://www.postgresql.org/message-id/52c6f712.6040...@student.kit.eduthere > > was some discussion around allowing push downs of quals that happen to be > > in every window clause of the sub query. I've quickly

[HACKERS] Re: Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

On 14 April 2014 02:50, Thomas Mayer wrote: > Hello David, > > thanks for your work. The results look promising. > Thanks > > What I'm missing is a test case with multiple fields in the partition by > clauses: > > I've modified the patch and added some regression tests that I think cover all o

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

On 24 March 2014 10:25, Kouhei Kaigai wrote: > Brief summary of the current approach that has been revised from my > original submission through the discussion on pgsql-hackers: > > The plannode was renamed to CustomPlan, instead of CustomScan, because > it dropped all the hardcoded portion that

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 2014-04-14 12:15:30 +0300, Heikki Linnakangas wrote: > Hmm. There's a field in GlobalTransactionData called locking_xid, which is > used to mark the XID of the transaction that's currently operating on the > prepared transaction. At prepare, that ensures that the transaction cannot > be committe

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/12/2014 05:03 PM, Andres Freund wrote: On 2014-04-12 09:47:24 -0400, Tom Lane wrote: Heikki Linnakangas writes: On 04/12/2014 12:07 AM, Jan Wieck wrote: the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that a txid_snapshot on o

[HACKERS] Minor improvements in create_foreign_table.sgml

Attached is a small patch to improve create_foreign_table.sgml. Thanks, Best regards, Etsuro Fujita diff --git a/doc/src/sgml/ref/create_foreign_table.sgml b/doc/src/sgml/ref/create_foreign_table.sgml index 06a7087..4a8cf38 100644 --- a/doc/src/sgml/ref/create_foreign_table.sgml +++ b/doc/src/sg

Re: [HACKERS] Adding unsigned 256 bit integers

Thanks for helping me out everyone. I ended up simply using the numeric type (I didn't realize it could support such large numbers) and writing the hex-to-numeric conversion functions in my application code. On 11 April 2014 12:27, Leon Smith wrote: > pgmp is also worth mentioning here, and i

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On Sun, Apr 13, 2014 at 05:46:20PM -0400, Jan Wieck wrote: > On 04/13/14 14:22, Jan Wieck wrote: > >On 04/13/14 08:27, Marko Kreen wrote: > >>I think you need to do SET_VARSIZE also here. Alternative is to > >>move SET_VARSIZE after sort_snapshot(). > >> > >>And it seems the drop-double-txid logic

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 04/13/2014 11:39 PM, Heikki Linnakangas wrote: However, I just noticed that there's a race condition between PREPARE TRANSACTION and COMMIT/ROLLBACK PREPARED. PostPrepare_Locks runs after the prepared transaction is already marked as fully prepared. That means that by the time we get to PostPr