[HACKERS] patch: enhanced DROP POLICY tab complete

Hi I am sending trivial patch, that enforce more precious tab complete for DROP POLICY statement Regards Pavel diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c new file mode 100644 index 0683548..9596af6 *** a/src/bin/psql/tab-complete.c --- b/src/bin/psql/tab-complete.c **

Re: [HACKERS] Memory Accounting v11

On Fri, 2015-07-17 at 15:52 +1200, David Rowley wrote: > Should we mark the patch as "returned with feedback" in the commitfest > app then? I believe the memory accounting patch has been rejected. Instead, the work will be done in the HashAgg patch. Thank you for the review! Regards, Je

Re: [HACKERS] Further issues with jsonb semantics, documentation

On Fri, Jul 17, 2015 at 6:20 PM, Andrew Dunstan wrote: > OK, I have committed this and updated the open issues list on the wiki. Thanks, Andrew. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgres

Re: [HACKERS] Further issues with jsonb semantics, documentation

On 07/17/2015 02:49 PM, Andrew Dunstan wrote: On 07/17/2015 02:37 PM, Robert Haas wrote: On Thu, Jul 9, 2015 at 10:49 AM, Andrew Dunstan wrote: Where are we on this? This is currently a 9.5 release blocker. I am on vacation right now, but I might have some time tomorrow to deal with it. If

Re: [HACKERS] pg_resetsysid

On 6/14/15 11:29 AM, Petr Jelinek wrote: > 0002 - Adds pg_resetsysid utility which changes the system id to newly > generated one. > > 0003 - Adds -s option to pg_resetxlog to change the system id to the one > specified - this is separate from the other one as it can be potentially > more dangerou

[HACKERS] BRIN index and aborted transaction

Forgive me if this has been already discussed somewhere. When a transaction aborts, it seems a BRIN index leaves summary data which is not valid any more. Is this an expected behavior? I guess the answer is yes, because it does not affect correctness of a query result, but I would like to make su

Re: [HACKERS] Support retrieving value from any sequence

On 7/14/15 12:06 PM, Tom Lane wrote: Thom Brown writes: On 14 July 2015 at 17:17, Robert Haas wrote: Since it's trivial to define this function if you need it, I'm not sure there's a reason to include it in core. It's not always possible to create functions on a system when access is restr

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 7/16/15 12:40 PM, Robert Haas wrote: >They may well be 2-3 times as long. Why is that a negative? In my opinion, brevity makes things easier to read and understand. We also don't support multi-line GUCs, so if your configuration takes 140 characters, you're going to have a very long line in

Re: [HACKERS] WAL test/verification tool

Thomas Munro wrote: > Hi > > I have heard rumours of a tool that could verify or compare the > effects of applying WAL records for testing/development purposes, but > I've been unable to track it down or find out if it was publicly > released. Does anyone know the status of that or what it was ca

[HACKERS] WAL test/verification tool

Hi I have heard rumours of a tool that could verify or compare the effects of applying WAL records for testing/development purposes, but I've been unable to track it down or find out if it was publicly released. Does anyone know the status of that or what it was called? Thanks, -- Thomas Munro

Re: [HACKERS] creating extension including dependencies

On 2015-07-15 06:07, Michael Paquier wrote: On Fri, Jul 10, 2015 at 11:28 PM, Tom Lane wrote: Andres Freund writes: On July 10, 2015 4:16:59 PM GMT+02:00, Tom Lane wrote: Would that propagate down through multiple levels of CASCADE? (Although I'm not sure it would be sensible for a non-rel

[HACKERS] Corner-case logic problem in WaitLatchOrSocket

Terry Chong of Salesforce pointed me at an apparent oversight in the Unix version of WaitLatchOrSocket. Assuming that it is called with a timeout specification, the only place where we detect timeout is if poll() (or select()) returns 0. Now suppose that for some reason we have gotten into a stat

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

On Fri, 17 Jul 2015 at 23:14 Robert Haas wrote: > Committed. I changed one remaining use of "proportion" to "fraction", > fixed an OID conflict, and reverted some unnecessary whitespace > changes. > Thanks Robert. Sorry I missed a "proportion" in my latest version, and thanks for catching it.

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 7/15/15 11:38 PM, Thakur, Sameer wrote: Hello, I am not really willing to show up as the picky guy here, but could it be possible to receive those patches as attached to emails instead of having them referenced by URL? I >imagine that you are directly using the nabble interface. Just confi

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 8, 2015 at 12:21 PM, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/08/2015 08:51 AM, Corey Huinker wrote: > > Questions: Would moving rowtype to the first parameter resolve the > > parameter ambiguity issue? > > Not for the existing functions but with n

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

Hello Tom, (although actually, why wouldn't we want to just implement variable substitution exactly like it is in psql? Pgbench variable substitution is performed when the script is run, not while the file is being processed for being split, which is when a lexer would be used. The situatio

Re: [HACKERS] Grouping Sets: Fix unrecognized node type bug

> "Kyotaro" == Kyotaro HORIGUCHI writes: Kyotaro> Hello, this looks to be a kind of thinko. The attached patch Kyotaro> fixes it. No, that's still wrong. Just knowing that there is a List is not enough to tell whether to concat it or append it. Jeevan's original patch tries to get around

Re: [HACKERS] 9.6 First Commitfest Begins

The third week of the July commitfest is now past us. There are 35 patches left in Needs Review state. Progress has slowed somewhat, which is understandable, as the trivial patches often get weeded out first. But we need to make progress on the bigger patches too to complete this. If you see a

Re: [HACKERS] Further issues with jsonb semantics, documentation

On 07/17/2015 02:37 PM, Robert Haas wrote: On Thu, Jul 9, 2015 at 10:49 AM, Andrew Dunstan wrote: Where are we on this? This is currently a 9.5 release blocker. I am on vacation right now, but I might have some time tomorrow to deal with it. If not, it will be Sunday or Monday when I get to i

Re: [HACKERS] Further issues with jsonb semantics, documentation

On Fri, Jul 17, 2015 at 11:37 AM, Robert Haas wrote: >> I am on vacation right now, but I might have some time tomorrow to deal with >> it. If not, it will be Sunday or Monday when I get to it. > > Is this still pending? Yes. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-

[HACKERS] Re: [COMMITTERS] pgsql: Retain comments on indexes and constraints at ALTER TABLE ... TY

On 07/17/2015 05:40 PM, Michael Paquier wrote: On Fri, Jul 17, 2015 at 11:16 PM, Kevin Grittner wrote: Heikki Linnakangas wrote: This fixes bug #13126, reported by Kirill Simonov. It looks like you missed something with the addition of AT_ReAddComment: test_ddl_deparse.c:80:11: warning: e

Re: [HACKERS] Further issues with jsonb semantics, documentation

On Thu, Jul 9, 2015 at 10:49 AM, Andrew Dunstan wrote: >> Where are we on this? This is currently a 9.5 release blocker. > > I am on vacation right now, but I might have some time tomorrow to deal with > it. If not, it will be Sunday or Monday when I get to it. Is this still pending? -- Robert

Re: [HACKERS] Asynchronous execution on FDW

On Fri, Jul 3, 2015 at 4:41 PM, Heikki Linnakangas wrote: > At a quick glance, I think this has all the same problems as starting the > execution at ExecInit phase. The correct way to do this is to kick off the > queries in the first IterateForeignScan() call. You said that "ExecProc > phase does

Re: [HACKERS] GSets: Getting collation related error when GSets has text column

> "Jeevan" == Jeevan Chalke writes: Jeevan> Hi, Jeevan> When we have text column in the GROUPING SETS (and with some specific Jeevan> order of columns), we are getting error saying Jeevan> "could not determine which collation to use for string comparison" Good catch. Jeevan> After spe

Re: [HACKERS] option for psql - short list non template database

2015-07-17 18:56 GMT+02:00 Robert Haas : > On Thu, Jul 16, 2015 at 12:21 AM, Pavel Stehule > wrote: > > terrible often I use pattern > > > > psql -c "select datname from pg_database where not datistemplate and > > datallowconn" postgres > > > > What about introduction new long option that does i

Re: [HACKERS] option for psql - short list non template database

On Thu, Jul 16, 2015 at 12:21 AM, Pavel Stehule wrote: > terrible often I use pattern > > psql -c "select datname from pg_database where not datistemplate and > datallowconn" postgres > > What about introduction new long option that does it? > > psql -At -list --names --without-templates I think

Re: [HACKERS] Retrieve the snapshot's LSN

On Fri, Jul 17, 2015 at 8:31 AM, Florent Guiliani wrote: > A pg_export_snapshot_for_slot(...) would work very well. > > Let me explain the use case. You have many downstream systems that are > replicated with logical decoding. Using a dedicated replication slot > for each target is not practical.

Re: [HACKERS] Transactions involving multiple postgres foreign servers

Overall, you seem to have made some significant progress on the design since the last version of this patch. There's probably a lot left to do, but the design seems more mature now. I haven't read the code, but here are some comments based on the email. On Thu, Jul 9, 2015 at 6:18 AM, Ashutosh B

Re: [HACKERS] [PATCH] Generalized JSON output functions

On 07/17/2015 10:30 AM, Alvaro Herrera wrote: Andrew Dunstan wrote: I have already pointed out how this patch is fundamentally broken. You can achieve your aims by a fairly small amount of code inside your logical decoder, and with no core code changes whatsoever. So I'm puzzled why we are eve

Re: [HACKERS] [PATCH] Generalized JSON output functions

Shulgin, Oleksandr wrote: > On Jul 17, 2015 4:31 PM, "Andrew Dunstan" wrote: > > Incidentally, this doesn't look acceptable anyway: > >> > >> ! es->json_cxt.value(&es->json_cxt, num, JSONTYPE_NUMERIC, > >> ! NUMERICOID, 1702 /* numeric_out */); > > > > We don't hardcode function oids elsewhere.

Re: [HACKERS] TABLESAMPLE patch is really in pretty sad shape

On 2015-07-16 17:08, Tom Lane wrote: Petr Jelinek writes: On 2015-07-16 15:59, Tom Lane wrote: I'm not clear on whether sequence AMs would need explicit catalog representation, or could be folded down to just a single SQL function with special signature as I suggested for tablesample handlers.

Re: [HACKERS] [PATCH] Generalized JSON output functions

Andrew Dunstan wrote: > I have already pointed out how this patch is fundamentally broken. You can > achieve your aims by a fairly small amount of code inside your logical > decoder, and with no core code changes whatsoever. So I'm puzzled why we are > even still debating this broken design. I we

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Fri, Jul 17, 2015 at 6:05 AM, Tom Lane wrote: > Peter Geoghegan writes: > > I've heard that clock_gettime() with CLOCK_REALTIME_COARSE, or with > > CLOCK_MONOTONIC_COARSE can have significantly lower overhead than > > gettimeofday(). > > It can, but it also has *much* lower precision, typical

Re: [HACKERS] proposal: multiple psql option -c

> On Thu, Jul 16, 2015 at 12:42 PM, Pavel Stehule > wrote: > Hi > can we support multiple "-c" option? > Why? Because some statements like VACUUM cannot be used together with any > other statements with single -c option. The current solution is using echo > and pipe op, but it is a complication

Re: [HACKERS] [PATCH] Generalized JSON output functions

On Jul 17, 2015 4:31 PM, "Andrew Dunstan" wrote: > > > On 07/17/2015 10:11 AM, Andrew Dunstan wrote: >> >> >> On 07/17/2015 08:20 AM, Shulgin, Oleksandr wrote: >> >> >>> > This patch makes Postgres core more complex >>> >>> Yes, it does. But, that was not the purpose, obviously. :-) >>> >>> > whil

[HACKERS] Re: [COMMITTERS] pgsql: Retain comments on indexes and constraints at ALTER TABLE ... TY

On Fri, Jul 17, 2015 at 11:16 PM, Kevin Grittner wrote: > Heikki Linnakangas wrote: > >> This fixes bug #13126, reported by Kirill Simonov. > > It looks like you missed something with the addition of > AT_ReAddComment: > > test_ddl_deparse.c:80:11: warning: enumeration value 'AT_ReAddComment' not

Re: [HACKERS] segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function

Geoff Winkless writes: > While doing some testing of 9.5a one of my colleagues (not on list) found a > reproducible server segfault. Hm, looks like commit 1345cc67bbb014209714af32b5681b1e11eaf964 is to blame: memory management for the plpgsql cast cache needs to be more complicated than I realize

Re: [HACKERS] [PATCH] Generalized JSON output functions

On 07/17/2015 10:11 AM, Andrew Dunstan wrote: On 07/17/2015 08:20 AM, Shulgin, Oleksandr wrote: > This patch makes Postgres core more complex Yes, it does. But, that was not the purpose, obviously. :-) > while not really solving the problem in Javascript. It still allows for less risk of

[HACKERS] Re: [COMMITTERS] pgsql: Retain comments on indexes and constraints at ALTER TABLE ... TY

Heikki Linnakangas wrote: > This fixes bug #13126, reported by Kirill Simonov. It looks like you missed something with the addition of AT_ReAddComment: test_ddl_deparse.c:80:11: warning: enumeration value 'AT_ReAddComment' not handled in switch [-Wswitch] switch (subcmd->subtyp

Re: [HACKERS] [PATCH] Generalized JSON output functions

On 07/17/2015 08:20 AM, Shulgin, Oleksandr wrote: > This patch makes Postgres core more complex Yes, it does. But, that was not the purpose, obviously. :-) > while not really solving the problem in Javascript. It still allows for less risk of silent data corruption on the js side. I hav

[HACKERS] pgbench stats per script & other stuff

This patch adds per-script statistics & other improvements to pgbench Rationale: Josh asked for the per-script stats:-) Some restructuring is done so that all stats (-l --aggregate-interval --progress --per-script-stats, latency & lag...) share the same structures and functions to accumulate

[HACKERS] GSets: Getting collation related error when GSets has text column

Hi, When we have text column in the GROUPING SETS (and with some specific order of columns), we are getting error saying "could not determine which collation to use for string comparison" Here is the example: postgres=# select sum(ten) from onek group by rollup(four::text), two order by 1; ERROR

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

On Fri, Jul 17, 2015 at 4:23 AM, Brendan Jurd wrote: > On Thu, 16 Jul 2015 at 08:37 Gurjeet Singh wrote: >> OK. Please send a new patch with the changes you agree to, and I can mark >> it ready for committer. > > Done. Please find attached patch v3. I have changed "proportion" to > "fraction",

Re: [HACKERS] segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function

On 17 July 2015 at 13:49, Michael Paquier wrote: > On Fri, Jul 17, 2015 at 7:52 PM, Geoff Winkless > wrote: > > While doing some testing of 9.5a one of my colleagues (not on list) > found a > > reproducible server segfault. > > [...] > > Hope someone can get something useful from the above. Any

Re: [HACKERS] [PATCH] postgres_fdw extension support

On July 17, 2015 at 5:57:42 AM, Simon Riggs (si...@2ndquadrant.com(mailto:si...@2ndquadrant.com)) wrote: > Options already exist on CREATE FOREIGN DATA WRAPPER, so it should be easy to > support that. > > I'd rather add it once on the wrapper than be forced to list all the options > on every

Re: [HACKERS] [PATCH] postgres_fdw extension support

On 17 July 2015 at 13:51, Paul Ramsey wrote: > There’s no facility to add OPTIONS to an EXTENSION right now, so this > capability seems to be very much server-by-server (adding a FDW-specific > capability to the EXTENSION mechanism seems like overkill for a niche > feature addition). > Options

Re: [HACKERS] [PATCH] postgres_fdw extension support

  On July 17, 2015 at 12:49:04 AM, Simon Riggs (si...@2ndquadrant.com(mailto:si...@2ndquadrant.com)) wrote: > On 17 July 2015 at 01:23, Michael Paquier wrote: > > > > Well, as I see it there’s three broad categories of behavior available: > > > > > > 1- Forward nothing non-built-in (current beha

Re: [HACKERS] segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function

On Fri, Jul 17, 2015 at 7:52 PM, Geoff Winkless wrote: > While doing some testing of 9.5a one of my colleagues (not on list) found a > reproducible server segfault. > [...] > Hope someone can get something useful from the above. Any questions, please > ask. A test case is more than enough to look

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

On Fri, Jul 17, 2015 at 4:23 AM, Brendan Jurd wrote: > On Thu, 16 Jul 2015 at 08:37 Gurjeet Singh wrote: >> OK. Please send a new patch with the changes you agree to, and I can mark >> it ready for committer. > > Done. Please find attached patch v3. I have changed "proportion" to > "fraction",

Re: [HACKERS] Retrieve the snapshot's LSN

On Thu, Jul 16, 2015 at 7:13 PM, Andres Freund wrote: > On 2015-07-16 13:08:48 -0400, Robert Haas wrote: >> On Thu, Jul 16, 2015 at 12:54 PM, Andres Freund wrote: >> > Well, in combination with logical decoding it kinda has one: It should >> > allow you to take a dump of the database with a certa

Re: [HACKERS] [PATCH] Generalized JSON output functions

On Jul 17, 2015 12:23 AM, "Ryan Pedela" wrote: > > On Thu, Jul 16, 2015 at 11:51 AM, Robert Haas wrote: >> >> I don't understand these issues in great technical depth, but if >> somebody is arguing that it's OK for PostgreSQL to be difficult to use >> for a certain category of user for several ye

Re: [HACKERS] Retrieve the snapshot's LSN

On Fri, Jul 17, 2015 at 4:16 AM, Florent Guiliani wrote: >> but such an LSN need not exist. Suppose A writes a commit record at >> LSN 0/1, and then B writes a commit record at 0/10100, and then B >> calls ProcArrayEndTransaction(). At this point, B is visible and A is >> not visible, even t

[HACKERS] segfault in 9.5alpha - plpgsql function, implicit cast and IMMUTABLE cast function

Hi all While doing some testing of 9.5a one of my colleagues (not on list) found a reproducible server segfault. We've broken it down to a minimal script to reproduce below. Reproduced on both machines on which we've installed 9.5 so far (both built from source since we don't have any RHEL7 mach

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

On Thu, 16 Jul 2015 at 08:37 Gurjeet Singh wrote: > OK. Please send a new patch with the changes you agree to, and I can mark > it ready for committer. > Done. Please find attached patch v3. I have changed "proportion" to "fraction", and made other wording improvements per your suggestions. C

Re: [HACKERS] Retrieve the snapshot's LSN

On Thu, Jul 16, 2015 at 6:40 PM, Robert Haas wrote: > I don't think "the snapshot's LSN" has a well-defined meaning in > general. The obvious meaning would be "the LSN such that all commits > prior to that LSN are visible and all later commits are invisible", I like this definition. > but such

Re: [HACKERS] Grouping Sets: Fix unrecognized node type bug

Hello, this looks to be a kind of thinko. The attached patch fixes it. === According to the comment of transformGroupingSet, it assumes that the given GROUPING SETS node is already flatted out and flatten_grouping_sets() does that. The details of the transformation is described in the comment for

Re: [HACKERS] Parallel Seq Scan

On Thu, Jul 16, 2015 at 1:10 PM, Amit Kapila wrote: > Thanks, I will fix this in next version of patch. > I am posting in this thread as I am not sure, whether it needs a separate thread or not? I gone through the code and found that the newly added funnel node is is tightly coupled with partial

Re: [HACKERS] [PATCH] postgres_fdw extension support

On 17 July 2015 at 01:23, Michael Paquier wrote: > > Well, as I see it there’s three broad categories of behavior available: > > > > 1- Forward nothing non-built-in (current behavior) > > 2- Use options to forward only specified non-built-in things (either in > > function chunks (extensions, as

Re: [HACKERS] Support for N synchronous standby servers - take 2

Robert Haas wrote: > > On Thu, Jul 16, 2015 at 1:32 PM, Simon Riggs wrote: > >> Personally, I think we're going to find that using JSON for this > >> rather than a custom syntax makes the configuration strings two or > >> three times as long for > > > > They may well be 2-3 times as long.