Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On Wed, Oct 12, 2016 at 3:30 PM, Haribabu Kommi wrote: > As we are moving to PostgreSQL 10, so are there any plans of backward > compatiblity > breakage, so the existing macaddr datatype itself can be changed to support > both > 48 and 64 bit MAC addresses. Er, I had thought that we should not us

[HACKERS] macaddr 64 bit (EUI-64) datatype support

There was bug that is raised in [1] related to storing EUI-64 mac address in PostgreSQL MAC address datatype. As the current macaddr datatype stores only 48 bit MAC address only, and now a days people are adopting to EUI-64 format of MAC address. So it better to add the support in PostgreSQL. Her

Re: [HACKERS] autonomous transactions

On 11/10/16 21:54, Merlin Moncure wrote: > On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek wrote: >> On 10/10/16 16:44, Merlin Moncure wrote: >>> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote: On 6 October 2016 at 21:27, Robert Haas wrote: > I think we should implement background tra

Re: [HACKERS] How to inspect tuples during execution of a plan?

On Mon, Oct 10, 2016 at 1:39 PM, Ernst-Georg Schmid wrote: > Hello all, > > I'd like to inspect the content of tuples as they are sent during the > execution of a query in order to react to their values. The correct answer will depend upon the purpose of this inspection. You may write a function,

Re: [HACKERS] "Some tests to cover hash_index"

On Wed, Sep 28, 2016 at 9:56 PM, Robert Haas wrote: > something committable will come from it, but with 2 days left it's not > going to happen this CF. Adding a new patch. This one uses generate series instead of INSERT INTO SELECT and fixed comments from Alvaro. -- Thanks and Regards Mithun C Y

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On 2016/10/12 12:21, Haribabu Kommi wrote: On Thu, Sep 29, 2016 at 3:45 PM, Haribabu Kommi mailto:kommi.harib...@gmail.com>> wrote: On Thu, Sep 22, 2016 at 3:05 AM, Alvaro Herrera mailto:alvhe...@2ndquadrant.com>> wrote: Peter Eisentraut wrote: > How about havin

Re: [HACKERS] autonomous transactions

2016-10-11 21:54 GMT+02:00 Merlin Moncure : > On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek > wrote: > > On 10/10/16 16:44, Merlin Moncure wrote: > >> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs > wrote: > >>> On 6 October 2016 at 21:27, Robert Haas wrote: > I think we should implement ba

Re: [HACKERS] Remove "Source Code" column from \df+ ?

2016-10-12 1:51 GMT+02:00 Tom Lane : > Stephen Frost writes: > > As was mentioned, this thread doesn't really need a patch but rather > > some comment from those who have voiced a -1 on removing the PL source > > code column. > > > In another, perhaps vain, attempt to get to a consensus, here's w

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Thu, Sep 29, 2016 at 3:45 PM, Haribabu Kommi wrote: > > > On Thu, Sep 22, 2016 at 3:05 AM, Alvaro Herrera > wrote: > >> Peter Eisentraut wrote: >> >> > How about having the tag not be a column name but a row entry. So you'd >> > do something like >> > >> > SELECT * FROM pg_stat_sql WHERE tag

Re: [HACKERS] DISTINCT with btree skip scan

On Sat, Nov 1, 2014 at 10:35 AM, Thomas Munro wrote: > I am definitely interested in collaborating on a series of patches to > implement various kinds of skip-based plans as seen in other RDBMSs if > others think it could be useful. I see skip-based DISTINCT as a good > place to start. (I suspec

Re: [HACKERS] int2vector and btree indexes

On 2016/10/11 21:40, Tom Lane wrote: > Amit Langote writes: >> I was wrong that the index *never* gets used. It does in fact get used if >> the operator is an ordering search operator (<, <=, >, >=), in which case >> the query would use an array_ops operator (which is a btree operator class >> fo

[HACKERS] buildfarm client release 4.18

I have just released buildfarm client version 4.18. In addition to some minor fixes, there are two significant changes: * The client now makes a determined effort to clean up any left over build artefacts from previous runs at the start of a run. It also tries to clean away old socket

Re: [HACKERS] Remove "Source Code" column from \df+ ?

Stephen Frost writes: > As was mentioned, this thread doesn't really need a patch but rather > some comment from those who have voiced a -1 on removing the PL source > code column. > In another, perhaps vain, attempt to get to a consensus, here's what it > looks like the current standings are for

Re: [HACKERS] [PATCH] pgpassfile connection option

05.10.2016, 20:06, Robert Haas kirjoitti: You could do something like that, I guess, but I think it might be a good idea to wait and see if anyone else has opinions on (1) the desirability of the basic feature, (2) the severity of the security hazard it creates, and (3) your proposed remediation

[HACKERS] Remove "Source Code" column from \df+ ?

All, Starting a new thread with an accurate name to see if we can't get somewhere with this topic. * Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2016-10-08 23:46 GMT+02:00 Jim Nasby : > > On 10/3/16 3:18 PM, Pavel Stehule wrote: > >> I am feeling consensus on removing source of PL from \dt+.

Re: [HACKERS] Macro customizable hashtable / bitmapscan & aggregation perf

On 10/11/2016 05:56 PM, Andres Freund wrote: On 2016-10-11 04:29:31 +0200, Tomas Vondra wrote: On 10/11/2016 04:07 AM, Andres Freund wrote: On 2016-10-10 17:46:22 -0700, Andres Freund wrote: TPC-DS (tpcds.ods) -- In this case, I'd say the results are less convincing. There are

Re: [HACKERS] autonomous transactions

On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek wrote: > On 10/10/16 16:44, Merlin Moncure wrote: >> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote: >>> On 6 October 2016 at 21:27, Robert Haas wrote: I think we should implement background transactions and call them background transac

Re: [HACKERS] Is it time to kill support for very old servers?

I wrote: > pg_dump alleges support for dumping from servers back to 7.0. Would v10 > be a good time to remove some of that code? It's getting harder and > harder to even compile those ancient branches, let alone get people to > test against them (cf. 4806f26f9). My initial thought is to cut supp

Re: [HACKERS] Merge Join with an Index Optimization

On Sun, Sep 11, 2016 at 1:20 PM, Tom Lane wrote: > Michael Malis writes: >> As I understand it, a merge join will currently read all tuples from both >> subqueries (besides early termination). I believe it should be possible to >> take advantages of the indexes on one or both of the tables being

Re: [HACKERS] Is it time to kill support for very old servers?

On 10/11/2016 08:23 PM, Tom Lane wrote: Not sure where to go from here, but the idea of dropping V2 support is seeming attractive again. Or we could just continue the policy of benign neglect. Let's drop it. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Is it time to kill support for very old servers?

Robert Haas writes: > On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane wrote: >> The problem with letting it just sit there is that we're not, in fact, >> testing it. If we take the above argument seriously then we should >> provide some way to configure libpq to prefer V2 and run regression >> tests i

Re: [HACKERS] Macro customizable hashtable / bitmapscan & aggregation perf

On 2016-10-11 04:29:31 +0200, Tomas Vondra wrote: > On 10/11/2016 04:07 AM, Andres Freund wrote: > > On 2016-10-10 17:46:22 -0700, Andres Freund wrote: > > > > TPC-DS (tpcds.ods) > > > > -- > > > > > > > > In this case, I'd say the results are less convincing. There are quite > >

Re: [HACKERS] autonomous transactions

2016-10-11 17:06 GMT+02:00 Petr Jelinek : > On 10/10/16 16:44, Merlin Moncure wrote: > > On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs > wrote: > >> On 6 October 2016 at 21:27, Robert Haas wrote: > >>> I think we should implement background transactions and call them > >>> background transactions.

Re: [HACKERS] autonomous transactions

On 10/10/16 16:44, Merlin Moncure wrote: > On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs wrote: >> On 6 October 2016 at 21:27, Robert Haas wrote: >>> I think we should implement background transactions and call them >>> background transactions. That allows us to expose additional >>> functionality

Re: [HACKERS] int2vector and btree indexes

Amit Langote writes: > I was wrong that the index *never* gets used. It does in fact get used if > the operator is an ordering search operator (<, <=, >, >=), in which case > the query would use an array_ops operator (which is a btree operator class > for type anyarray) and hence matches the inde

[HACKERS] Proposal: scan key push down to heap [WIP]

Hi Hackers, I would like to propose a patch for pushing down the scan key to heap. Currently only in case of system table scan keys are pushed down. I have implemented the POC patch to do the same for normal table scan. This patch will extract the expression from qual and prepare the scan keys.

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Tue, Oct 11, 2016 at 6:08 PM, Michael Paquier wrote: > On Tue, Oct 11, 2016 at 4:18 PM, Masahiko Sawada > wrote: >>> You may want to add an assert in >>> SyncRepGetSyncStandbysPriority and SyncRepGetSyncStandbysQuorum to be >>> sure that they are getting called for the correct method. >>> +

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Tue, Oct 11, 2016 at 4:18 PM, Masahiko Sawada wrote: >> You may want to add an assert in >> SyncRepGetSyncStandbysPriority and SyncRepGetSyncStandbysQuorum to be >> sure that they are getting called for the correct method. >> + /* Sort each array in descending order to get 'pos' newest elemen

Re: [HACKERS] memory leak in e94568ecc10 (pre-reading in external sort)

On 10/11/2016 12:56 AM, Peter Geoghegan wrote: Also, something about trace_sort here: +#ifdef TRACE_SORT + if (trace_sort) + elog(LOG, "using " INT64_FORMAT " KB of memory for read buffers among %d input tapes", +(state->availMem) / 1024, numInputTapes); +#endif + + state

Re: [HACKERS] int2vector and btree indexes

On 2016/10/11 15:58, Amit Langote wrote: > If I create btree index on a int2vector column, it does not get used for > queries because the query search always fails to match the index operator > (family). > > During index creation, GetDefaultOpClass() returns array_ops for a > int2vector index colu

Re: [HACKERS] kqueue

On 28.09.2016 23:39, Thomas Munro wrote: On Thu, Sep 29, 2016 at 9:09 AM, Keith Fiske wrote: On Thu, Sep 15, 2016 at 11:11 PM, Thomas Munro wrote: Ok, here's a version tweaked to use EVFILT_PROC for postmaster death detection instead of the pipe, as Tom Lane suggested in another thread[1]. [

Re: [HACKERS] proposal: schema PL session variables

Hi 2016-02-23 20:52 GMT+01:00 Pavel Stehule : > > > 2016-02-12 22:41 GMT+01:00 Jim Nasby : > >> On 2/12/16 2:58 PM, Pavel Stehule wrote: >> >>> >>> So I think adding something like this needs to at least address >>> *how* SQL level access would work, *when* it's eventually >>> implemented

Re: [HACKERS] proposal: psql \setfileref

2016-10-11 9:32 GMT+02:00 Gilles Darold : > Le 11/10/2016 à 07:53, Pavel Stehule a écrit : > > > > 2016-10-10 19:50 GMT+02:00 Pavel Stehule : > >> >> >> 2016-10-10 15:17 GMT+02:00 Gilles Darold : >> >>> Le 10/10/2016 à 14:38, Daniel Verite a écrit : >>> > Gilles Darold wrote: >>> > >>> >>

Re: [HACKERS] proposal: psql \setfileref

Le 11/10/2016 à 07:53, Pavel Stehule a écrit : > > > 2016-10-10 19:50 GMT+02:00 Pavel Stehule >: > > > > 2016-10-10 15:17 GMT+02:00 Gilles Darold >: > > Le 10/10/2016 à 14:38, Daniel Verite a écrit : > >

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Wed, Sep 28, 2016 at 5:14 PM, Michael Paquier wrote: > On Sat, Sep 24, 2016 at 5:37 PM, Masahiko Sawada > wrote: >> I still vote for changing behaviour of existing syntax 'k (n1, n2)' to >> quorum commit. >> That is, >> 1. 'First k (n1, n2, n3)' means that the master server waits for ACKs >>