Re: [HACKERS] Replication logging

On Tue, Jan 18, 2011 at 4:15 PM, Heikki Linnakangas wrote: > I also find it weird that incoming replication connections are logged by > default. In the standby, we also log "streaming replication successfully > connected to primary", which serves much of the same debugging purpose. That > standby-

Re: [HACKERS] ToDo List Item - System Table Index Clustering

Followup on System Table Index clustering ToDo - It looks like to implement this I need to do the following: 1 - Add statements to indexing.h to cluster the selected indexes. A do-nothing define at the top to suppress warnings and then lines below for perl to pars

Re: [HACKERS] Replication logging

On 17.01.2011 21:04, Robert Haas wrote: On Mon, Jan 17, 2011 at 1:57 PM, Tom Lane wrote: I'm of the opinion that the correct way of "lowering in later releases" is to make the messages obey Log_connections. The "needed for debug" argument seems mighty weak to me even for the time, and surely f

Re: [HACKERS] We need to log aborted autovacuums

On mån, 2011-01-17 at 17:26 -0800, Josh Berkus wrote: > However, it's hard for me to imagine a real-world situation where a > table would be under repeated full-table-locks from multiple > connections. Can anyone else? If you want to do assertion-type checks at the end of transactions in the curr

Re: [HACKERS] SQL/MED - file_fdw

On Sat, Jan 15, 2011 at 08:35, Shigeru HANADA wrote: > Interface of NextCopyFrom() is fixed to return HeapTuple, to support > tableoid without any change to TupleTableSlot. > > 3) 20110114-copy_export_HeapTupe.patch > This patch fixes interface of NextCopyFrom() to return results as > HeapTuple.

[HACKERS] MingW + GCC 4.5.2 + Relocate libpq.dll = SegFault

I'm compiling postgresql 9.0.2 using msys + mingw + gcc 4.5.2 (latest official release from mingw). This is on Windows 7 64-bit. Unfortunately the built dlls, at least libpq.dll, crash if they need to be relocated. This happens to me when loading libpq.dll into a project that has a number of

[HACKERS] Confusing comment in TransactionIdIsInProgress

Shouldn't the comment read "If first time through"? /* * If not first time through, get workspace to remember main XIDs in. We * malloc it permanently to avoid repeated palloc/pfree overhead. */ if (xids == NULL) { ... xids = (Tran

Re: [HACKERS] SSI patch version 12

"Kevin Grittner" writes: >> Dan Ports wrote: > The biggest, in my mind, is whether > MySerializableXact needs to be declared volatile. > The problem is that I don't have a very clear sense of what it really > does, which is not helped much by having done a few years of Java > programming,

Re: [HACKERS] pg_filedump moved to pgfoundry

David Fetter writes: > On Mon, Jan 17, 2011 at 09:48:58PM -0500, Tom Lane wrote: >> (Before someone suggests folding it into contrib/: we can't because >> of license issues. pg_filedump is GPL, per Red Hat company policy, >> and that's not going to change.) > Who's the copyright holder(s)? If i

Re: [HACKERS] pg_filedump moved to pgfoundry

On Mon, Jan 17, 2011 at 09:48:58PM -0500, Tom Lane wrote: > I've gotten permission to move pg_filedump from its former home at > sources.redhat.com to pgfoundry. You can find the historical release > tarballs as well as current sources at > http://pgfoundry.org/projects/pgfiledump/ > > One

Re: [HACKERS] SSI patch version 12

> Dan Ports wrote: > On Mon, Jan 17, 2011 at 07:20:20PM -0600, Kevin Grittner wrote: >> OK. I may need to bounce some questions off the list to resolve >> some of them. The biggest, in my mind, is whether >> MySerializableXact needs to be declared volatile. I don't have my >> head around the issue

Re: [HACKERS] texteq/byteaeq: avoid detoast [REVIEW]

On mån, 2011-01-17 at 15:33 -0500, Tom Lane wrote: > Peter Eisentraut writes: > > On mån, 2011-01-17 at 07:35 +0100, Magnus Hagander wrote: > >> In fact, aren't there cases where the *length test* also fails? > > > Currently, two text values are only equal of strcoll() considers them > > equal an

Re: [HACKERS] limiting hint bit I/O

On Jan 14, 2011, at 7:24 PM, Josh Berkus wrote: > On 1/14/11 11:51 AM, Tom Lane wrote: >> The people whose tables are mostly insert-only complain about it, but >> that's not the majority of our userbase IMO. We just happen to have a >> couple of particularly vocal ones, like Berkus. > > It might

Re: [HACKERS] We need to log aborted autovacuums

Josh Berkus writes: > On 1/17/11 11:46 AM, Tom Lane wrote: >> Do we actually need a lock timeout either? The patch that was being >> discussed just involved failing if you couldn't get it immediately. >> I suspect that's sufficient for AV. At least, nobody's made a >> compelling argument why we

[HACKERS] pg_filedump moved to pgfoundry

I've gotten permission to move pg_filedump from its former home at sources.redhat.com to pgfoundry. You can find the historical release tarballs as well as current sources at http://pgfoundry.org/projects/pgfiledump/ One advantage of doing this is it will be a lot easier to let other folk

Re: [HACKERS] pg_basebackup for streaming base backups

On Mon, Jan 17, 2011 at 10:50 PM, Magnus Hagander wrote: >> +       printf(_("  -D, --pgdata=directory   receive base backup into >> directory\n")); >> +       printf(_("  -T, --tardir=directory    receive base backup into tar >> files\n" >> +                        "                            

Re: [HACKERS] We need to log aborted autovacuums

On Mon, Jan 17, 2011 at 8:26 PM, Josh Berkus wrote: > On 1/17/11 11:46 AM, Tom Lane wrote: >> Do we actually need a lock timeout either?  The patch that was being >> discussed just involved failing if you couldn't get it immediately. >> I suspect that's sufficient for AV.  At least, nobody's made

Re: [HACKERS] estimating # of distinct values

On Mon, Jan 17, 2011 at 7:56 PM, Jim Nasby wrote: > - Forks are very possibly a more efficient way to deal with TOAST than having > separate tables. There's a fair amount of overhead we pay for the current > setup. That seems like an interesting idea, but I actually don't see why it would be an

Re: [HACKERS] Spread checkpoint sync

Bruce Momjian wrote: Should we be writing until 2:30 then sleep 30 seconds and fsync at 3:00? The idea of having a dead period doing no work at all between write phase and sync phase may have some merit. I don't have enough test data yet on some more fundamental issues in this area to com

Re: [HACKERS] psql: Add \dL to show languages

Hi all, I've updated the patch to address the following points: * help string now says "list procedural languages" (no parentheses now) * the language name column is now titled "Name" * added another column in verbose mode for 9.0+ showing whether DO blocks are possible with the language. I nam

Re: [HACKERS] Moving test_fsync to /contrib?

Alvaro Herrera wrote: I don't understand why it would be "overkill". Are you saying people would complain because you installed a 25 kB executable that they might not want to use? Just for fun I checked /usr/bin and noticed that I have a "pandoc" executable, weighing 17 MB, that I have never us

Re: [HACKERS] test_fsync open_sync test

Bruce Momjian wrote: Is there a value to this test_fsync test? Compare open_sync with different sizes: (This is designed to compare the cost of one large sync'ed write and two smaller sync'ed writes.) open_sync 16k write 242.563 ops/sec

Re: [HACKERS] We need to log aborted autovacuums

On 1/17/11 11:46 AM, Tom Lane wrote: > Do we actually need a lock timeout either? The patch that was being > discussed just involved failing if you couldn't get it immediately. > I suspect that's sufficient for AV. At least, nobody's made a > compelling argument why we need to expend a very subst

Re: [HACKERS] SSI patch version 12

On Mon, Jan 17, 2011 at 07:20:20PM -0600, Kevin Grittner wrote: > OK. I may need to bounce some questions off the list to resolve some > of them. The biggest, in my mind, is whether MySerializableXact > needs to be declared volatile. I don't have my head around the > issues on that as well as I

Re: [HACKERS] Review: compact fsync request queue on overflow

Chris Browne wrote: It was a little troublesome inducing it. I did so by cutting shared memory to minimum (128kB)... With higher shared memory, I couldn't readily induce compaction, which is probably a concurrency matter of not having enough volume of concurrent wor

Re: [HACKERS] SSI patch version 12

> Heikki Linnakangas wrote: > Setting the high bit in OldSetXidAdd() seems a bit weird. How about > just using UINT64_MAX instead of 0 to mean no conflicts? Or 1, and > start the sequence counter from 2. Sure. I think I like reserving 1 and starting at 2 better. Will do. > ReleasePredicate

Re: [HACKERS] SSI patch version 12

On Mon, Jan 17, 2011 at 06:52:09PM -0600, Kevin Grittner wrote: > I think we still need the vxid. It shows in the pg_locks view, and > we might possibly need it to find the right process to cancel once we > have some way to do that. But there's no point with having the tag > level anymore. Oh, r

Re: [HACKERS] estimating # of distinct values

On Jan 17, 2011, at 6:36 PM, Tomas Vondra wrote: > 1) Forks are 'per relation' but the distinct estimators are 'per > column' (or 'per group of columns') so I'm not sure whether the file > should contain all the estimators for the table, or if there should > be one fork for each estimator. Th

Re: [HACKERS] REVIEW: PL/Python validator function

On 17/01/11 09:26, Jan Urbański wrote: > On 17/01/11 01:02, Hitoshi Harada wrote: >> This is a review for the patch sent as >> https://commitfest.postgresql.org/action/patch_view?id=456 >> It includes adequate amount of test. I found regression test failure >> in plpython_error. > >> My environmen

Re: [HACKERS] SSI patch version 12

> Dan Ports wrote: > Yes, that comment was supposed to be attached to > possibleUnsafeConflicts. > Actually, I think that "other" hash no longer exists > The comment above SERIALIZABLEXACT also needs to be updated since > it refers to said hash table. And if I'm not mistaken (Kevin?), we > c

Re: [HACKERS] estimating # of distinct values

Dne 9.1.2011 13:58, Jim Nasby napsal(a): >> A resource fork? Not sure what you mean, could you describe it in more >> detail? > > Ooops, resource forks are a filesystem thing; we call them relation forks. > >From src/backend/storage/smgr/README: OK, I think using relation forks seems like a good

Re: [HACKERS] Spread checkpoint sync

Jim Nasby wrote: Wow, that's the kind of thing that would be incredibly difficult to figure out, especially while your production system is in flames... Can we change ereport that happens in that case from DEBUG1 to WARNING? Or provide some other means to track it That's why we already added

Re: [HACKERS] SQL/MED - file_fdw

Itagaki Takahiro wrote: > Shigeru HANADA wrote: >> Attached patch would avoid this leak by adding per-copy context to >> CopyState. This would be overkill, and ResetCopyFrom() might be >> reasonable though. > > Good catch. I merged your fix into the attached patch. Review for CF: While ther

Re: [HACKERS] Spread checkpoint sync

On Mon, Jan 17, 2011 at 6:07 PM, Jim Nasby wrote: > On Jan 15, 2011, at 8:15 AM, Robert Haas wrote: >> Well, the point of this is not to save time in the bgwriter - I'm not >> surprised to hear that wasn't noticeable.  The point is that when the >> fsync request queue fills up, backends start perf

Re: [HACKERS] Moving test_fsync to /contrib?

> Also, it's not going to get packaged at all unless it gets renamed to > something less generic, maybe pg_test_fsync; I'm not going to risk the > oppobrium of sticking something named "test_fsync" into /usr/bin. > Moving to contrib would be a good opportunity to fix the name. +1. It would be a

Re: [HACKERS] WIP: RangeTypes

On 1/17/11 1:09 PM, Jeff Davis wrote: > I feel like I'm making this too complicated. Should I just scope out > NULL range boundaries for the first cut, and leave room in the > representation so that it can be added when there is a more thorough > proposal for NULL range boundaries? Well, NULL rang

Re: [HACKERS] WIP: RangeTypes

Jeff Davis writes: > I feel like I'm making this too complicated. Should I just scope out > NULL range boundaries for the first cut, and leave room in the > representation so that it can be added when there is a more thorough > proposal for NULL range boundaries? +1. I'm far from convinced that

Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support

On Tue, 18 Jan 2011 00:06:10 +0100, Brar Piening wrote: So there is now a third version of this patch at http://www.piening.info/VS2010v3.patch Forgot to run perltidy on it - fixed in http://www.piening.info/VS2010v4.patch Sorry! Brar -- Sent via pgsql-hackers mailing list (pgsql-hack

Re: [HACKERS] Spread checkpoint sync

On Jan 15, 2011, at 8:15 AM, Robert Haas wrote: > Well, the point of this is not to save time in the bgwriter - I'm not > surprised to hear that wasn't noticeable. The point is that when the > fsync request queue fills up, backends start performing an fsync *for > every block they write*, and that

Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support

Hi, I initially considered this patch as a primer to start off some basic VS2010 support and not as something to be commited within the next few commitfests. As there seems to be at least some interest in this patch I refactored the code and did some more testing (actually found some weird i

Re: [HACKERS] pg_dump directory archive format / parallel pg_dump

On Fri, Jan 7, 2011 at 3:18 PM, Joachim Wieland wrote: > Here's a new series of patches for the parallel dump/restore. They need to be > applied on top of each other. > This one is the last version of this patch? if so, commitfest app should be updated to reflect that -- Jaime Casanova        

Re: [HACKERS] Warning compiling pg_dump (MinGW, Windows XP)

On 01/17/2011 03:51 PM, Tom Lane wrote: Andrew Dunstan writes: On 01/17/2011 07:18 AM, Pavel Golub wrote: So you think I should just ignore these warnings? Because I can't remember the same behaviour on 8.x branches... We've had them all along, as I said. See

Re: [HACKERS] SSI patch version 12

On Mon, Jan 17, 2011 at 09:58:44PM +0200, Heikki Linnakangas wrote: > What does that comment about list of concurrent r/w transactions refer > to? I don't see any list there. Does it refer to > possibleUnsafeConflicts, which is above that comment? Yes, that comment was supposed to be attached to

Re: [HACKERS] WIP: RangeTypes

On Mon, Jan 17, 2011 at 01:09:26PM -0800, Jeff Davis wrote: > When defining generic range functions, there is quite a bit of extra > complexity needed to handle special cases. > > The special cases are due to: > * empty ranges > * ranges with infinite boundaries > * ranges with NULL boundaries

Re: [HACKERS] texteq/byteaeq: avoid detoast [REVIEW]

On Mon, Jan 17, 2011 at 02:36:56PM -0600, Jim Nasby wrote: > On Jan 17, 2011, at 9:22 AM, Noah Misch wrote: > > Just to be clear, the code already has these length tests today. This patch > > just moves them before the detoast. > > Any reason we can't do this for other varlena? I'm wondering if i

Re: [HACKERS] WIP: RangeTypes

When defining generic range functions, there is quite a bit of extra complexity needed to handle special cases. The special cases are due to: * empty ranges * ranges with infinite boundaries * ranges with NULL boundaries * ranges with exclusive bounds (e.g. "(" or ")"). Infinite bounds, and e

Re: [HACKERS] Bug in pg_describe_object, patch v2

2011/1/17 Tom Lane : > Joel Jacobson writes: >> a) pg_describe_object should always include the schema in the name, >> even for object in public and pg_catalog. > > I knew you were going to demand that next, as soon as you figured out > that it was an obstacle for using pg_describe_object output a

Re: [HACKERS] We need to log aborted autovacuums

Simon Riggs writes: > On Mon, 2011-01-17 at 14:46 -0500, Tom Lane wrote: >> Do we actually need a lock timeout either? The patch that was being >> discussed just involved failing if you couldn't get it immediately. >> I suspect that's sufficient for AV. At least, nobody's made a >> compelling ar

Re: [HACKERS] Bug in pg_describe_object, patch v2

Tom Lane writes: > Joel Jacobson writes: >> a) pg_describe_object should always include the schema in the name, >> even for object in public and pg_catalog. > > I knew you were going to demand that next, as soon as you figured out > that it was an obstacle for using pg_describe_object output as

Re: [HACKERS] Bug in pg_describe_object, patch v2

On Sun, 2011-01-16 at 14:28 -0500, Tom Lane wrote: > One other point here is that I find messages like this a mite > unreadable: > > function 1 (oidvector[], oidvector[]) btoidvectorcmp(oidvector,oidvector) of > operator family array_ops for access method gin > > If we were to go with this, I'd

Re: [HACKERS] Warning compiling pg_dump (MinGW, Windows XP)

Andrew Dunstan writes: > On 01/17/2011 07:18 AM, Pavel Golub wrote: >> So you think I should just ignore these warnings? Because I can't >> remember the same behaviour on 8.x branches... > We've had them all along, as I said. See >

Re: [HACKERS] psql: Add \dL to show languages

On Sun, 2011-01-16 at 22:32 -0500, Josh Kupershmidt wrote: > On Sat, Jan 15, 2011 at 8:26 PM, Andreas Karlsson wrote: > > Should we include a column in \dL+ for the laninline function (DO > > blocks)? > > Hrm, I guess that could be useful for the verbose output at least. Magnus Hagander agreed w

Re: [HACKERS] Bug in pg_describe_object, patch v2

Joel Jacobson writes: > a) pg_describe_object should always include the schema in the name, > even for object in public and pg_catalog. I knew you were going to demand that next, as soon as you figured out that it was an obstacle for using pg_describe_object output as a globally unique identifier

Re: [HACKERS] log_hostname and pg_stat_activity

Excerpts from Peter Eisentraut's message of sáb ene 15 13:15:45 -0300 2011: > Here is a patch that adds a client_hostname field to pg_stat_activity. > It takes the hostname if it is available either by having log_hostname > set or if the pg_hba.conf processing resolved it. So I think for most > p

Re: [HACKERS] texteq/byteaeq: avoid detoast [REVIEW]

Magnus Hagander writes: > I wonder if we can trust the *equality* test, but not the inequality? > E.g. if compressed(A) == compressed(B) we know they're the same, but > if compressed(A) != compressed(B) we don't know they're not they still > might be. I haven't looked at this patch, but it seems

Re: [HACKERS] psql: Add \dL to show languages

On Mon, 2011-01-17 at 07:37 +0100, Magnus Hagander wrote: > Yeah. Procedural langauges may strictly be wrong, but people aren't > likely to misunderstand it. That was idea when suggesting we call it "procedural languages". It is short and I do not think it can be misunderstood. Regards, Andreas

Re: [HACKERS] texteq/byteaeq: avoid detoast [REVIEW]

On Jan 17, 2011, at 9:22 AM, Noah Misch wrote: > On Mon, Jan 17, 2011 at 07:35:52AM +0100, Magnus Hagander wrote: >> On Mon, Jan 17, 2011 at 06:51, Itagaki Takahiro >> wrote: >>> On Mon, Jan 17, 2011 at 04:05, Andy Colson wrote: This is a review of: https://commitfest.postgresql.org/act

Re: [HACKERS] texteq/byteaeq: avoid detoast [REVIEW]

Peter Eisentraut writes: > On mån, 2011-01-17 at 07:35 +0100, Magnus Hagander wrote: >> In fact, aren't there cases where the *length test* also fails? > Currently, two text values are only equal of strcoll() considers them > equal and the bits are the same. So this patch is safe in that regard

Re: [HACKERS] We need to log aborted autovacuums

On Mon, 2011-01-17 at 14:46 -0500, Tom Lane wrote: > Josh Berkus writes: > > However, we'd want a separate lock timeout for autovac, of course. I'm > > not at all keen on a *statement* timeout on autovacuum; as long as > > autovacuum is doing work, I don't want to cancel it. Also, WTF would we >

Re: [HACKERS] Warning compiling pg_dump (MinGW, Windows XP)

Robert Haas writes: > 2011/1/13 Pavel Golub : >> pg_dump.c: In function 'dumpSequence': >> pg_dump.c:11449:2: warning: unknown conversion type character 'l' in format >> pg_dump.c:11449:2: warning: too many arguments for format > It seems like PGAC_FUNC_SNPRINTF_LONG_LONG_INT_FORMAT is getting th

Re: [HACKERS] SSI patch version 12

On 15.01.2011 01:54, Kevin Grittner wrote: /* * for r/o transactions: list of concurrent r/w transactions that we could * potentially have conflicts with, and vice versa for r/w transactions */ TransactionId topXid; /* top level xid for the tr

Re: [HACKERS] [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.

On Mon, Jan 17, 2011 at 2:25 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut wrote: >>> Maybe instead of the proposed patch, a notice could be added: >>> NOTICE: existing object was replaced > >> Well, that would eliminate the backward-compatibility

Re: [HACKERS] pl/python refactoring

On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote: > Here they are. There are 16 patches in total. They amount to what's > currently in my refactor branch (and almost to what I've sent as the > complete refactor patch, while doing the splitting I discovered a few > useless hunks that I've disca

Re: [HACKERS] We need to log aborted autovacuums

Josh Berkus writes: > However, we'd want a separate lock timeout for autovac, of course. I'm > not at all keen on a *statement* timeout on autovacuum; as long as > autovacuum is doing work, I don't want to cancel it. Also, WTF would we > set it to? Yeah --- in the presence of vacuum cost delay,

Re: [HACKERS] [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.

On Mon, Jan 17, 2011 at 09:23:07PM +0200, Peter Eisentraut wrote: > On mån, 2011-01-17 at 10:05 -0500, Robert Haas wrote: > > On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut wrote: > > > On fre, 2011-01-14 at 18:45 -0500, Robert Haas wrote: > > >> On Fri, Jan 14, 2011 at 3:45 PM, Marti Raudsepp

Re: [HACKERS] pg_basebackup for streaming base backups

On Mon, Jan 17, 2011 at 20:31, Tom Lane wrote: > Magnus Hagander writes: >> Actually, after some IM chats, I think pg_streamrecv should be >> renamed, probably to pg_walstream (or pg_logstream, but pg_walstream >> is a lot more specific than that) > > What I like about streamrecv is it's fairly c

Re: [HACKERS] pg_basebackup for streaming base backups

Magnus Hagander writes: > Actually, after some IM chats, I think pg_streamrecv should be > renamed, probably to pg_walstream (or pg_logstream, but pg_walstream > is a lot more specific than that) What I like about streamrecv is it's fairly clear which end of the connection it's supposed to be use

Re: [HACKERS] Streaming base backups

Magnus Hagander writes: >> Until we get integrated WAL streaming while the base backup is ongoing. >> We don't know when that is (9.1 or future), but that's what we're aiming >> to now, right? > > Yeah, it does sound like a plan. But to still allow both - streaming > it in parallell will eat two c

Re: [HACKERS] [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.

Robert Haas writes: > On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut wrote: >> Maybe instead of the proposed patch, a notice could be added: >> NOTICE: existing object was replaced > Well, that would eliminate the backward-compatibility hazard, pretty > much, but it seems noisy. I already fi

Re: [HACKERS] [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.

On mån, 2011-01-17 at 10:05 -0500, Robert Haas wrote: > On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut wrote: > > On fre, 2011-01-14 at 18:45 -0500, Robert Haas wrote: > >> On Fri, Jan 14, 2011 at 3:45 PM, Marti Raudsepp > >> wrote: > >> > There's a similar case with CREATE TABLE IF NOT EXISTS

Re: [HACKERS] Determining client_encoding from client locale

On mån, 2011-01-17 at 14:59 +0100, Susanne Ebrecht wrote: > I didn't thought about pg_dump dump files here. > I more thought about files that came out of editors using mad encoding > and maybe then also were created on Windows and then copied to > Unix for import. > > Written on little endian, cop

Re: [HACKERS] texteq/byteaeq: avoid detoast [REVIEW]

On mån, 2011-01-17 at 07:55 -0500, Robert Haas wrote: > > There is, however, some desire to loosen this. Possible > applications > > are case-insensitive comparison and Unicode normalization. It's not > > going to happen soon, but it may be worth considering not putting in > an > > optimization t

Re: [HACKERS] Review: compact fsync request queue on overflow

On Mon, Jan 17, 2011 at 1:43 PM, Chris Browne wrote: >      (I observe that it wasn't all that obvious that "hash_search()" >      *adds* elements that are missing.  I got confused and went >      looking for "hash_add() or similar.  It's permissible to say "dumb >      Chris".) I didn't invent t

Re: [HACKERS] Replication logging

On Mon, Jan 17, 2011 at 1:57 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Mon, Jan 17, 2011 at 17:46, Tom Lane wrote: >>> I think it'd make more sense just to say that replication connections >>> are subject to the same log_connections rule as others.  An extra GUC >>> for this is surely

Re: [HACKERS] Replication logging

Magnus Hagander writes: > On Mon, Jan 17, 2011 at 17:46, Tom Lane wrote: >> I think it'd make more sense just to say that replication connections >> are subject to the same log_connections rule as others.  An extra GUC >> for this is surely overkill. > I thought so, but Robert didn't agree. And

[HACKERS] Review: compact fsync request queue on overflow

I have been taking a peek at the following commitfest item: https://commitfest.postgresql.org/action/patch_view?id=497 Submission: - I had to trim a little off the end of the patch to apply it, but that's likely the fault of how I cut'n'pasted it. It applied cleanly against HEAD. - I obse

Re: [HACKERS] Spread checkpoint sync

Jeff Janes wrote: Have you ever tested Robert's other idea of having a metronome process do a periodic fsync on a dummy file which is located on the same ext3fs as the table files? I think that that would be interesting to see. To be frank, I really don't care about fixing this behavior on

Re: [HACKERS] What happened to open_sync_without_odirect?

Josh Berkus wrote: > On 1/15/11 4:30 PM, Bruce Momjian wrote: > > Josh Berkus wrote: > >> Last I remember, we were going to add this as an option. But I don't > >> see a patch in the queue. Am I missing it? Was I supposed to write it? > > > > I don't know, but let me add that I am confused how

Re: [HACKERS] REVIEW: Extensions support for pg_dump

> Well I'm not seeing that here I am not at work at the moment and I don't have the possibility to compile PostgreSQL on this computer, so the example here is from memory. The issue I saw was this: assume you have an extension foo, containing one function, test(). CREATE EXTENSION foo; DROP FU

Re: [HACKERS] Moving test_fsync to /contrib?

On Mon, Jan 17, 2011 at 12:48 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jan 17, 2011 at 12:05 PM, Tom Lane wrote: >>> On Red Hat, it is not packaged at all (at least not by me), and won't >>> be unless it goes into contrib. I don't believe it belongs in the >>> base package. > >> I co

Re: [HACKERS] Moving test_fsync to /contrib?

Bruce Momjian writes: > Robert Haas wrote: >> I confess to some confusion about what things "belong" where. > I was suggesting /contrib because it seems to be of limited usefulness. > I assume people want pg_upgrade to stay in /contrib for the same reason. pg_upgrade is a different issue, reall

Re: [HACKERS] READ ONLY fixes

Jeff Janes wrote: > A review: Thanks! Very thorough! > None of the issues I raise above are severe. Does that mean I > should change the status to "ready for committer"? I see that notion was endorsed by Robert, so I'll leave it alone for now. If a committer asks me to do something about

Re: [HACKERS] Moving test_fsync to /contrib?

Robert Haas writes: > On Mon, Jan 17, 2011 at 12:05 PM, Tom Lane wrote: >> On Red Hat, it is not packaged at all (at least not by me), and won't >> be unless it goes into contrib. I don't believe it belongs in the >> base package. > I confess to some confusion about what things "belong" where.

Re: [HACKERS] Moving test_fsync to /contrib?

Robert Haas wrote: > On Mon, Jan 17, 2011 at 12:05 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Mon, Jan 17, 2011 at 11:47 AM, Bruce Momjian wrote: > >>> It seems like /contrib would be more natural, no? ?/bin seems like > >>> overkill because most people will not want to run it. ?Most of

Re: [HACKERS] Moving test_fsync to /contrib?

Tom Lane wrote: > Robert Haas writes: > > On Mon, Jan 17, 2011 at 11:47 AM, Bruce Momjian wrote: > >> It seems like /contrib would be more natural, no? ?/bin seems like > >> overkill because most people will not want to run it. ?Most of /contrib > >> is installed already by installers, I think. >

Re: [HACKERS] psql: Add \dL to show languages

Peter Eisentraut wrote: > On m?n, 2011-01-17 at 07:37 +0100, Magnus Hagander wrote: > > >> which, as Magnus points out, includes non-procedural languages (SQL). > > >> > > >> I think that "list languages" could be confusing to newcomers -- the > > >> very people who might be reading through the hel

Re: [HACKERS] Streaming base backups

On Mon, Jan 17, 2011 at 11:18, Dimitri Fontaine wrote: > Magnus Hagander writes: >> With pg_basebackup, you can set up streaming replication in what's >> basically a single command (run the base backup, copy i na >> recovery.conf file). In my first version I even had a switch that >> would create

Re: [HACKERS] SSI patch version 12

Anssi Kääriäinen wrote: > I tried to break the version 11 of the patch (some of the work was > against earlier versions). In total I have used a full work day > just trying to break things, but haven't been able to find anything > after version 8. I can verify that the partial index issue is > fi

Re: [HACKERS] walreceiver fallback_application_name

Fujii Masao writes: >>>  http://www.postgresql.org/docs/9.0/interactive/runtime-config-wal.html#GUC-MAX-WAL-SENDERS > > +1 though I could not find the mention to "walreceiver" in the doc. True, we already use "wal sender", I should have said "similar phrasing". Regards, -- Dimitri Fontaine http

Re: [HACKERS] Streaming base backups

Magnus Hagander writes: > With pg_basebackup, you can set up streaming replication in what's > basically a single command (run the base backup, copy i na > recovery.conf file). In my first version I even had a switch that > would create the recovery.conf file for you - should we bring that > back?

Re: [HACKERS] Include WAL in base backup

Magnus Hagander writes: > But however we do it, it will be significantly more complex than just > including the WAL. And I want to make sure we get *something* done in > time for 9.1, and then improve upon it. If we can get the improvement > into 9.1 that's great, but if not it will have to wait u

Re: [HACKERS] REVIEW: Extensions support for pg_dump

Alvaro Herrera writes: > Excerpts from Anssi Kääriäinen's message of lun ene 17 12:41:25 -0300 2011: > >> While it is not possible to drop functions in extensions, it is possible >> to rename a function, and also to CREATE OR REPLACE a function in an >> extension. After renaming or CORing a fun

Re: [HACKERS] REVIEW: Extensions support for pg_dump

Hi, Thanks for your review! Anssi Kääriäinen writes: > Does the patch apply cleanly? > No: That was some bitrot, has been fixed, thanks you for working from the git repository meanwhile. > pg_dump.c:3748: warning: too many arguments for format Fixed in v25 already sent this morning. > And, m

Re: [HACKERS] pg_basebackup for streaming base backups

Magnus Hagander writes: > The walsender can't read pg_class for example, so it can't generate > that mapping file. I don't see any way out here. So let's call .tar good enough for now… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent

Re: [HACKERS] Moving test_fsync to /contrib?

On Mon, Jan 17, 2011 at 12:05 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jan 17, 2011 at 11:47 AM, Bruce Momjian wrote: >>> It seems like /contrib would be more natural, no?  /bin seems like >>> overkill because most people will not want to run it.  Most of /contrib >>> is installed al

Re: [HACKERS] Moving test_fsync to /contrib?

Robert Haas writes: > On Mon, Jan 17, 2011 at 11:47 AM, Bruce Momjian wrote: >> It seems like /contrib would be more natural, no?  /bin seems like >> overkill because most people will not want to run it.  Most of /contrib >> is installed already by installers, I think. > At least on Red Hat, it

Re: [HACKERS] Moving test_fsync to /contrib?

2011/1/17 Bruce Momjian : > Robert Haas wrote: >> On Mon, Jan 17, 2011 at 11:02 AM, Bruce Momjian wrote: >> > Is there value in moving test_fsync to /contrib? >> >> Why would we want to do that? > > If we expect users to run the tool to best choose the best > wal_sync_method. +1 to move it to co

Re: [HACKERS] Moving test_fsync to /contrib?

Excerpts from Bruce Momjian's message of lun ene 17 13:47:40 -0300 2011: > It seems like /contrib would be more natural, no? /bin seems like > overkill because most people will not want to run it. Most of /contrib > is installed already by installers, I think. I don't understand why it would be

Re: [HACKERS] Replication logging

On Mon, Jan 17, 2011 at 17:46, Tom Lane wrote: > Magnus Hagander writes: >> Before I go ahead and commit the part that adds >> log_replication_connections, anybody else want to object to the idea? > > I think it'd make more sense just to say that replication connections > are subject to the same

Re: [HACKERS] Add support for logging the current role

On 01/17/2011 11:44 AM, Alvaro Herrera wrote: Excerpts from Tom Lane's message of sáb ene 15 00:34:40 -0300 2011: Stephen Frost writes: What about something other than version_x_y? I could maybe see having a 'default' and an 'all' instead.. Then have the default be what we have currently a

  1   2   >