Re: [HACKERS] Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

Hi, On 22/01/14 14:45, Tom Lane wrote: > Well, is it context or detail? Those fields have reasonably well defined > meanings IMO. I find the distinction somewhat blurry and think both would be appropriate. But since I wasn't sure I changed to detail. > If we need errcontext_plural, let's add it

Re: [HACKERS] [PATCH] Support for pg_stat_archiver view

On Thu, Jan 9, 2014 at 6:36 AM, Gabriele Bartolini wrote: > Il 08/01/14 18:42, Simon Riggs ha scritto: >> Not sure I see why it needs to be an SRF. It only returns one row. > Attached is version 4, which removes management of SRF stages. I have been looking at v4 a bit more, and found a couple of

Re: [HACKERS] WIP patch (v2) for updatable security barrier views

(2014/01/21 18:18), Dean Rasheed wrote: On 21 January 2014 01:09, KaiGai Kohei wrote: (2014/01/13 22:53), Craig Ringer wrote: On 01/09/2014 11:19 PM, Tom Lane wrote: Dean Rasheed writes: My first thought was that it should just preprocess any security barrier quals in subquery_planner()

Re: [HACKERS] GIN improvements part 1: additional information

On Wed, Jan 22, 2014 at 9:28 PM, Heikki Linnakangas wrote: > On 01/22/2014 02:17 PM, Alexander Korotkov wrote: > >> We already spent a lot of time with compression. Now we need to figure out >> the result we want see. I spent quite long time debugging varbyte encoding >> without segments. Finally

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

Amit Kapila writes: > On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote: >> So? Anything which can know the value of a GUC parameter can certainly >> know the selected port number. > 1. In case of registration of event source, either user has to pass the name > or it uses hard coded default v

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

(2014/01/23 12:00), Andrew Dunstan wrote: On 01/22/2014 08:28 PM, KONDO Mitsumasa wrote: (2014/01/22 22:26), Robert Haas wrote: On Wed, Jan 22, 2014 at 3:32 AM, KONDO Mitsumasa wrote: OK, Kondo, please demonstrate benchmarks that show we have <1% impact from this change. Otherwise we may nee

Re: [HACKERS] Confusing documentation of ordered-set aggregates?

I wrote: > Florian Pflug writes: >> array_agg(), for example, also has a result type that is >> determined by the argument type, yet it's final function doesn't take an >> argument of type anyelement, even though it returns anyarray. > Yeah. So it's a complete leap of faith on the type system's

Re: [HACKERS] Confusing documentation of ordered-set aggregates?

Florian Pflug writes: > After reading through the relevant parts of sytnax.sgml, create_aggregate.smgl > and xaggr.sgml, I think I understand how these work - they work exactly like > regular aggregates, except that some arguments are evaluated only once and > passed to the final function instead

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote: > Amit Kapila writes: >> On Wed, Jan 22, 2014 at 6:54 PM, Robert Haas wrote: >>> I wonder if the port number wouldn't be a better choice. And that >>> could even be done without adding a parameter. > >> We need this for register of event source w

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On 01/22/2014 08:28 PM, KONDO Mitsumasa wrote: (2014/01/22 22:26), Robert Haas wrote: On Wed, Jan 22, 2014 at 3:32 AM, KONDO Mitsumasa wrote: OK, Kondo, please demonstrate benchmarks that show we have <1% impact from this change. Otherwise we may need a config parameter to allow the calculati

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

On Jan23, 2014, at 01:07 , David Rowley wrote: > On Tue, Jan 21, 2014 at 3:20 AM, Florian Pflug wrote: >> On Jan20, 2014, at 08:42 , David Rowley wrote: >> >> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote: >> >> * I've also renamed INVFUNC to INVSFUNC. That's a pretty invasive change, >

[HACKERS] Confusing documentation of ordered-set aggregates?

Hi After reading through the relevant parts of sytnax.sgml, create_aggregate.smgl and xaggr.sgml, I think I understand how these work - they work exactly like regular aggregates, except that some arguments are evaluated only once and passed to the final function instead of the transition function.

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Wed, Jan 22, 2014 at 10:08 PM, Jim Nasby wrote: > > Probably more useful is the case of index scans; if we pre-read more data > from the index we could hand the kernel a list of base relation blocks that > we know we'll need. Actually, I've already tried this. The most important part is fetch

Re: [HACKERS] Proposal: variant of regclass

On Wed, Jan 22, 2014 at 1:44 PM, Yugo Nagata wrote: > On Wed, 22 Jan 2014 20:04:12 +0900 (JST) > Tatsuo Ishii wrote: > parseTypeString() is called by some other functions and I avoided > influences of modifying the definition on them, since this should > raise errors in most cases. This is same r

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On Wed, Jan 22, 2014 at 5:28 PM, KONDO Mitsumasa wrote: > Oh, thanks to inform me. I think essential problem of my patch has bottle > neck in sqrt() function and other division caluculation. Well, that's a pretty easy theory to test. Just stop calling them (and do something similar to what we do

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

(2014/01/22 22:26), Robert Haas wrote: On Wed, Jan 22, 2014 at 3:32 AM, KONDO Mitsumasa wrote: OK, Kondo, please demonstrate benchmarks that show we have <1% impact from this change. Otherwise we may need a config parameter to allow the calculation. OK, testing DBT-2 now. However, error range

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On 1/19/14, 5:51 PM, Dave Chinner wrote: Postgres is far from being the only application that wants this; many >people resort to tmpfs because of this: >https://lwn.net/Articles/499410/ Yes, we covered the possibility of using tmpfs much earlier in the thread, and came to the conclusion that tem

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On 1/17/14, 2:24 PM, Gregory Smith wrote: I am skeptical that the database will take over very much of this work and perform better than the Linux kernel does. My take is that our most useful role would be providing test cases kernel developers can add to a performance regression suite. Ugly

Re: [HACKERS] [PATCH] Relocation of tablespaces in pg_basebackup

My review: Clearly, everyone likes this feature. I'm tempted to think it should be mandatory to specify this option in plain mode when tablespaces are present. Otherwise, creating a base backup is liable to create random files all over the place. Obviously, there would be backward compatibility

Re: [HACKERS] proposal: hide application_name from other users

On Wed, Jan 22, 2014 at 1:03 PM, Josh Berkus wrote: > Probably Heroku has some more specific exploit case to be concerned > about here; if so, might I suggest taking it up with the -security list? I don't think there's a specific vulnerability that needs to be kept secret here. Here's an example

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On 1/17/14, 7:57 AM, Robert Haas wrote: - WAL files are written (and sometimes read) sequentially and fsync'd very frequently and it's always good to write the data out to disk as soon as possible - Temp files are written and read sequentially and never fsync'd. They should only be written to dis

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

On Jan23, 2014, at 01:17 , David Rowley wrote: > On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug wrote: >> If you want to play with >> this, I think the first step has to be to find a set of guarantees that >> SUM(float) is supposed to meet. Currently, SUM(float) guarantees that if the >> summand

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

On 1/21/14, 6:46 PM, Andres Freund wrote: On 2014-01-21 16:34:45 -0800, Peter Geoghegan wrote: >On Tue, Jan 21, 2014 at 3:43 PM, Andres Freund wrote: > >I personally think this isn't worth complicating the code for. > >You're probably right. However, I don't see why the bar has to be very >hi

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

On Wed, Jan 22, 2014 at 12:46 AM, Florian Pflug wrote: > On Jan21, 2014, at 10:53 , David Rowley wrote: > > It came to me that it might be possible to implement inverse transitions > > for floating point aggregates by just detecting if precision has been > > lost during forward transitions. > >

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

On Tue, Jan 21, 2014 at 3:20 AM, Florian Pflug wrote: > On Jan20, 2014, at 08:42 , David Rowley wrote: > >> On Mon, Jan 20, 2014 at 2:45 PM, Florian Pflug wrote: > >> * I've also renamed INVFUNC to INVSFUNC. That's a pretty invasive > change, and > >> it's the last commit, so if you object to

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

On 22 January 2014 14:25, Simon Riggs wrote: > On 22 January 2014 13:14, Heikki Linnakangas wrote: >> On 01/22/2014 02:10 PM, Simon Riggs wrote: >>> >>> As Jeff points out, the blocks being modified would be locked until >>> space is freed up. Which could make other users wait. The code >>> requi

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Tue, Jan 21, 2014 at 09:20:52PM +0100, Jan Kara wrote: > > If we're forcing the WAL out to disk because of transaction commit or > > because we need to write the buffer protected by a certain WAL record > > only after the WAL hits the platter, then it's fine. But sometimes > > we're writing WAL

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

On Wed, Jan 22, 2014 at 1:38 PM, Tom Lane wrote: > Hm, are there 5K distinct queries in the regression tests? I'd have > thought they weren't enough to fill a large pgss hash. Well, yes. They're a really bad case for pg_stat_statements, in that almost all distinct queries are only executed once

Re: [HACKERS] PoC: Duplicate Tuple Elidation during External Sort for DISTINCT

On Wed, Jan 22, 2014 at 3:26 PM, Tom Lane wrote: > Jeremy Harris writes: >> On 22/01/14 03:53, Tom Lane wrote: >>> Jon Nelson writes: - in createplan.c, eliding duplicate tuples is enabled if we are creating a unique plan which involves sorting first > >>> [ raised eyebrow ... ] And w

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

Peter Geoghegan writes: > On Wed, Jan 22, 2014 at 1:22 PM, Tom Lane wrote: >> BTW, have you got any sort of test scenario you could share for this >> purpose? I'm sure I could build something, but if you've already >> done it ... > I simply ran the standard regression tests, and then straced a

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

On Wed, Jan 22, 2014 at 1:22 PM, Tom Lane wrote: > BTW, have you got any sort of test scenario you could share for this > purpose? I'm sure I could build something, but if you've already > done it ... I simply ran the standard regression tests, and then straced a backend as it executed the pgss-

Re: [HACKERS] PoC: Duplicate Tuple Elidation during External Sort for DISTINCT

Jeremy Harris writes: > On 22/01/14 03:53, Tom Lane wrote: >> Jon Nelson writes: >>> - in createplan.c, eliding duplicate tuples is enabled if we are >>> creating a unique plan which involves sorting first >> [ raised eyebrow ... ] And what happens if the planner drops the >> unique step and th

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

Peter Geoghegan writes: > I ran an strace on a pg_stat_statements backend with a full ~5,000 > entries. BTW, have you got any sort of test scenario you could share for this purpose? I'm sure I could build something, but if you've already done it ... regards, tom lane -

Re: [HACKERS] PoC: Duplicate Tuple Elidation during External Sort for DISTINCT

On 22/01/14 03:53, Tom Lane wrote: Jon Nelson writes: A rough summary of the patch follows: - a GUC variable enables or disables this capability - in nodeAgg.c, eliding duplicate tuples is enabled if the number of distinct columns is equal to the number of sort columns (and both are gr

Re: [HACKERS] PoC: Duplicate Tuple Elidation during External Sort for DISTINCT

On 22/01/14 03:16, Jon Nelson wrote: Greetings -hackers: I have worked up a patch to PostgreSQL which elides tuples during an external sort. The primary use case is when sorted input is being used to feed a DISTINCT operation. The idea is to throw out tuples that compare as identical whenever it

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Fri 17-01-14 08:57:25, Robert Haas wrote: > On Fri, Jan 17, 2014 at 7:34 AM, Jeff Layton wrote: > > So this says to me that the WAL is a place where DIO should really be > > reconsidered. It's mostly sequential writes that need to hit the disk > > ASAP, and you need to know that they have hit t

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Wed 22-01-14 09:07:19, Dave Chinner wrote: > On Tue, Jan 21, 2014 at 09:20:52PM +0100, Jan Kara wrote: > > > If we're forcing the WAL out to disk because of transaction commit or > > > because we need to write the buffer protected by a certain WAL record > > > only after the WAL hits the platter

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Tue, Jan 21, 2014 at 09:20:52PM +0100, Jan Kara wrote: > On Fri 17-01-14 08:57:25, Robert Haas wrote: > > On Fri, Jan 17, 2014 at 7:34 AM, Jeff Layton wrote: > > > So this says to me that the WAL is a place where DIO should really be > > > reconsidered. It's mostly sequential writes that need t

Re: [HACKERS] proposal: hide application_name from other users

On Tue, Jan 21, 2014 at 7:38 PM, Stephen Frost wrote: > * Harold Giménez (har...@heroku.com) wrote: >> Definitely agree with you. This is just an example of how running >> monitoring as superuser is not necessarily the worst thing, and there >> are other reasons to do it already. > > It's a horrib

Re: [HACKERS] Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

Christian Kruse writes: >> However, the real problem here is that you shouldn't be calling ngettext >> manually in an ereport context in the first place. There is >> infrastructure in place for that, and this isn't using it. > Fixed in attached patch. I changed it from calling > errorcontext(nge

Re: [HACKERS] plpgsql.consistent_into

On 1/15/14, 12:35 AM, Tom Lane wrote: Jim Nasby writes: Do we actually support = right now? We already support v_field := field FROM table ... ; and I think it's a bad idea to have different meaning for = and :=. That ship sailed a *very* long time ago. See other thread about documenting rat

Re: [HACKERS] Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

Hi, attached you will find a new version of the patch containing more comments. On 22/01/14 12:00, Tom Lane wrote: > Alvaro Herrera writes: > > This ngettext() call is repeated four times in the new code, which is a > > bit annoying because it's not trivial. I think you could assign the > > nge

Re: [HACKERS] proposal: hide application_name from other users

Stephen Frost wrote: > Harold Giménez (har...@heroku.com) wrote: > >> This is just an example of how running monitoring as superuser >> is not necessarily the worst thing, and there are other reasons >> to do it already. > > It's a horrible thing and that isn't a good reason- if my > database isn'

Re: [HACKERS] Incorrectly reporting config errors

Tom Lane wrote: > Kevin Grittner writes: >> My preference would be to not generate noise for interim states; >> just report net changes. > > Yeah.  Is it worth explicitly detecting and dropping redundant assignments > to the same variable?  A naive check for that would be O(N^2) in the > number o

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

Peter Geoghegan writes: > On Tue, Jan 21, 2014 at 8:01 PM, Peter Geoghegan wrote: >>> Actually, I think the whole thing is rather badly designed, as warm >>> cache or no you're still proposing to do thousands of kernel calls >>> while holding a potentially contended LWLock. I suggest what we >>>

Re: [HACKERS] proposal: hide application_name from other users

On 01/21/2014 05:22 PM, Mark Kirkwood wrote: > If said malicious attacker can log into postgres and issue its own > queries, and connect to other database then you are in serious trouble > already. > > I also wonder that if such an attacker knows the application name, that > would suggest that the

Re: [HACKERS] Changeset Extraction v7.0 (was logical changeset generation)

On Wed, Jan 22, 2014 at 10:48 AM, Andres Freund wrote: > Yes, individual operations should be, but you cannot be sure whether a > rename()/unlink() will survive a crash until the directory is > fsync()ed. So, what is one going to do if the unlink suceeded, but the > fsync didn't? Well, apparently

Re: [HACKERS] WAL replay should fdatasync() segments?

On Thu, Jan 23, 2014 at 2:08 AM, Andres Freund wrote: > On 2014-01-23 02:05:48 +0900, Fujii Masao wrote: >> On Thu, Jan 23, 2014 at 1:21 AM, Andres Freund >> wrote: >> > Hi, >> > >> > Currently, XLogInsert(), XLogFlush() or XLogBackgroundFlush() will >> > write() data before fdatasync()ing them

Re: [HACKERS] new json funcs

On 01/21/2014 06:21 PM, Marko Tiikkaja wrote: Hi Andrew, On 1/18/14, 10:05 PM, I wrote: But I'll continue with my review now that this has been sorted out. Sorry about the delay. I think the API for the new functions looks good. They are all welcome additions to the JSON family. The imp

Re: [HACKERS] proposal: hide application_name from other users

On 01/21/2014 05:21 PM, Andres Freund wrote: > I think the only realistic thing is a "monitoring" capability, like we > have "replication". GRANT/REVOKE doesn't even come close to being able > to generically allow to grant permissions of even the moderate > complexity pg_stat_get_activity() has. T

Re: [HACKERS] dynamic shared memory and locks

On 2014-01-22 12:40:34 -0500, Robert Haas wrote: > On Wed, Jan 22, 2014 at 12:11 PM, Tom Lane wrote: > > Andres Freund writes: > >> Shouldn't we introduce a typedef LWLock* LWLockid; or something to avoid > >> breaking external code using lwlocks? > > > > +1, in fact there's probably no reason to

Re: [HACKERS] dynamic shared memory and locks

On Wed, Jan 22, 2014 at 12:11 PM, Tom Lane wrote: > Andres Freund writes: >> Shouldn't we introduce a typedef LWLock* LWLockid; or something to avoid >> breaking external code using lwlocks? > > +1, in fact there's probably no reason to touch most *internal* code using > that type name either. I

Re: [HACKERS] GIN improvements part 1: additional information

On 01/22/2014 02:17 PM, Alexander Korotkov wrote: We already spent a lot of time with compression. Now we need to figure out the result we want see. I spent quite long time debugging varbyte encoding without segments. Finally, it passed very many tests without any problems. Now, it is just piece

Re: [HACKERS] Incorrectly reporting config errors

Kevin Grittner writes: > My preference would be to not generate noise for interim states; > just report net changes. Yeah. Is it worth explicitly detecting and dropping redundant assignments to the same variable? A naive check for that would be O(N^2) in the number of entries in the conf file,

Re: [HACKERS] Incorrectly reporting config errors

On 2014-01-22 12:10:30 -0500, Tom Lane wrote: > Kevin Grittner writes: > > My preference would be to not generate noise for interim states; > > just report net changes. > > Yeah. Is it worth explicitly detecting and dropping redundant assignments > to the same variable? A naive check for that w

Re: [HACKERS] dynamic shared memory and locks

Andres Freund writes: > Shouldn't we introduce a typedef LWLock* LWLockid; or something to avoid > breaking external code using lwlocks? +1, in fact there's probably no reason to touch most *internal* code using that type name either. regards, tom lane -- Sent via pgsq

Re: [HACKERS] WAL replay should fdatasync() segments?

On 2014-01-23 02:05:48 +0900, Fujii Masao wrote: > On Thu, Jan 23, 2014 at 1:21 AM, Andres Freund wrote: > > Hi, > > > > Currently, XLogInsert(), XLogFlush() or XLogBackgroundFlush() will > > write() data before fdatasync()ing them (duh, kinda obvious). But I > > think given the current recovery c

Re: [HACKERS] Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

Alvaro Herrera writes: > This ngettext() call is repeated four times in the new code, which is a > bit annoying because it's not trivial. I think you could assign the > ngettext() to a char * at the bottom of the loop, and then in the > ereport() calls use it: Would that not break the compiler's

Re: [HACKERS] WAL replay should fdatasync() segments?

On Thu, Jan 23, 2014 at 1:21 AM, Andres Freund wrote: > Hi, > > Currently, XLogInsert(), XLogFlush() or XLogBackgroundFlush() will > write() data before fdatasync()ing them (duh, kinda obvious). But I > think given the current recovery code that leaves a window where we can > get into strange inco

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

Andres Freund writes: > On 2014-01-21 21:42:19 -0500, Tom Lane wrote: >> Uh, what? The behavior I'm talking about is *exactly the same* >> as what happens now. The only change is that the data sent to the >> WAL file is laid out a bit differently, and the replay logic has >> to work harder to re

Re: [HACKERS] dynamic shared memory and locks

On 2014-01-10 13:11:32 -0500, Robert Haas wrote: > OK, I've implemented this: here's what I believe to be a complete > patch, based on the previous lwlock-pointers.patch but now handling > LOCK_DEBUG and TRACE_LWLOCKS and dtrace and a bunch of other loose > ends. I think this should be adequate fo

Re: [HACKERS] Incorrectly reporting config errors

Andres Freund wrote: > A rather common and sensible configuration is to have a common > configuration file used across servers, which then is overwritten > by a per-server or per-cluster config file containing values > specific to a server/cluster. Agreed. My preference would be to not generate

[HACKERS] WAL replay should fdatasync() segments?

Hi, Currently, XLogInsert(), XLogFlush() or XLogBackgroundFlush() will write() data before fdatasync()ing them (duh, kinda obvious). But I think given the current recovery code that leaves a window where we can get into strange inconsistencies. Consider what happens if postgres (not the OS!) crash

Re: [HACKERS] Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

Christian Kruse wrote: I think this could use some more comments -- for instance at the top of the while loop, explain what's its purpose. > if (deadlock_state == DS_SOFT_DEADLOCK) > ereport(LOG, > (

Re: [HACKERS] Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

Hi, On 22/01/14 12:40, Simon Riggs wrote: > > 1. I find a issue in following scenario: > > > > session 1 with process id X: BEGIN; LOCK TABLE foo IN SHARE MODE; > > session 2 with process id Y: BEGIN; LOCK TABLE foo IN EXCLUSIVE > > MODE; > > session 3 with process id Z: B

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On Tue, Jan 21, 2014 at 3:20 PM, Jan Kara wrote: >> But that still doesn't work out very well, because now the guy who >> does the write() has to wait for it to finish before he can do >> anything else. That's not always what we want, because WAL gets >> written out from our internal buffers for

Re: [HACKERS] Changeset Extraction v7.0 (was logical changeset generation)

On 2014-01-22 10:14:27 -0500, Robert Haas wrote: > On Wed, Jan 22, 2014 at 9:48 AM, Andres Freund wrote: > > On 2014-01-18 08:35:47 -0500, Robert Haas wrote: > >> > I am not sure I understand that point. We can either update the > >> > in-memory bit before performing the on-disk operations or > >>

Re: [HACKERS] Funny representation in pg_stat_statements.query.

Kyotaro HORIGUCHI wrote: > Hello, > > > >> Since this becomes more than a simple bug fix, I think it is too > > >> late for 9.4 now. I'll work on this in the longer term. > > > > OK. I will get around to it someday, but if you do it first, that's fine. > > Nevertheless of my words, the drive is

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

On 2014-01-21 21:42:19 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2014-01-21 19:45:19 -0500, Tom Lane wrote: > >> I don't think that's a comparable case. Incomplete actions are actions > >> to be taken immediately, and which the replayer then has to complete > >> somehow if it doesn't

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

Amit Kapila writes: > On Wed, Jan 22, 2014 at 6:54 PM, Robert Haas wrote: >> I wonder if the port number wouldn't be a better choice. And that >> could even be done without adding a parameter. > We need this for register of event source which might be done before > start of server. So? Anythi

Re: [HACKERS] patch: option --if-exists for pg_dump

Tomorrow I'll send updated version Regards Pavel 2014/1/21 Jeevan Chalke > Hi Pavel, > > Consider following test scenario: > > mydb=# \d emp > Table "public.emp" > Column | Type | Modifiers > +-+--- > empno | integer | not null > deptno | integer | > enam

Re: [HACKERS] Why conf.d should be default, and auto.conf and recovery.conf should be in it

Amit Kapila writes: > On Tue, Jan 21, 2014 at 8:25 PM, Robert Haas wrote: >> While reviewing, I noted that the >> "skipping missing configuration file" message in ParseConfigFile() >> uses an elevel of LOG, while the other messages in the same file use >> "elevel". I'm thinking that's a bug. >

Re: [HACKERS] Dynamic Shared Memory stuff

On Wed, Jan 22, 2014 at 09:32:09AM -0500, Robert Haas wrote: > On Tue, Jan 21, 2014 at 2:58 PM, Noah Misch wrote: > >> What do people prefer? > > > > I recommend performing cleanup on the control segment named in PGShmemHeader > > just before shmdt() in PGSharedMemoryCreate(). No new ERROR or WAR

Re: [HACKERS] Changeset Extraction v7.0 (was logical changeset generation)

On Wed, Jan 22, 2014 at 9:48 AM, Andres Freund wrote: > On 2014-01-18 08:35:47 -0500, Robert Haas wrote: >> > I am not sure I understand that point. We can either update the >> > in-memory bit before performing the on-disk operations or >> > afterwards. Either way, there's a way to be inconsistent

Re: [HACKERS] Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist

Hello 2014/1/22 Dean Rasheed > On 21 January 2014 22:28, Alvaro Herrera wrote: > > I have been mulling over this patch, and I can't seem to come to terms > > with it. I first started making it look nicer here and there, thinking > > it was all mostly okay, but eventually arrived at the idea t

Re: [HACKERS] Changeset Extraction v7.0 (was logical changeset generation)

On 2014-01-18 08:35:47 -0500, Robert Haas wrote: > > I am not sure I understand that point. We can either update the > > in-memory bit before performing the on-disk operations or > > afterwards. Either way, there's a way to be inconsistent if the disk > > operation fails somewhere inbetween (it mig

[HACKERS] The problems of PQhost()

Hi, I reported in other thread that PQhost() has three problems. http://www.postgresql.org/message-id/cahgqgwe77akyabywde5+8bjldopthp7cnswao_syedjogyv...@mail.gmail.com (1) PQhost() can return Unix-domain socket directory path even in the platform that doesn't support

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Wed, Jan 22, 2014 at 6:54 PM, Robert Haas wrote: > On Tue, Jan 21, 2014 at 11:20 PM, Amit Kapila wrote: >> On Wed, Jan 22, 2014 at 9:19 AM, Tom Lane wrote: >>> Amit Kapila writes: On Tue, Jan 21, 2014 at 6:57 PM, MauMau wrote: > To follow this, we have the line as: > > #eve

Re: [HACKERS] Dynamic Shared Memory stuff

On Tue, Jan 21, 2014 at 2:58 PM, Noah Misch wrote: >> What do people prefer? > > I recommend performing cleanup on the control segment named in PGShmemHeader > just before shmdt() in PGSharedMemoryCreate(). No new ERROR or WARNING sites > are necessary. Have dsm_postmaster_startup() continue to

Re: [HACKERS] ALTER SYSTEM SET typos and fix for temporary file name management

On Tue, Jan 21, 2014 at 7:02 PM, Michael Paquier wrote: > On Wed, Jan 22, 2014 at 5:29 AM, Alvaro Herrera > wrote: >> I agree with Michael that having pg_basebackup be aware of the ".temp" >> suffix is ugly; for instance if we were to fix it to ".tmp" in ALTER >> SYSTEM but forgot to change pg_ba

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

Tom Lane wrote: > Well, PANIC is certainly bad, but what I'm suggesting is that we > just focus on getting that down to ERROR and not worry about > trying to get out of the disk-shortage situation automatically. > Nor do I believe that it's such a good idea to have the database > freeze up until

Re: GIN pending list pages not recycled promptly (was Re: [HACKERS] GIN improvements part 1: additional information)

Heikki Linnakangas wrote: > I wrote a little utility that scans all pages in a gin index, and > prints out the flags indicating what kind of a page it is. The > distribution looks like this: > > 19 DATA >7420 DATA LEAF > 24701 DELETED > 1 LEAF > 1 META Hah. > I think we n

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

On 22 January 2014 13:14, Heikki Linnakangas wrote: > On 01/22/2014 02:10 PM, Simon Riggs wrote: >> >> As Jeff points out, the blocks being modified would be locked until >> space is freed up. Which could make other users wait. The code >> required to avoid that wait would be complex and not worth

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

On Wed, Jan 22, 2014 at 3:32 AM, KONDO Mitsumasa wrote: >> OK, Kondo, please demonstrate benchmarks that show we have <1% impact >> from this change. Otherwise we may need a config parameter to allow >> the calculation. > > OK, testing DBT-2 now. However, error range of benchmark might be 1% highe

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Tue, Jan 21, 2014 at 11:20 PM, Amit Kapila wrote: > On Wed, Jan 22, 2014 at 9:19 AM, Tom Lane wrote: >> Amit Kapila writes: >>> On Tue, Jan 21, 2014 at 6:57 PM, MauMau wrote: To follow this, we have the line as: #event_source = 'PostgreSQL 9.4' But this requires us t

Re: [HACKERS] improve the help message about psql -F

OK,I will do it.Thanks. Jov blog: http:amutu.com/blog 2014/1/21 Marti Raudsepp > On Mon, Jan 20, 2014 at 2:04 PM, Jov wrote: > > reasonable，I removed the "set",patch attached. > > Hi Jov, > > A new commitfest was just opened, due on 2014-06. Please add your patch > her

Re: [HACKERS] GIN improvements part 1: additional information

On Wed, Jan 22, 2014 at 12:30 PM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote: > On 01/22/2014 09:25 AM, Alexander Korotkov wrote: > >> On Wed, Jan 22, 2014 at 1:21 AM, Heikki Linnakangas < >> hlinnakan...@vmware.com >> >>> wrote: >>> >> >> On 01/21/2014 11:35 AM, Heikki Linnakangas wrote

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

On 01/22/2014 02:10 PM, Simon Riggs wrote: As Jeff points out, the blocks being modified would be locked until space is freed up. Which could make other users wait. The code required to avoid that wait would be complex and not worth any overhead. Checkpoint also acquires the content lock of eve

GIN pending list pages not recycled promptly (was Re: [HACKERS] GIN improvements part 1: additional information)

On 01/22/2014 03:39 AM, Tomas Vondra wrote: What annoys me a bit is the huge size difference between the index updated incrementally (by a sequence of INSERT commands), and the index rebuilt from scratch using VACUUM FULL. It's a bit better with the patch (2288 vs. 2035 MB), but is there a chance

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

On 22 January 2014 01:30, Tom Lane wrote: > Andres Freund writes: >> How are we supposed to wait while e.g. ProcArrayLock? Aborting >> transactions doesn't work either, that writes abort records which can >> get signficantly large. > > Yeah, that's an interesting point ;-). We can't *either* com

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

On 22 January 2014 01:23, Tom Lane wrote: > Andres Freund writes: >> On 2014-01-21 18:59:13 -0500, Tom Lane wrote: >>> Another thing to think about is whether we couldn't put a hard limit on >>> WAL record size somehow. Multi-megabyte WAL records are an abuse of the >>> design anyway, when you g

Re: [HACKERS] Proposal: variant of regclass

On Wed, 22 Jan 2014 20:04:12 +0900 (JST) Tatsuo Ishii wrote: > > On Tue, Jan 14, 2014 at 9:28 AM, Yugo Nagata wrote: > >> Here is the patch to implement to_regclass, to_regproc, to_regoper, > >> and to_regtype. > > > > + static Datum regclass_guts(char *class_name_or_oid, bool raiseError); > >

Re: [HACKERS] Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire

On 22 January 2014 04:42, Rajeev rastogi wrote: > > On 31st December 2013, Christian Kruse Wrote: > >> Hi there, >> >> I created two patches improving the log messages generated by >> log_lock_waits. The first patch shows the process IDs holding a lock we >> try to acquire (show_pids_in_lock_log.p

Re: [HACKERS] Proposal: variant of regclass

> On Tue, Jan 14, 2014 at 9:28 AM, Yugo Nagata wrote: >> Here is the patch to implement to_regclass, to_regproc, to_regoper, >> and to_regtype. > > + static Datum regclass_guts(char *class_name_or_oid, bool raiseError); > > Minor bikeshedding, a lot of code currently uses an argument named > "mi

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

On Tue, Jan 21, 2014 at 8:01 PM, Peter Geoghegan wrote: >> BTW shouldn't there be an fflush() in qtext_store? > > I don't think so, no. Whenever qtext_store() callers don't fflush() > before releasing their exclusive lock, they FreeFile() before doing so > instead. In the case of pgss_shmem_startu

Re: [HACKERS] Storing pg_stat_statements query texts externally, pg_stat_statements in core

On Tue, Jan 21, 2014 at 8:01 PM, Peter Geoghegan wrote: >> Actually, I think the whole thing is rather badly designed, as warm >> cache or no you're still proposing to do thousands of kernel calls >> while holding a potentially contended LWLock. I suggest what we >> do is (1) read in the whole fi

Re: [HACKERS] Proposal: variant of regclass

On Tue, Jan 14, 2014 at 9:28 AM, Yugo Nagata wrote: > Here is the patch to implement to_regclass, to_regproc, to_regoper, > and to_regtype. + static Datum regclass_guts(char *class_name_or_oid, bool raiseError); Minor bikeshedding, a lot of code currently uses an argument named "missing_ok" for

Re: [HACKERS] GIN improvements part 1: additional information

On 01/22/2014 09:25 AM, Alexander Korotkov wrote: On Wed, Jan 22, 2014 at 1:21 AM, Heikki Linnakangas wrote: On 01/21/2014 11:35 AM, Heikki Linnakangas wrote: Oh, I see what's going on. I had assumed that there cannot be duplicate insertions into the posting tree, but that's dead wrong. The

Re: [HACKERS] Trigger information for auto_explain.

Hello, I came back with doc patch and revised 0002 patch. > > > I think documentation is the only thing that stops this patch to be > > > commitable... can you add it? > > > > Agreed. I have pushed patch 0001 for now. > > Thank you, I'll put it sooner. I found the default setting for log_trigg

Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

(2014/01/22 9:34), Simon Riggs wrote: AFAICS, all that has happened is that people have given their opinions and we've got almost the same identical patch, with a rush-rush comment to commit even though we've waited months. If you submit a patch, then you need to listen to feedback and be clear a

  1   2   >