Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

On Mon, Oct 26, 2015 at 09:54:03AM +0900, Tatsuo Ishii wrote: > > Kondo's design is correct. > > So more proper fix looks like this? > + /* If postmaster is listening > on "*", "0.0.0.0" or "::", use 127.0.0.1 */ > +

Re: [HACKERS] Getting sorted data from foreign server

On Fri, Oct 23, 2015 at 2:43 AM, Robert Haas wrote: > On Wed, Oct 21, 2015 at 5:23 AM, Ashutosh Bapat > wrote: > > Increasing the sorting cost factor (when use_remote_estimates = false) > from > > 1.1 to 1.2 makes the difference disappear. > > > > Since the startup costs for postgres_fdw are lar

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 22:51, Tom Lane wrote: > Dean Rasheed writes: >> Personally I'd rather have sind(30) be exactly 0.5, even if >> sind(29.999...) or sind(30.000...1) ended up the wrong side of it. > > TBH, sir, if you think that you are too dangerous to be allowed anywhere > near any numerica

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

Noah, > No, PQping("host='127.0.0.1'") fails to reach a listen_addresses='::' server > on many systems. Here's what I thought Kondo was proposing: > > --- a/src/bin/pg_ctl/pg_ctl.c > +++ b/src/bin/pg_ctl/pg_ctl.c > @@ -649,5 +649,9 @@ test_postmaster_connection(pgpid_t pm_pid, bool > do_checkpo

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

Noah, > No, PQping("host='127.0.0.1'") fails to reach a listen_addresses='::' server > on many systems. Here's what I thought Kondo was proposing: > > --- a/src/bin/pg_ctl/pg_ctl.c > +++ b/src/bin/pg_ctl/pg_ctl.c > @@ -649,5 +649,9 @@ test_postmaster_connection(pgpid_t pm_pid, bool > do_checkpo

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2015-10-23 7:34 GMT+02:00 Catalin Iacob : > On Sat, Oct 17, 2015 at 8:18 PM, Pavel Stehule > wrote: > > here is new patch > > > > cleaned, all unwanted artefacts removed. I am not sure if used way for > > method registration is 100% valid, but I didn't find any related > > documentation. > >

Re: [HACKERS] TODO list updates

On 16 October 2015 18:20:59 EEST, Bruce Momjian wrote: >I think on-disk bitmap indexes would only beat GIN indexes in a >read-only database on low-cardinality columns. For example, if you had >a purchase_log table and wanted to know all the "blue" and "large" >items >sold at a specific store, I

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Mon, Oct 26, 2015 at 10:02 PM, Christopher Browne wrote: > > On 26 October 2015 at 16:25, Peter Eisentraut wrote: > >> On 10/14/15 6:41 AM, Victor Wagner wrote: >> > 1. It is allowed to specify several hosts in the connect string, either >> > in URL-style (separated by comma) or in param=valu

[HACKERS] Disabling START TRANSACTION for a SuperUser

Hi, I have created a readonly user by executing the following statements, CREATE USER backupadm SUPERUSER password 'mypass'; ALTER USER backupadm set default_transaction_read_only = on; But the backupadm user is able to create/update table when using START TRANSACTION READ WRITE and then COMMIT;

Re: [HACKERS] Disabling START TRANSACTION for a SuperUser

On 27 October 2015 at 18:25, rajan wrote: > Hi, > > I have created a readonly user by executing the following statements, > CREATE USER backupadm SUPERUSER password 'mypass'; A superuser can never be a read only user. > ALTER USER backupadm set default_transaction_read_only = on; They can just

Re: [HACKERS] Getting sorted data from foreign server

On Tue, Oct 27, 2015 at 5:26 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > > > On Fri, Oct 23, 2015 at 2:43 AM, Robert Haas wrote: >> >> On Wed, Oct 21, 2015 at 5:23 AM, Ashutosh Bapat >> wrote: >> > Increasing the sorting cost factor (when use_remote_estimates = false) from >>

Re: [HACKERS] Disabling START TRANSACTION for a SuperUser

Hey Craig, Thanks for your response. Seems like the workaround is difficult. I am trying to understand " ExecutorStart_hook and ProcessUtility_hook, implemented with a C extension. You can find an example of one in pg_stat_statements, sepgsql, and in the BDR source code. The latter uses it for

Re: [HACKERS] Disabling START TRANSACTION for a SuperUser

On 27 October 2015 at 21:19, rajan wrote: > Hey Craig, > > Thanks for your response. Seems like the workaround is difficult. > > I am trying to understand > " > ExecutorStart_hook and ProcessUtility_hook Doing what you want will require being willing to spend a fair bit of time becoming familiar

[HACKERS] fortnight interval support

On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote: > Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be cool. Patch attached... :) % psql -p 5433 -d template1 -h localhost psql (9.4.5, server 9.6devel) WARNING: psql major version 9.4, server major version 9.6.

Re: [HACKERS] remaining open items

On 14 October 2015 at 09:57, Robert Haas wrote: > We've got a few open items remaining at > https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items - we should > try to get rid of them. I'd like to add, rather than remove, one. A bug in replication origins support. It comes with a simple fix.

Re: [HACKERS] Disabling START TRANSACTION for a SuperUser

On Tuesday, October 27, 2015 8:52 AM, Craig Ringer wrote: > On 27 October 2015 at 21:19, rajan wrote: >> Thanks for your response. Seems like the workaround is difficult. >> >> I am trying to understand >> " >> ExecutorStart_hook and ProcessUtility_hook > Doing what you want will require being

Re: [HACKERS] remaining open items

Craig Ringer wrote: > On 14 October 2015 at 09:57, Robert Haas wrote: > > We've got a few open items remaining at > > https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items - we should > > try to get rid of them. > > I'd like to add, rather than remove, one. A bug in replication origins > sup

Re: [HACKERS] Rework the way multixact truncations work

Hi, On 2015-10-24 22:07:00 -0400, Noah Misch wrote: > I'm several days into a review of this change (commits 4f627f8 and > aa29c1c). Cool! > There's one part of the design I want to understand before commenting on > specific code. What did you anticipate to be the consequences of failing to > r

Re: [HACKERS] Duplicated assignment of slot_name in walsender.c

Andres Freund wrote: > If you want to do that, I'm unenthusiastically not objecting. But if so, > let's also do it in IdentifySystem(), SendTimeLineHistory(), > StartReplication(), SendBackupHeader(), SendXLogRecPtResult() - they're > modeled after each other. Okay, pushed with that, backpatched

Re: [HACKERS] fortnight interval support

On Tue, Oct 27, 2015 at 8:52 AM, Nathan Wagner wrote: > On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote: >> Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be >> cool. > > Patch attached... > > :) This is very cool (you are 100% certain there are no performance

Re: [HACKERS] fortnight interval support

On Tue, Oct 27, 2015 at 01:52:11PM +, Nathan Wagner wrote: > On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote: > > Aw, you're no fun. select '1 fortnight'::interval => '14 days' > > would be cool. > > Patch attached... > > :) I'd argue for a back-patch all the way to 9.1, as the

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 10/27/2015 01:42 AM, Shulgin, Oleksandr wrote: > On Mon, Oct 26, 2015 at 10:02 PM, Christopher Browne > wrote: > > > On 26 October 2015 at 16:25, Peter Eisentraut > wrote: > > On 10/14/15 6:41 AM, Victor Wagner wrote: >

Re: [HACKERS] [DOCS] max_worker_processes on the standby

Alvaro Herrera wrote: > Robert Haas wrote: > > On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote: > > > I agree with that sentiment. > > > > > > Attached patch adds variable to the shmem which is used for module > > > activation tracking - set to true in ActiveCommitTs() and false in > > > Deact

Re: [HACKERS] fortnight interval support

On 28/10/15 02:52, Nathan Wagner wrote: On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote: Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be cool. Patch attached... :) [...] You trying to get PostgreSQL banned in France??? :-) When I was learning French ma

Re: [HACKERS] fortnight interval support

On Tue, Oct 27, 2015 at 12:04:55PM -0500, Merlin Moncure wrote: > On Tue, Oct 27, 2015 at 8:52 AM, Nathan Wagner wrote: > > On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote: > >> Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be > >> cool. > > > > Patch attached.

Re: [HACKERS] fortnight interval support

On Wed, Oct 28, 2015 at 08:17:25AM +1300, Gavin Flower wrote: > You trying to get PostgreSQL banned in France??? :-) > > When I was learning French many years ago, I was told that the French > consider their fortnight to be 15 days!!! What, it's a "fortnight", not a "quinzaine". You have no ide

Re: [HACKERS] fortnight interval support

On Tue, Oct 27, 2015 at 01:52:11PM +, Nathan Wagner wrote: > On Mon, Oct 26, 2015 at 01:58:52PM -0400, Robert Haas wrote: > > Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be > > cool. > > Patch attached... This isn't necessarily bad, but I observe that it would be di

Re: [HACKERS] Limit GIST_MAX_SPLIT_PAGES to XLR_MAX_BLOCK_ID

(adding Heikki, since that macro was touched by his commit 04e298b8) Does my previous description of the problem make sense, or am I fretting over something that's a non-issue. Best regards, On Sun, Sep 20, 2015 at 7:03 PM, Gurjeet Singh wrote: > Gin code respects the XLR_MAX_BLOCK_ID when >

Re: [HACKERS] Rework the way multixact truncations work

On 10/27/2015 07:44 AM, Andres Freund wrote: >> Unlinking old pg_clog files is strictly an optimization. If you were to >> > comment out every unlink() call in slru.c, the only ill effect on CLOG is >> > the >> > waste of disk space. Is the same true of MultiXact? > Well, multixacts are a lot la

[HACKERS] quieting DEBUG3

It's been my observation that setting client_min_messages or log_min_messages to DEBUG3 is almost invariably impractical, because every SQL statement spews about SIX messages about the transaction state: rhaas=# select 1; DEBUG: StartTransactionCommand DEBUG: StartTransaction DEBUG: name: unnam

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Tue, Oct 20, 2015 at 12:39 PM, Etsuro Fujita wrote: > Sorry, my explanation was not correct. (Needed to take in caffeine.) What > I'm concerned about is the following: > > SELECT * FROM localtab JOIN (ft1 LEFT JOIN ft2 ON ft1.x = ft2.x) ON > localtab.id = ft1.id FOR UPDATE OF ft1 > > LockRows

Re: [HACKERS] remaining open items

Ian Barwick wrote: > On 17/10/15 04:31, Alvaro Herrera wrote: > > Robert Haas wrote: > >>> The other item on me is the documentation patch by Emre Hasegeli for > >>> usage of the inclusion opclass framework in BRIN. I think it needs some > >>> slight revision by some native English speaker and I'm

Re: [HACKERS] [COMMITTERS] pgsql: Cleanup commit timestamp module activaction, again

On Tue, Oct 27, 2015 at 7:07 PM, Alvaro Herrera wrote: > Cleanup commit timestamp module activaction, again > > Further tweak commit_ts.c so that on a standby the state is completely > consistent with what that in the master, rather than behaving > differently in the cases that the settings differ

Re: [HACKERS] Parallel Seq Scan

On Sat, Oct 24, 2015 at 6:31 PM, Noah Misch wrote: > On Sat, Oct 24, 2015 at 07:49:07AM -0400, Robert Haas wrote: >> On Fri, Oct 23, 2015 at 9:38 PM, Noah Misch wrote: >> > Since that specification permits ParamListInfo consumers to ignore >> > paramMask, >> > the plpgsql_param_fetch() change fr

Re: [HACKERS] quieting DEBUG3

On 28 October 2015 at 04:52, Robert Haas wrote: > Thoughts? I agree with you that DEBUG3 is currently impractical. So much so that when testing/debugging I often change log severities of messages of interest so they'll show up at DEBUG2 instead, rather than running in DEBUG3. Simplifying the St

Re: [HACKERS] [COMMITTERS] pgsql: Cleanup commit timestamp module activaction, again

Robert Haas writes: > On Tue, Oct 27, 2015 at 7:07 PM, Alvaro Herrera > wrote: >> Cleanup commit timestamp module activaction, again > The buildfarm seems to be very unhappy right now, and it looks as if > this commit is to blame. I think it's just failure to update an expected-file, but will

Re: [HACKERS] quieting DEBUG3

Craig Ringer writes: > I think it'd be helpful to define some level of policy about what the > debug levels are intended for, so there's some guidance on what level > to emit messages on rather than playing "pick a number". +1 ... I doubt anyone has ever looked at that in a holistic way.

Re: [HACKERS] [COMMITTERS] pgsql: Cleanup commit timestamp module activaction, again

Tom Lane wrote: > Robert Haas writes: > > On Tue, Oct 27, 2015 at 7:07 PM, Alvaro Herrera > > wrote: > >> Cleanup commit timestamp module activaction, again > > > The buildfarm seems to be very unhappy right now, and it looks as if > > this commit is to blame. > > I think it's just failure to

Re: [HACKERS] [COMMITTERS] pgsql: Cleanup commit timestamp module activaction, again

Alvaro Herrera writes: > Tom Lane wrote: >> I think it's just failure to update an expected-file, but will leave it >> to Alvaro. > I don't understand. It passed make check fine for me on both branches. > Will fix in a jiffy. There are two variant expected files for that module --- did you fix

Re: [HACKERS] [COMMITTERS] pgsql: Cleanup commit timestamp module activaction, again

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> I think it's just failure to update an expected-file, but will leave it > >> to Alvaro. > > > I don't understand. It passed make check fine for me on both branches. > > Will fix in a jiffy. > > There are two variant expected file

Re: [HACKERS] Disabling START TRANSACTION for a SuperUser

Thanks Craig, There are a lot of details and its overwhelming :-) Let me digest and will post for any help On 27-Oct-2015 7:21 PM, "Craig Ringer" wrote: > On 27 October 2015 at 21:19, rajan <[hidden email] > > wrote: > > Hey Craig, >

Re: [HACKERS] Disabling START TRANSACTION for a SuperUser

Hello Kevin, This may be a trivial thing But what do you mean by shops? I actually can't get it :-) On 27-Oct-2015 7:37 PM, "Kevin Grittner" wrote: > On Tuesday, October 27, 2015 8:52 AM, Craig Ringer > wrote: > > On 27 October 2015 at 21:19, rajan wrote: > > >> Thanks for your respons

Re: [HACKERS] Freeze avoidance of very large table.

On Sat, Oct 24, 2015 at 2:24 PM, Masahiko Sawada wrote: > > On Sat, Oct 24, 2015 at 10:59 AM, Amit Kapila wrote: > > > > I think we can display information about relallfrozen it in pg_stat_*_tables > > as suggested by you. It doesn't make much sense to keep it in pg_class > > unless we have some

Re: [HACKERS] Disabling START TRANSACTION for a SuperUser

On 2015/10/28 12:57, Muthiah Rajan wrote: > Hello Kevin, > > This may be a trivial thing But what do you mean by shops? I actually > can't get it :-) I think it's casually used to mean a company or a production environment. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] Getting sorted data from foreign server

On Tue, Oct 27, 2015 at 6:44 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > On Tue, Oct 27, 2015 at 5:26 AM, Ashutosh Bapat < > ashutosh.ba...@enterprisedb.com> wrote: > > > > > > > > On Fri, Oct 23, 2015 at 2:43 AM, Robert Haas > wrote: > >> > >> On Wed, Oct 21, 2015 at 5:23

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Oct 27, 2015 at 9:34 AM, Pavel Stehule wrote: > Hi > > 2015-10-23 7:34 GMT+02:00 Catalin Iacob : >> The current code doesn't build on Python3 because the 3rd argument of >> PyMethod_New, the troubled one you need set to NULL has been removed. >> This has to do with the distinction between