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

[Moving to -hackers] On Sat, Feb 23, 2013 at 2:51 PM, Pavel Stehule pavel.steh...@gmail.com wrote: so * --conditional-drops replaced by --if-exists Thanks for the fixes, I played around with the patch a bit. I was sort of expecting this example to work (after setting up the regression

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

On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/3/8 Josh Kupershmidt schmi...@gmail.com: Cool. I think it would also be useful to check that --clean may only be used with --format=p to avoid any confusion there. (This issue could be addressed in a separate

Re: [HACKERS] Add some regression tests for SEQUENCE

On Mon, Mar 18, 2013 at 3:10 PM, Robins Tharakan thara...@gmail.com wrote: Hi, Please find an updated patch (reworked on the names of SEQUENCES / ROLES / SCHEMA etc.) Takes code-coverage of 'make check' for SEQUENCE to ~95%. There is a typo difference between sequence.out and sequence.sql

Re: [HACKERS] Ignore invalid indexes in pg_dump

On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs si...@2ndquadrant.com wrote: On 20 March 2013 02:51, Michael Paquier michael.paqu...@gmail.com wrote: If failures happen with CREATE INDEX CONCURRENTLY, the system will be let with invalid indexes. I don't think that the user would like to see

Re: [HACKERS] pg_dump/restore syntax checking bug?

On Fri, Mar 22, 2013 at 9:35 PM, Joshua D. Drake j...@commandprompt.com wrote: postgres@jd-laptop:~$ pg_restore -d test -P 'by(),hello()' foo.sqlc Note, the pg_restore doc makes no mention of trying to squeeze multiple function prototypes in a single argument you've done here, or of using

Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

On Mon, Sep 27, 2010 at 10:05 PM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: I re-ordered some description in the doc. Does it look better? Comments and suggestions welcome. I thought this paragraph was a little confusing: ! In the second case, a full table scan is followed by a

Re: [HACKERS] ask for review of MERGE

On Wed, Sep 29, 2010 at 2:44 AM, Greg Smith g...@2ndquadrant.com wrote: The rest of the compiler warnings I saw didn't look related to his code, maybe stuff my picky Ubuntu compiler is noticing that was done recently to HEAD. I haven't checked HEAD without this patch yet to confirm, and am

Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

On Wed, Sep 29, 2010 at 11:55 AM, Leonardo Francalanci m_li...@yahoo.it wrote: Can someone else test the patch to see if what I found is still valid? I don't think it makes much sense if I'm the only one that says this is faster :) I ran a few more performance tests on this patch. Here's what

Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

On Fri, Oct 1, 2010 at 4:33 AM, Leonardo Francalanci m_li...@yahoo.it wrote: I ran a few more performance tests on this patch. Here's what  I got for the tests Leonardo posted originally:    * 2M  rows:  22 seconds for seq. scan, 24 seconds for index scan    * 5M  rows:  139 seconds for seq.

Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

On Mon, Oct 4, 2010 at 8:42 AM, Robert Haas robertmh...@gmail.com wrote: Did you also adjust random_page_cost? No, my seq_page_cost (1) and random_page_cost (4) are from the defaults. Here are all my non-default settings: test=# SELECT name, unit, setting FROM pg_settings WHERE source !=

Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

On Mon, Oct 4, 2010 at 4:47 PM, Leonardo Francalanci m_li...@yahoo.it wrote: It sounds like the costing model might need a bit more work before  we commit this. I tried again the simple sql tests I posted a while ago, and I still get the same ratios. I've tested the applied patch on a dual

Re: [HACKERS] [GENERAL] column-level update privs + lock table

[Moving to -hackers] On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs si...@2ndquadrant.com wrote: On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote: On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt schmi...@gmail.com wrote: I noticed that granting a user column-level update privileges

Re: [HACKERS] [GENERAL] column-level update privs + lock table

On Mon, Oct 18, 2010 at 10:27 AM, Robert Haas robertmh...@gmail.com wrote: Please add this to https://commitfest.postgresql.org/action/commitfest_view/open I want to look at this at some point, but we still have over a dozen patches from the current CF to deal with. Added at

[HACKERS] psql autocompletion for \z and \dg

Hi all, It looks like psql's tab completion for the \z and \dg commands in psql are missing. I couldn't see a reason for this, so attached patch fixes. Also, this patch proposes to change psql's \? help text to say that \dg and \du are the same, since AFAICT they do exactly the same thing. Josh

Re: [HACKERS] psql autocompletion for \z and \dg

On Thu, Oct 21, 2010 at 8:45 PM, Robert Haas robertmh...@gmail.com wrote: Please add this in the usual spot: https://commitfest.postgresql.org/action/commitfest_view/open Aye sir, added. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

[HACKERS] psql: Add \dL to show languages

Hi all, I'd like to revive Fernando Ike's patch implementing the \dL command for psql to list available languages, last version here: http://archives.postgresql.org/pgsql-hackers/2009-07/msg01092.php The original patch produced columns Name, Owner, Procedural Language, Trusted, Call Handler,

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

On Sun, Nov 21, 2010 at 8:39 PM, Robert Haas robertmh...@gmail.com wrote: Please add this patch to the currently open CommitFest: Added to 2011-01. https://commitfest.postgresql.org/action/commitfest_view/open And please also help with review of patches from the current CommitFest:

Re: [HACKERS] Tab completion for view triggers in psql

On Fri, Oct 29, 2010 at 10:33 AM, David Fetter da...@fetter.org wrote: That seems like a matter for a separate patch.  Looking this over, I found I'd created a query that can never get used, so please find enclosed the next version of the patch :) I like deletables better than deleteables for

Re: [HACKERS] Tab completion for view triggers in psql

On Tue, Nov 23, 2010 at 10:21 PM, David Fetter da...@fetter.org wrote: Please find attached a patch changing both this and updateable to updatable, also per the very handy git grep I just learned about :) I looked a little more at this patch today. I didn't find any serious problems, though it

Re: [HACKERS] [GENERAL] column-level update privs + lock table

On Fri, Nov 26, 2010 at 7:11 PM, Robert Haas robertmh...@gmail.com wrote: I'm not totally convinced that this is the correct behavior.  It seems a bit surprising that UPDATE privilege on a single column is enough to lock out all SELECT activity from the table.  It's actually a bit surprising

Re: [HACKERS] [GENERAL] column-level update privs + lock table

On Mon, Nov 29, 2010 at 10:50 AM, Robert Haas robertmh...@gmail.com wrote: A user with single-column UPDATE privileges could obtain a ROW EXCLUSIVE lock by issuing an UPDATE statement, but currently cannot obtain the same lock using LOCK TABLE.  It would be reasonable and consistent to allow

Re: [HACKERS] [GENERAL] column-level update privs + lock table

On Mon, Nov 29, 2010 at 10:06 PM, Robert Haas robertmh...@gmail.com wrote: On Mon, Nov 29, 2010 at 9:37 PM, Josh Kupershmidt schmi...@gmail.com wrote: I actually hadn't thought of that, for some reason. We used to similarly recommend that people handle TRUNCATE privileges with a security

Re: [HACKERS] mb_regress.sh gripes

On Thu, Sep 1, 2011 at 9:25 AM, Robert Haas robertmh...@gmail.com wrote: Committed, with some changes.  I used the new --if-exists option for dropdb rather than doing it as you had it here; I assume this may have been the motivation for that patch. Thanks, and that was indeed one reason I

[HACKERS] foreign table: WARNING: problem in alloc set ExecutorState detected write past chunk end in block ...

While trying to test out the EXPLAIN and nfiltered, take two patch with its test file explaintesti, I noticed I was getting a warning message like: WARNING: problem in alloc set ExecutorState: detected write past chunk end in block 0x101134e00, chunk 0x101134f38 I got the same warning on

Re: [HACKERS] foreign table: WARNING: problem in alloc set ExecutorState detected write past chunk end in block ...

On Tue, Sep 13, 2011 at 6:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Kupershmidt schmi...@gmail.com writes: While trying to test out the EXPLAIN and nfiltered, take two patch with its test file explaintesti, I noticed I was getting a warning message like:  WARNING:  problem in alloc set

Re: [HACKERS] foreign table: WARNING: problem in alloc set ExecutorState detected write past chunk end in block ...

On Tue, Sep 13, 2011 at 7:38 PM, Tom Lane t...@sss.pgh.pa.us wrote: Hmm.  I tried on 64-bit Lion (10.7.1) and had no luck. Please try setting a gdb breakpoint on the warning elog (it's in aset.c) and looking to see what's the contents of the complained-of chunk.  That might give us a hint

Re: [HACKERS] psql setenv command

On Thu, Sep 15, 2011 at 10:46 AM, Andrew Dunstan and...@dunslane.net wrote: this time with patch. I think help.c should document the \setenv command. And a link from the Environment section[1] of psql's doc page to the section about \setenv might help too. The existing \set command lists all

Re: [HACKERS] psql setenv command

On Thu, Sep 15, 2011 at 7:02 PM, Andrew Dunstan and...@dunslane.net wrote: On Thu, September 15, 2011 6:10 pm, Josh Kupershmidt wrote: [need way to show current values] \! echo $foo (which is how I tested the patch, of course) Ah, right. IMO it'd be helpful to mention that echo example

Re: [HACKERS] pg_comments (was: Allow \dd to show constraint comments)

On Wed, Oct 12, 2011 at 2:49 PM, Robert Haas robertmh...@gmail.com wrote: So, I think the critical question for this patch is do we want this?. Yep. Or put another way, are the gains worth having another system view we'll have to maintain forever? Tom didn't like it, In [1], Tom seemed to be

Re: [HACKERS] EXECUTE tab completion

On Mon, Sep 26, 2011 at 5:03 PM, Andreas Karlsson andr...@proxel.se wrote: Magnus's patch for adding tab completion of views to the TABLE statement reminded me of a minor annoyance of mine -- that EXECUTE always completes with PROCEDURE as if it would have been part of CREATE TRIGGER ...

Re: [HACKERS] EXECUTE tab completion

On Wed, Oct 19, 2011 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Kupershmidt schmi...@gmail.com writes: Incidentally, I was wondering what the heck was up with a clause like this:     else if (pg_strcasecmp(prev_wd, EXECUTE) == 0              pg_strcasecmp(prev2_wd, EXECUTE) == 0

Re: [HACKERS] EXECUTE tab completion

On Thu, Oct 20, 2011 at 5:16 PM, Andreas Karlsson andr...@proxel.se wrote: A new version is attached. Looks fine. Marking ready for committer (CF 2011-11). Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Show statistics target in \d+

On Fri, Nov 4, 2011 at 10:05 AM, Magnus Hagander mag...@hagander.net wrote: On Fri, Nov 4, 2011 at 14:53, Cédric Villemain Interesting, can the ouput be clear on the value being a default or an explicit stat target ? (not mandatory but I believe I would like to have it only when the stat

[HACKERS] proposal: psql concise mode

Hi all, The good news is that psql's backslash commands are becoming quite thorough at displaying all information which could conceivably be of interest about an object. The bad news is, psql's backslash commands often produce a lot of noise and wasted output. (There was some grumbling along

Re: [HACKERS] proposal: psql concise mode

On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes lis...@guedesoft.net wrote: test=# \d+ foo                         Table public.foo  Column |  Type   | Storage +-+-  a      | integer | plain  b      | integer | plain Has OIDs: no Using your example, what if

Re: [HACKERS] proposal: psql concise mode

On Mon, Nov 7, 2011 at 10:04 PM, Robert Haas robertmh...@gmail.com wrote: I don't strongly object to this, but I wonder how useful it will really be in practice.  It strikes me as the sort of advanced psql hackery that only a few people will use, and only some of those will gain any benefit.

Re: [HACKERS] proposal: psql concise mode

On Mon, Nov 7, 2011 at 11:25 PM, Robert Haas robertmh...@gmail.com wrote: But I can't help feeling that as we continue to add more features, we've eventually going to end up with our backs to the wall.  Not sure what to do about that, but... Seriously, parts of psql are starting to become a

Re: [HACKERS] proposal: psql concise mode

[Sorry for not CC'ing the list before, I'm still getting used to the new Gmail interface] On Tue, Nov 8, 2011 at 11:05 PM, Josh Kupershmidt schmi...@gmail.com wrote: On Tue, Nov 8, 2011 at 10:04 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Kupershmidt schmi...@gmail.com writes: We're

Re: [HACKERS] proposal: psql concise mode

On Thu, Nov 10, 2011 at 3:41 PM, Bruce Momjian br...@momjian.us wrote: Have you tried \d+ with this psql mode:        \pset format wrapped It wraps the data so it fits on the screen --- it is my default in my .psqlrc. I think that's one of the many psql features I haven't experimented with,

Re: [HACKERS] proposal: psql concise mode

On Thu, Nov 10, 2011 at 6:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: As I suggested, many more unexpected failures (e.g. \dnS+) pop up when talking to a 7.3 server. It's not a big deal, but it'd be nice if we could instead error out with a sorry, we're too lazy to try to support 7.3 on the

[HACKERS] fix for psql's \dd version check

Someone (me) didn't get the version check for part of psql's \dd command quite right. I was using a 9.2 client on a 9.1 server and got this when I ran \dd: ERROR: function pg_catalog.pg_opfamily_is_visible(oid) does not exist LINE 33: AND pg_catalog.pg_opfamily_is_visible(opf.oid) since

Re: [HACKERS] proposal: psql concise mode

On Mon, Nov 14, 2011 at 5:16 PM, Ross Reedstrom reeds...@rice.edu wrote: Concise output might look like (bikeshed argument: splat indicates columns squashed out):  test=# \d+ foo                          Table public.foo  Column |  Type   # Storage #  +-+-+  a      

[HACKERS] psql + libedit command history truncation (was: psql history vs. dearmor (pgcrypto))

On Mon, Nov 14, 2011 at 1:01 PM, Robert Haas robertmh...@gmail.com wrote: It looks like the problem is that the original has a blank line after the line that says Version: GnuPG v2.0.17 (GNU/Linux), but when you recall it from the query buffer, that extra blank line gets elided. The attached

[HACKERS] psql \ir filename normalization

Hi all, Commit c7f23494c1103f87bcf1ef7cbfcd626e73edb337 editorialized a bit on Gurjeet Singh's patch to implement \ir for psql, particularly in process_file(). Unfortunately, it looks like it broke the common case of loading a .SQL file in psql's working directory. Consider the following test

[HACKERS] Re: psql + libedit command history truncation (was: psql history vs. dearmor (pgcrypto))

On Mon, Nov 14, 2011 at 7:04 PM, Josh Kupershmidt schmi...@gmail.com wrote: But it reminded me of another issue. With OS X 10.6.8, and otool -L reporting that psql depends on libedit version 2.11.0, the up-arrow recall of Tomas' query gets truncated around here:  5I0/NTm+fFkB0McY9E2fAA [rest

Re: [HACKERS] psql setenv command

On Wed, Nov 2, 2011 at 5:36 PM, Andrew Dunstan and...@dunslane.net wrote: Updated patch is attached - adding to Nov commitfest. Review of the v2 patch: * Submission Review Patch applies with some fuzz and builds without warnings. I noticed some tab characters being used in psql-ref.sgml where

Re: [HACKERS] psql setenv command

On Sat, Nov 26, 2011 at 11:02 AM, Andrew Dunstan and...@dunslane.net wrote: Also, should the malloc() of newval just use pg_malloc() instead? Yes, also done. This bit is unnecessary, since pg_malloc() takes care of the error handling: + if (!newval) +

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

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

[HACKERS] psql: \dg off by one error

Hi all, I noticed an off by one error in psql's verbose-mode display for \dg and \du. In verbose mode, \dg and \du will not display the Replication attribute: test=# \dg rep List of roles Role name | Attributes | Member of ---+-+--- rep |

Re: [HACKERS] pg_terminate_backend and pg_cancel_backend by not administrator user

On Mon, Feb 14, 2011 at 8:58 AM, Anssi Kääriäinen anssi.kaariai...@thl.fi wrote: On 02/14/2011 02:10 PM, Torello Querci wrote: I suppose that give the right to the owner db user to terminate or cancel other session connected to the database which it is owner is a good thing. I not see any

Re: [DOCS] [HACKERS] Uppercase SGML entity declarations

On Mon, Apr 4, 2011 at 3:02 PM, Robert Haas robertmh...@gmail.com wrote:  In theory, we have documentation that explains this: http://www.postgresql.org/docs/current/static/docguide-toolsets.html While we're on the subject.. Attached is a patch against that page suggesting using openjade 1.3,

[HACKERS] Review: psql include file using relative path

I had a chance to give this patch a look. This review is of the second patch posted by Gurjeet, at: http://archives.postgresql.org/message-id/AANLkTi=yjb_a+ggt_pxmrqhbhyid6aswwb8h-lw-k...@mail.gmail.com == Summary == This patch implements the \ir command for psql, with a long alias

[HACKERS] patch: Allow \dd to show constraint comments

Hi all, Attached is a simple patch addressing the TODO item Allow \dd to show constraint comments. If you have comments on various constraints (column, foreign key, primary key, unique, exclusion), they should show up via \dd now. Some example SQL is attached to create two tables with a variety

Re: [HACKERS] patch: Allow \dd to show constraint comments

On Thu, May 19, 2011 at 10:26 AM, Robert Haas robertmh...@gmail.com wrote: At the risk of opening a can of worms, if we're going to fix \dd, shouldn't we fix it completely, and include comments on ALL the object types that can have them?  IIRC it's missing a bunch, not just constraints. You

Re: [HACKERS] Review: psql include file using relative path

On Fri, May 20, 2011 at 2:35 PM, Gurjeet Singh singh.gurj...@gmail.com wrote: On Sat, May 14, 2011 at 5:03 PM, Josh Kupershmidt schmi...@gmail.com wrote: Thanks a lot for the review. My responses are inline below. Thanks for the fixes. Your updated patch is sent as a patch-upon-a-patch, it'll

Re: [HACKERS] patch: Allow \dd to show constraint comments

On Sun, May 22, 2011 at 11:33 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, May 19, 2011 at 10:36 PM, Josh Kupershmidt schmi...@gmail.com wrote: Precisely, and I think there's a solid argument for putting constraints into bucket 1 above, as this patch does, since there's no good room

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

On Fri, Mar 8, 2013 at 11:58 AM, Pavel Stehule pavel.steh...@gmail.com wrote: I'll see - please, stay tuned to 9.4 first commitfest Hi Pavel, Just a reminder, I didn't see this patch in the current commitfest. I would be happy to spend some more time reviewing if you wish to pursue the patch.

[HACKERS] isolationtester and 'specs' subdirectory

Hi all, I have a Debian machine with gcc 4.7.2-5 where make check-world fails in the isolation check, like so: ... make[2]: Leaving directory `/home/josh/src/postgresql/src/test/regress' make -C isolation check [snip] gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith

Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List

On Mon, Jun 24, 2013 at 12:57 PM, Josh Berkus j...@agliodbs.com wrote: Actually, every submitter on that list -- including Maciej -- was sent a personal, private email a week ago. A few (3) chose to take the opportunity to review things, or promised to do so, including a brand new Chinese

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Tue, Jun 18, 2013 at 12:42 PM, Jeff Davis pg...@j-davis.com wrote: Attached a new diff for pg_filedump that makes use of the above change. I'm not sure what the resolution of Alvaro's concern was, so I left the flag reporting the same as the previous patch. This patch is in the current

Re: [HACKERS] fixing pg_ctl with relative paths

On Tue, Jun 25, 2013 at 2:28 AM, Hari Babu haribabu.ko...@huawei.com wrote: Please find the review of the patch. Thank you for reviewing! Code Review: +if (orig_post_opts) { +post_opts = strip_datadirs(orig_post_opts); +} No need of {} as the only one statement block

Re: [HACKERS] fixing pg_ctl with relative paths

On Wed, Jun 26, 2013 at 12:22 PM, Fujii Masao masao.fu...@gmail.com wrote: On Wed, Jun 26, 2013 at 2:36 PM, Hari Babu haribabu.ko...@huawei.com wrote: On June 26, 2013 5:02 AM Josh Kupershmidt wrote: Thanks for the feedback. Attached is a rebased version of the patch with the two small issues

Re: [HACKERS] fixing pg_ctl with relative paths

On Thu, Jun 27, 2013 at 11:47 AM, Fujii Masao masao.fu...@gmail.com wrote: On Thu, Jun 27, 2013 at 10:36 AM, Josh Kupershmidt schmi...@gmail.com wrote: On Wed, Jun 26, 2013 at 12:22 PM, Fujii Masao masao.fu...@gmail.com wrote: Though this is a corner case, the patch doesn't seem to handle

Re: [HACKERS] vacuumlo - use a cursor

On Mon, Nov 12, 2012 at 5:14 PM, Andrew Dunstan and...@dunslane.net wrote: vacuumlo is rather simpleminded about dealing with the list of LOs to be removed - it just fetches them as a straight resultset. For one of my our this resulted in an out of memory condition. Wow, they must have had a

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

On Fri, Jul 5, 2013 at 12:16 PM, Pavel Stehule pavel.steh...@gmail.com wrote: I am sending a patch that removes strict requirements for DROP IF EXISTS statements. This behave is similar to our ALTER IF EXISTS behave now. +1 for this idea. But this patch should be treated as a separate issue

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

On Tue, Jul 2, 2013 at 5:39 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/3/8 Josh Kupershmidt schmi...@gmail.com: On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2013/3/8 Josh Kupershmidt schmi...@gmail.com: Cool. I think it would also be useful

[HACKERS] tab-completion for \lo_import

Hi all, Is there any reason not to tab-complete the local filename used by the \lo_import command? Small patch to do so attached. Josh tab_complete_lo_import.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

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

On Tue, Jul 2, 2013 at 7:47 AM, Pavel Stehule pavel.steh...@gmail.com wrote: Hello remastered patch still there is a issue with dependencies Several of the issues from my last review [1] seem to still be present in this patch, such as review notes #1 and #4. And as discussed previously, I

Re: [HACKERS] pg_restore multiple --function options

On Tue, Aug 27, 2013 at 1:14 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: Assuming no objections, I'll apply the attached patch to 9.3 and master later tonight. Just a little stylistic nitpick: could we pluralize the --help outputs for the modified options so that they make clear that

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

On Thu, Oct 10, 2013 at 12:54 PM, Andrew Dunstan and...@dunslane.net wrote: This thread seems to have gone cold, but I'm inclined to agree with Pavel. If the table doesn't exist, neither does the trigger, and the whole point of the 'IF EXISTS' variants is to provide the ability to issue DROP

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

On Mon, Oct 14, 2013 at 5:38 PM, Josh Kupershmidt schmi...@gmail.com wrote: Also, Pavel, this patch is still listed as 'Needs Review' in the CF app, but I haven't seen a response to the concerns in my last message. It looks like this patch has been imported into the 2013-11 CF [1] and marked

Re: [HACKERS] Odd uuid-ossp behavior on smew and shearwater

On Wed, May 28, 2014 at 11:23 PM, Tom Lane t...@sss.pgh.pa.us wrote: Buildfarm critters smew and shearwater are reporting regression test failures that suggest that the UUID library can't get a system MAC address:

Re: [HACKERS] Odd uuid-ossp behavior on smew and shearwater

On Thu, May 29, 2014 at 4:06 PM, Andrew Dunstan and...@dunslane.net wrote: On 05/29/2014 02:38 PM, Tom Lane wrote: Josh Kupershmidt schmi...@gmail.com writes: Interesting. Looks like you have access only to virtual network interfaces, and they report all-zero MAC addresses, which the UUID

Re: [HACKERS] Proposing pg_hibernate

On Tue, May 27, 2014 at 10:01 PM, Gurjeet Singh gurj...@singh.im wrote: When the Postgres server is being stopped/shut down, the `Buffer Saver` scans the shared-buffers of Postgres, and stores the unique block identifiers of each cached block to the disk. This information is saved under the

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Tue, Feb 9, 2016 at 2:16 PM, Filip Rembiałkowski wrote: > But then it becomes disputable if SQL syntax change makes sense. > > ---we had this, > NOTIFY channel [ , payload ] > ---and in this patch we have this > NOTIFY [ ALL | DISTINCT ] channel [ , payload ] >

<    1   2