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

On Tue, Oct 11, 2016 at 4:18 PM, Masahiko Sawada wrote: > 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

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 10/15/2016 04:26 PM, Michael Paquier wrote: * Now that we don't call random() in postmaster anymore, is there any point in calling srandom() there (i.e. where the above incorrect comment was)? Should we remove it? random() might be used by pre-loaded extensions, though. (Hopefully not for

Re: [HACKERS] Gather Merge

On Wed, Oct 5, 2016 at 11:35 AM, Rushabh Lathia wrote: > Hi hackers, > > Attached is the patch to implement Gather Merge. > Couple of review comments: 1. ExecGatherMerge() { .. + /* No workers? Then never mind. */ + if (!got_any_worker || + node->nreaders < 2) + { +

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 10/17/2016 12:18 PM, Michael Paquier wrote: You removed the part of pgcrypto in charge of randomness, nice move. I was wondering about how to do with the perfc and the unix_std at some point, and ripping them off as you did is fine for me. Yeah. I didn't understand the need for the perfc

Re: [HACKERS] FSM corruption leading to errors

On Mon, Oct 17, 2016 at 4:14 PM, Pavan Deolasee wrote: > I think this is a major bug and I would appreciate any ideas to get the > patch in a committable shape before the next minor release goes out. We > probably need a committer to get interested in this to make

Re: [HACKERS] Mention column name in error messages

On Thu, Oct 6, 2016 at 2:58 PM, Franck Verrot wrote: > Michael, please find attached a revised patch addressing, amongst some other > changes, the testing issue (`make check` passes now) and the visibility of > the ` TransformExprState` struct. + /* Set up callback to

Re: [HACKERS] FSM corruption leading to errors

On Tue, Oct 11, 2016 at 5:20 AM, Michael Paquier wrote: > > > > > Once the underlying bug is fixed, I don't see why it should break again. > I > > added the above code to mostly deal with already corrupt FSMs. May be we > can > > just document and leave it to the user

Re: [HACKERS] Optimization for lazy_scan_heap

On Mon, Oct 3, 2016 at 10:59 AM, Michael Paquier wrote: > On Mon, Sep 26, 2016 at 5:26 AM, Rahila Syed wrote: >> Some initial comments on optimize_lazy_scan_heap_v2.patch. > > Seems worth pursuing. Marking as returned with feedback because of >

Re: [HACKERS] postgres_fdw super user checks

On Mon, Oct 17, 2016 at 11:48 AM, Michael Paquier wrote: > On Mon, Oct 17, 2016 at 3:33 AM, Jeff Janes wrote: >> postgres_fdw has some checks to enforce that non-superusers must connect to >> the foreign server with a password-based method. The

Re: [HACKERS] postgres_fdw super user checks

On Mon, Oct 17, 2016 at 12:03 AM, Jeff Janes wrote: > postgres_fdw has some checks to enforce that non-superusers must connect to > the foreign server with a password-based method. The reason for this is to > prevent the authentication to the foreign server from happening

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Thu, Oct 13, 2016 at 7:37 PM, Ashutosh Bapat wrote: >>> >>> If we are successful in COMMITTING foreign transactions during >>> post-commit phase, COMMIT message will be returned after we have >>> committed all foreign transactions. But in case we can not reach

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Mon, Oct 17, 2016 at 5:55 PM, Heikki Linnakangas wrote: > On 10/15/2016 04:26 PM, Michael Paquier wrote: >>> >>> * Now that we don't call random() in postmaster anymore, is there any >>> point >>> in calling srandom() there (i.e. where the above incorrect comment was)? >>>

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Robert Haas wrote: Yeah, I don't know. For my money, decorating the function definitions in place seems easier than having to maintain a separate export list, especially if it can be hidden under the carpet using the existing stupid macro tricks. But I am not a Windows expert. I suppose we

Re: [HACKERS] [ADMIN] 9.5 new setting "cluster name" and logging

* Thomas Munro (thomas.mu...@enterprisedb.com) wrote: > On Tue, Feb 9, 2016 at 3:24 AM, Andres Freund wrote: > > (x-posting to -hackers, more relevant audience) > > > > On 2016-01-29 22:19:45 -0800, Evan Rempel wrote: > >> Now that there is a setting to give a cluster a

Re: [HACKERS] postgres_fdw super user checks

On Mon, Oct 17, 2016 at 10:51 PM, Robert Haas wrote: > On Mon, Oct 17, 2016 at 2:18 AM, Michael Paquier > wrote: >> On Mon, Oct 17, 2016 at 3:33 AM, Jeff Janes wrote: >>> postgres_fdw has some checks to enforce that

Re: [HACKERS] emergency outage requiring database restart

On Tue, Oct 18, 2016 at 4:21 AM, Alvaro Herrera wrote: > Merlin Moncure wrote: > >> We had several good backups since the previous outage so it's not >> clear the events are related but after months of smooth operation I >> find that coincidence highly suspicious. As

Re: [HACKERS] asynchronous execution

Hello, this works but ExecAppend gets a bit degradation. At Mon, 03 Oct 2016 19:46:32 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20161003.194632.204401048.horiguchi.kyot...@lab.ntt.co.jp> > > Some notes: > > > > - EvalPlanQual rechecks are

Re: [HACKERS] emergency outage requiring database restart

On 18/10/16 14:12, Michael Paquier wrote: On Tue, Oct 18, 2016 at 4:21 AM, Alvaro Herrera wrote: Merlin Moncure wrote: We had several good backups since the previous outage so it's not clear the events are related but after months of smooth operation I find that

Re: [HACKERS] Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

On Tue, Oct 18, 2016 at 5:35 AM, Tom Lane wrote: > If we want it to fail, and don't want to retire pademelon, there are > multiple ways we could get to that goal: > > * Enable --with-openssl in pademelon's build (don't really want to do > this, since I believe almost all the

Re: [HACKERS] Idempotency for all DDL statements

On 10/17/16 2:05 PM, Kenaniah Cerny wrote: > Could I request DDL idempotency as an addition to the development roadmap? There is not really a roadmap, but I think there is general interest in this. If you want to make it happen faster, however, you will need to start coding it yourself. --

Re: [HACKERS] FSM corruption leading to errors

On Mon, Oct 17, 2016 at 8:04 PM, Heikki Linnakangas wrote: > visibilitymap_truncate is actually also wrong, in a different way. The > truncation WAL record is written only after the VM (and FSM) are truncated. > But visibilitymap_truncate() has already modified and dirtied the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

Michael Paquier writes: > And actually, enabling prngd would need to be controlled by a > configure switch as well disabled by default, no? AFAICT, openssl has no configuration options related to prngd; they seem to be able to use it automatically when /dev/[u]random

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

On 18 October 2016 at 04:11, Tom Lane wrote: > As for the core problem, I wonder why we aren't recommending that > third-party modules be built using the same infrastructure contrib > uses, rather than people ginning up their own infrastructure and > then finding out the hard

Re: [HACKERS] FSM corruption leading to errors

On Mon, Oct 17, 2016 at 4:34 PM, Heikki Linnakangas wrote: > >> > visibilitymap_truncate is actually also wrong, in a different way. The > truncation WAL record is written only after the VM (and FSM) are truncated. > But visibilitymap_truncate() has already modified and dirtied

Re: [HACKERS] Idempotency for all DDL statements

On 18 October 2016 at 10:26, Peter Eisentraut wrote: > On 10/17/16 2:05 PM, Kenaniah Cerny wrote: >> Could I request DDL idempotency as an addition to the development roadmap? > > There is not really a roadmap, but I think there is general interest in > this. If

Re: [HACKERS] Parallel Index Scans

On Thu, Oct 13, 2016 at 8:48 AM, Amit Kapila wrote: > As of now, the driving table for parallel query is accessed by > parallel sequential scan which limits its usage to a certain degree. > Parallelising index scans would further increase the usage of parallel > query in

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

On 18 October 2016 at 04:19, Andres Freund wrote: > On 2016-10-17 16:16:37 -0400, Robert Haas wrote: >> I wouldn't think that cross-file references would be especially >> common. Functions that take PG_FUNCTION_ARGS and return Datum aren't >> a lot of fun to call from C. But

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-18 5:48 GMT+02:00 Craig Ringer : > On 18 October 2016 at 04:19, Andres Freund wrote: > > On 2016-10-17 16:16:37 -0400, Robert Haas wrote: > >> I wouldn't think that cross-file references would be especially > >> common. Functions that take

Re: [HACKERS] Illegal SJIS mapping

Hello, At Fri, 7 Oct 2016 23:58:45 +0300, Heikki Linnakangas wrote in <9c544547-7214-aebe-9b04-57624aedd...@iki.fi> > > So, I wonder how the mappings related to SJIS (and/or EUC-JP) are > > maintained. If no authoritative information is available, the > > generating script no

Re: [HACKERS] Illegal SJIS mapping

> However, running the script with that doesn't produce exactly what we > have in utf8_to_sjis.map, either. It's otherwise same, but we have > some extra mappings: > > - {0xc2a5, 0x5c}, 0xc2a5 is U+00a5. The glyph is "YEN SIGN" which is corresponding to 0x5c in SJIS. So this is a valid mapping.

Re: [HACKERS] emergency outage requiring database restart

On Thu, Oct 13, 2016 at 4:13 PM, Tom Lane wrote: > Merlin Moncure writes: >> Today I had an emergency production outage on a server. >> ... >> Adding all this up it smells like processes were getting stuck on a spinlock. > > Maybe. If it happens again,

[HACKERS] Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

On 10/17/2016 06:21 PM, Tom Lane wrote: Heikki Linnakangas writes: On 10/17/2016 05:50 PM, Tom Lane wrote: The real issue here is whether we are willing to say that Postgres simply does not work anymore on machines without standard entropy sources. Doesn't matter whether the

Re: [HACKERS] COPY as a set returning function

On Sun, Oct 16, 2016 at 9:01 AM, Craig Ringer wrote: > On 15 Oct. 2016 04:56, "Corey Huinker" wrote: > > > I would like to make COPY itself a SRF. That's a bit beyond my > capabilities, so if that is the route we want to go, I will need

Re: [HACKERS] COPY as a set returning function

On Fri, Sep 30, 2016 at 9:56 PM, Tom Lane wrote: > Craig Ringer writes: >> On 1 Oct. 2016 05:20, "Tom Lane" wrote: >>> I think the last of those suggestions has come up before. It has the >>> large advantage that you don't

Re: [HACKERS] [PATCH] Better logging of COPY queries if log_statement='all'

Aleksander Alekseev wrote: > According to my colleagues it would be very nice to have this feature. > For instance, if you are trying to optimize PostgreSQL for application > that uses COPY and you don't have access to or something like this. > It could also be useful in some other

Re: [HACKERS] emergency outage requiring database restart

On Mon, Oct 17, 2016 at 1:39 PM, Merlin Moncure wrote: > On Thu, Oct 13, 2016 at 4:13 PM, Tom Lane wrote: >> Merlin Moncure writes: >>> Today I had an emergency production outage on a server. >>> ... >>> Adding all this up it smells

Re: [HACKERS] [ADMIN] 9.5 new setting "cluster name" and logging

On Tue, Feb 9, 2016 at 3:24 AM, Andres Freund wrote: > Hi, > > (x-posting to -hackers, more relevant audience) > > On 2016-01-29 22:19:45 -0800, Evan Rempel wrote: >> Now that there is a setting to give a cluster a "name", it would be nice to >> have an escape sequence in the

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

17 октября 2016 г. 23:42:30 MSK, Tom Lane wrote: [ wanders away wondering what cmake does with this... ] CMake can export all symbols using only one setting - WINDOWS_EXPORT_ALL_SYMBOLS for shared libraries and special for Postgres I made "export all" for executable files. You can try this

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, Oct 17, 2016 at 5:36 AM, Amit Kapila wrote: > Okay, but what is the proof or why do you think second is going to > better than first? I don't have proof. It's my opinion that it probably would be, based on partial information, and my intuition. It's hard to prove

Re: [HACKERS] postgres_fdw super user checks

On Mon, Oct 17, 2016 at 3:33 AM, Jeff Janes wrote: > postgres_fdw has some checks to enforce that non-superusers must connect to > the foreign server with a password-based method. The reason for this is to > prevent the authentication to the foreign server from happening on

[HACKERS] When is TopMemoryContext released ?

Hi, hackers !TopMemoryContext is created with malloc in MemoryContextInit().All the other MemoryContexts such as ErrContext, MessageContext are allocated with palloc in a block of TopMemoryContext.So, to release all the allocated memories, TopMemoryContext should be freed with

Re: [HACKERS] When is TopMemoryContext released ?

On 10/17/2016 09:26 AM, 서정협 wrote: Then, when or where is TopMemoryContext released ?? TopMemoryContext is never released, by design. See also src/backend/utils/mmgr/README. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

On Fri, Oct 7, 2016 at 7:20 AM, Etsuro Fujita wrote: > On 2016/10/07 10:26, Amit Langote wrote: >> >> On 2016/10/06 21:55, Etsuro Fujita wrote: >>> >>> On 2016/10/06 20:17, Amit Langote wrote: On 2016/10/05 20:45, Etsuro Fujita wrote: > > >>> I noticed that

Re: [HACKERS] Question about behavior of snapshot too old feature

On Sun, Oct 16, 2016 at 9:26 PM, Masahiko Sawada wrote: > When I set old_snapshot_threshold = 0 I got error at step #3, which > means that the error is occurred without table pruning. The "snapshot too old" error can happen without pruning, but only because there is no

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Oct 13, 2016 at 12:35 AM, Peter Geoghegan wrote: > On Wed, Oct 12, 2016 at 11:09 AM, Robert Haas wrote: > >> On the flip side, what if anything can queries hope to get out of >> parallel sort that they can't get out of Gather Merge? One >>

Re: [HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

Committed this patch now. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

Heikki Linnakangas writes: > Replace PostmasterRandom() with a stronger way of generating randomness. This patch broke padmeleon: 016-10-17 09:57:17.782 EDT [5804d8bd.57c2:1] LOG: database system was shut down at 2016-10-17 09:57:17 EDT 2016-10-17 09:57:17.790 EDT

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

I wrote: > But I'd understand if you think that this is too much code churn for too > little > benefit, even if it could be considered a clean-up. > > In that case, I'd argue that in the sample in doc/src/sgml/xfunc.sgml > the function definitions should be changed to read > > PGDLLEXPORT

Re: [HACKERS] Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

* Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 10/17/2016 05:50 PM, Tom Lane wrote: > >Heikki Linnakangas writes: > >>Replace PostmasterRandom() with a stronger way of generating randomness. > > > >This patch broke padmeleon: > > > >016-10-17 09:57:17.782 EDT

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 10/17/2016 12:27 PM, Heikki Linnakangas wrote: On 10/17/2016 12:18 PM, Michael Paquier wrote: You removed the part of pgcrypto in charge of randomness, nice move. I was wondering about how to do with the perfc and the unix_std at some point, and ripping them off as you did is fine for me.

Re: [HACKERS] [PATCH] Better logging of COPY queries if log_statement='all'

Andrew Dunstan writes: > On 10/17/2016 09:57 AM, Aleksander Alekseev wrote: >> Sometimes it's useful to log content of files used in COPY ... TO ... and >> COPY ... FROM ... queries. Unfortunately PostgreSQL doesn't allow to do >> it, even if log_statement='all'. Suggested

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

> > The current macaddr datatype needs to be kept for some time by renaming > it without changing OID and use the newer one for further usage. > >From the point of view of a driver maintainer... Npgsql looks up data types by their name - upon first connection to a database it queries pg_type and

[HACKERS] Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

On 10/17/2016 05:50 PM, Tom Lane wrote: Heikki Linnakangas writes: Replace PostmasterRandom() with a stronger way of generating randomness. This patch broke padmeleon: 016-10-17 09:57:17.782 EDT [5804d8bd.57c2:1] LOG: database system was shut down at 2016-10-17

Re: [HACKERS] [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

On Mon, Oct 17, 2016 at 10:50 AM, Tom Lane wrote: > The real issue here is whether we are willing to say that > Postgres simply does not work anymore on machines without standard entropy > sources. Doesn't matter whether the user cares about the strength of > cancel keys,

Re: [HACKERS] [PATCH] Better logging of COPY queries if log_statement='all'

> > I'm not in favor of this, especially if it's not even optional. > > I'm not either. It sounds good when you're looking at toy examples, > but not when it means repeating gigabytes of COPY data into the log. I understand your concern. Perhaps we could create and additional parameter for

Re: [HACKERS] Gather Merge

On Mon, Oct 17, 2016 at 4:56 AM, Amit Kapila wrote: > + node->nreaders < 2) ... > I see there are small discrepancies in both the codes like I don't see > the use of single_copy flag, as it is present in gather node. single_copy doesn't make sense for GatherMerge,

Re: [HACKERS] [PATCH] Better logging of COPY queries if log_statement='all'

On 10/17/2016 09:57 AM, Aleksander Alekseev wrote: Hello. Sometimes it's useful to log content of files used in COPY ... TO ... and COPY ... FROM ... queries. Unfortunately PostgreSQL doesn't allow to do it, even if log_statement='all'. Suggested patch fixes this. Log example: ``` LOG:

Re: [HACKERS] FSM corruption leading to errors

On 10/10/2016 05:25 PM, Michael Paquier wrote: On Fri, Oct 7, 2016 at 2:59 AM, Pavan Deolasee wrote: I believe the fix is very simple. The FSM change during truncation is critical and the buffer must be marked by MarkBufferDirty() i.e. those changes must make to the

Re: [HACKERS] make coverage-html on OS X

On 10/14/16 11:50 AM, Jim Nasby wrote: > On 10/13/16 11:13 PM, Peter Eisentraut wrote: >> On 10/13/16 4:03 PM, Jim Nasby wrote: >>> I've slowly stripped away my normal build environment; I'm now using >>> baseline gcc (no ccache) with the following ./configure... anyone have >>> any ideas how to

[HACKERS] [PATCH] Better logging of COPY queries if log_statement='all'

Hello. Sometimes it's useful to log content of files used in COPY ... TO ... and COPY ... FROM ... queries. Unfortunately PostgreSQL doesn't allow to do it, even if log_statement='all'. Suggested patch fixes this. Log example: ``` LOG: statement: create table test (k int, v text); LOG:

Re: [HACKERS] postgres_fdw super user checks

On Mon, Oct 17, 2016 at 2:18 AM, Michael Paquier wrote: > On Mon, Oct 17, 2016 at 3:33 AM, Jeff Janes wrote: >> postgres_fdw has some checks to enforce that non-superusers must connect to >> the foreign server with a password-based method. The

Re: [HACKERS] bit|varbit #, xor operator

On 10/16/16 3:13 PM, Tom Lane wrote: As for counting bits in a bitstring, why do we have to make that an operator at all? Using a function would decrease the stress involved in choosing a name, and it's hard to believe that the requirement is so common that we need to shave a few keystrokes.

Re: [HACKERS] [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

Heikki Linnakangas writes: > On 10/17/2016 05:50 PM, Tom Lane wrote: >> The real issue here is whether we are willing to say that >> Postgres simply does not work anymore on machines without standard entropy >> sources. Doesn't matter whether the user cares about the strength of

Re: [HACKERS] [PATCH] Better logging of COPY queries if log_statement='all'

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan writes: > > On 10/17/2016 09:57 AM, Aleksander Alekseev wrote: > >> Sometimes it's useful to log content of files used in COPY ... TO ... and > >> COPY ... FROM ... queries. Unfortunately PostgreSQL doesn't allow to do >

Re: [HACKERS] [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

On Mon, Oct 17, 2016 at 8:21 AM, Tom Lane wrote: > Heikki Linnakangas writes: > > On 10/17/2016 05:50 PM, Tom Lane wrote: > >> The real issue here is whether we are willing to say that > >> Postgres simply does not work anymore on machines without standard >

Re: [HACKERS] bit|varbit #, xor operator

Jim Nasby writes: > On 10/16/16 3:13 PM, Tom Lane wrote: >>> Related to this I'd also like to add a boolean XOR operator as that's a >>> relatively common request/question. >> We have boolean XOR; it's spelled "<>". > I always forget about that... Maybe it should be

Re: [HACKERS] Parallel bitmap heap scan

Hi, On 2016-10-07 11:46:40 +0530, Dilip Kumar wrote: > Brief design idea: > --- > #1. Shared TIDBitmap creation and initialization > First worker to see the state as parallel bitmap info as PBM_INITIAL > become leader and set the state to PBM_INPROGRESS All other workers >

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

On Mon, Oct 17, 2016 at 4:11 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Oct 14, 2016 at 10:14 AM, Albe Laurenz >> wrote: >>> Actually I would say that the correct solution is to remove the function >>> declarations

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

On 2016-10-17 16:16:37 -0400, Robert Haas wrote: > I wouldn't think that cross-file references would be especially > common. Functions that take PG_FUNCTION_ARGS and return Datum aren't > a lot of fun to call from C. But maybe I'm wrong. There's a fair number of DirectFunctionCall$Ns over the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

Robert Haas writes: > On Mon, Oct 17, 2016 at 1:48 PM, Heikki Linnakangas wrote: >> I'm going to try implementing prngd support. It seems easy enough, and prngd >> can be run on modern systems too, which is important for testing it. > TBH, if pandemolon

Re: [HACKERS] process type escape for log_line_prefix

On 2016-10-15 17:43:40 -0700, Jeff Janes wrote: > On Fri, Oct 14, 2016 at 11:51 AM, Andres Freund wrote: > > > On 2016-10-14 13:11:51 +0200, Christoph Berg wrote: > > > Re: Michael Paquier 2016-02-10

Re: [HACKERS] bit|varbit #, xor operator

On 10/17/16 11:29 AM, Tom Lane wrote: Jim Nasby writes: On 10/16/16 3:13 PM, Tom Lane wrote: Related to this I'd also like to add a boolean XOR operator as that's a relatively common request/question. We have boolean XOR; it's spelled "<>". I always forget

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Robert Haas writes: > On Mon, Oct 17, 2016 at 4:11 PM, Tom Lane wrote: >> As for the core problem, I wonder why we aren't recommending that >> third-party modules be built using the same infrastructure contrib >> uses, rather than people ginning up

[HACKERS] Idempotency for all DDL statements

Hello everyone. This is my first time posting in -hackers, so please keep this in mind. I would like to formally request the addition of "IF EXISTS", "IF NOT EXISTS", "OR REPLACE", and any other CINE variants to DDL statements that currently do not feature an idempotent construct. The lack of an

Re: [HACKERS] Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

Heikki Linnakangas writes: > I'm going to try implementing prngd support. It seems easy enough, and > prngd can be run on modern systems too, which is important for testing it. OK, if you feel like doing the work. However: > In addition to that, I'm going to see if we can

Re: [HACKERS] emergency outage requiring database restart

Merlin Moncure wrote: > castaging=# CREATE OR REPLACE VIEW vw_ApartmentSample AS > castaging-# SELECT ... > ERROR: 42809: "pg_cast_oid_index" is an index > LINE 11: FROM ApartmentSample s > ^ > LOCATION: heap_openrv_extended, heapam.c:1304 > > should I be restoring from

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

On 10/12/16 4:59 PM, Tom Lane wrote: > The larger picture here is that we got very little thanks when we squeezed > IPv6 into the pre-existing inet datatype; there's a large number of people > who just said "no thanks" and started using the add-on ip4r type instead. I don't think that is a

Re: [HACKERS] emergency outage requiring database restart

Merlin Moncure wrote: > We had several good backups since the previous outage so it's not > clear the events are related but after months of smooth operation I > find that coincidence highly suspicious. As always, we need to suspect > hardware problems but I'm highly abstracted from them -- using

Re: [HACKERS] emergency outage requiring database restart

On Mon, Oct 17, 2016 at 2:04 PM, Alvaro Herrera wrote: > Merlin Moncure wrote: > >> castaging=# CREATE OR REPLACE VIEW vw_ApartmentSample AS >> castaging-# SELECT ... >> ERROR: 42809: "pg_cast_oid_index" is an index >> LINE 11: FROM ApartmentSample s >>

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

On Fri, Oct 14, 2016 at 10:14 AM, Albe Laurenz wrote: > Tom Lane wrote: >>> Well, the buildfarm doesn't like that even a little bit. It seems that >>> the MSVC compiler does not like seeing both "extern Datum foo(...)" and >>> "extern PGDLLEXPORT Datum foo(...)", so

Re: [HACKERS] Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

On Mon, Oct 17, 2016 at 2:14 PM, Tom Lane wrote: > But in general, I think that being this picky about cancel keys on systems > that are too old to have /dev/random is not really helpful to anybody. > I don't recall any reports of anyone ever having a DOS situation from > weak

Re: [HACKERS] Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

On Mon, Oct 17, 2016 at 1:48 PM, Heikki Linnakangas wrote: > I'm going to try implementing prngd support. It seems easy enough, and prngd > can be run on modern systems too, which is important for testing it. TBH, if pandemolon is the only system in the BF that doesn't have any

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Robert Haas writes: > On Fri, Oct 14, 2016 at 10:14 AM, Albe Laurenz > wrote: >> Actually I would say that the correct solution is to remove the function >> declarations from all the header files in contrib, since from commit e7128e8d >> on the

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Oct 17, 2016 at 1:23 AM, Dilip Kumar wrote: > There is major chance in tidbitmap.c file after efficient hash table > commit [1] and my patch need to be rebased. > > Only parallel-bitmap-heap-scan need to be rebased, all other patch can > be applied on head as is. >

Re: [HACKERS] bit|varbit #, xor operator

On Mon, Oct 17, 2016 at 1:39 PM, Jim Nasby wrote: > On 10/17/16 11:29 AM, Tom Lane wrote: > >> Jim Nasby writes: >> >>> On 10/16/16 3:13 PM, Tom Lane wrote: >>> Related to this I'd also like to add a boolean XOR operator as that's a >

Re: [HACKERS] Non-empty default log_line_prefix

On Fri, Oct 14, 2016 at 7:04 AM, Christoph Berg wrote: > Re: Stephen Frost 2016-10-12 <20161012190732.gj13...@tamriel.snowman.net> >> For my 2c, I'd rather have %m, but I definitely agree with Robert that >> we need to do *something* here and if the only thing holding us back is

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

On Mon, Oct 17, 2016 at 4:42 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Oct 17, 2016 at 4:11 PM, Tom Lane wrote: >>> As for the core problem, I wonder why we aren't recommending that >>> third-party modules be built using

Re: [HACKERS] bit|varbit #, xor operator

On Sun, Oct 16, 2016 at 4:13 PM, Tom Lane wrote: > Jim Nasby writes: >> Personally I think it was a mistake to use # for intersection. Range >> doesn't do that (using * instead), and AFAICT PostGIS doesn't either >> (preferring &). So I propose

Re: [HACKERS] Make getrusage() output a little more readable

On Fri, Oct 14, 2016 at 10:06 AM, Peter Eisentraut wrote: > The getrusage() output that is shown by VACUUM VERBOSE and other places > has always been a little too terse and confusing for me. I propose to > improve that a bit: > > -CPU 0.01s/0.08u sec elapsed

Re: [HACKERS] Make getrusage() output a little more readable

On Fri, Oct 14, 2016 at 7:06 AM, Peter Eisentraut wrote: > The getrusage() output that is shown by VACUUM VERBOSE and other places > has always been a little too terse and confusing for me. I propose to > improve that a bit: > > -CPU 0.01s/0.08u sec elapsed 0.18