Re: [HACKERS] more on comments of snapbuild.c

On 2017-03-18 06:37, Erik Rijkers wrote: Studying logrep yielded some more improvements to the comments in snapbuild.c (to be applied to master) Attached the actual file thanks, Erik Rijekrs --- src/backend/replication/logical/snapbuild.c.orig 2017-03-18 05:02:28.627077888 +0100 +++

[HACKERS] more on comments of snapbuild.c

Studying logrep yielded some more improvements to the comments in snapbuild.c (to be applied to master) thanks, Erik Rijekrs -- 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] WIP: [[Parallel] Shared] Hash

On Tue, Mar 14, 2017 at 8:03 AM, Thomas Munro wrote: > On Mon, Mar 13, 2017 at 8:40 PM, Rafia Sabih > wrote: >> In an attempt to test v7 of this patch on TPC-H 20 scale factor I found a >> few regressions, >> Q21: 52 secs on HEAD and

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Mar 17, 2017 at 9:15 AM, Ashutosh Bapat wrote: > This set of patches fixes both of those things. 0001 changes the purpose of a function and then 0007 renames it. It would be better to include the renaming in 0001 so that you're not taking multiple whacks

Re: [HACKERS] increasing the default WAL segment size

On Fri, Mar 17, 2017 at 6:11 PM, Peter Eisentraut wrote: > On 3/17/17 16:56, Tom Lane wrote: >> Tools could get the segment size out of >> XLogLongPageHeaderData.xlp_seg_size in the first page of the segment. > > OK, then pg_standby would have to wait until the

Re: [HACKERS] <> join selectivity estimate question

On Sat, Mar 18, 2017 at 11:49 AM, Thomas Munro wrote: > On Sat, Mar 18, 2017 at 6:14 AM, Tom Lane wrote: >> After a bit more thought, it seems like the bug here is that "the >> fraction of the LHS that has a non-matching row" is not one minus >>

Re: [HACKERS] <> join selectivity estimate question

On Sat, Mar 18, 2017 at 6:14 AM, Tom Lane wrote: > After a bit more thought, it seems like the bug here is that "the > fraction of the LHS that has a non-matching row" is not one minus > "the fraction of the LHS that has a matching row". In fact, in > this example, *all* LHS

[HACKERS] Introduce expression initialization hook?

Hi, It looks we're creeping towards agreement in http://archives.postgresql.org/message-id/20161206034955.bh33paeralxbtluv%40alap3.anarazel.de It'd be fairly easy to add a hook in its ExecInstantiateExpr(), which'd allow extensions to provide newer (presumably faster) ways to evaluate

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

Hi, On 03/17/2017 05:23 PM, Peter Eisentraut wrote: I'm struggling to find a good way to share code between bt_page_items(text, int4) and bt_page_items(bytea). If we do it via the SQL route, as I had suggested, it makes the extension non-relocatable, and it will also create a bit of a mess

Re: [HACKERS] Microvacuum support for Hash Index

On Wed, Mar 15, 2017 at 07:26:45PM -0700, Andres Freund wrote: > On 2017-03-15 16:31:11 -0400, Robert Haas wrote: > > On Wed, Mar 15, 2017 at 3:54 PM, Ashutosh Sharma > > wrote: > > > Changed as per suggestions. Attached v9 patch. Thanks. > > > > Wow, when do you sleep? >

Re: [HACKERS] Parallel Append implementation

On Fri, Mar 17, 2017 at 10:12 AM, Amit Khandekar wrote: > Yeah, I was in double minds as to whether to do the > copy-to-array-and-qsort thing, or should just write the same number of > lines of code to manually do an insertion sort. Actually I was > searching if we already

Re: [HACKERS] increasing the default WAL segment size

On 3/17/17 16:56, Tom Lane wrote: > Tools could get the segment size out of > XLogLongPageHeaderData.xlp_seg_size in the first page of the segment. OK, then pg_standby would have to wait until the file is at least XLOG_BLCKSZ, then look inside and get the expected final size. A bit more

Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM

By the way, it would be very good if you could review some patches, too. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] [PATCH] Suppress Clang 3.9 warnings

On 3/13/17 11:35, Aleksander Alekseev wrote: > Here is a new patch. I tried to make as little changes as possible. This > is no doubt not the most beautiful patch on Earth but it removes all > warnings. I anyone could suggest an approach that would be significantly > better please don't hesitate

Re: [HACKERS] Two phase commit in ECPG

On Fri, Mar 17, 2017 at 5:50 PM, Michael Meskes wrote: >> Thank you for pointing out. >> Yeah, I agree that the twophase regression test should not be >> performed by default as long as the default value of >> max_prepared_transactions is 0. Similar to this, the isolation

Re: [HACKERS] Index usage for elem-contained-by-const-range clauses

On Friday 10 March 2017 07:59 PM, Alexander Korotkov wrote: Hi, Pritam! > > I've assigned to review this patch. > > On Thu, Feb 23, 2017 at 2:17 AM, Pritam Baral wrote: > > The topic has been previously discussed[0] on the -performance mailing list, > about four

Re: [HACKERS] Index usage for elem-contained-by-const-range clauses

On Sunday 12 March 2017 01:58 AM, Jim Nasby wrote: On 3/10/17 8:29 AM, Alexander Korotkov wrote: >> That's cool idea. But I would say more. Sometimes it's useful to >> transform "intcol between x and y" into "intcol <@ 'x,y'::int4range". >> btree_gin supports "intcol between x and y" as

Re: [HACKERS] Index usage for elem-contained-by-const-range clauses

I wrote: > * You're not bothering to insert any inputcollid into the generated > comparison operator nodes. I'm not sure why that fails to fall over > for text comparisons (if indeed it does fail ...) but it's wrong. > Use the range type's collation there. Oh ... looking at this again, I realize

Re: [HACKERS] increasing the default WAL segment size

Peter Eisentraut writes: > On 3/17/17 16:20, Peter Eisentraut wrote: >> I think we would have to extend restore_command with an additional >> placeholder that communicates the segment size, and add a new pg_standby >> option to accept that size somehow. And

Re: [HACKERS] increasing the default WAL segment size

On 3/17/17 16:20, Peter Eisentraut wrote: > On 3/16/17 21:10, Robert Haas wrote: >> The changes to pg_standby seem to completely break the logic to wait >> until the file has attained the correct size. I don't know how to >> salvage that logic off-hand, but just breaking it isn't acceptable. > >

[HACKERS] Re: new set of psql patches for loading (saving) data from (to) text, binary files

2017-03-16 22:01 GMT+01:00 Stephen Frost : > Pavel, > > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > 2017-03-15 17:21 GMT+01:00 Stephen Frost : > > > I started looking through this to see if it might be ready to commit > and > > > I don't believe it

Re: [HACKERS] Candidate for local inline function?

Kevin Grittner writes: > Why do we warn of a hazard here instead of eliminating said hazard > with a static inline function declaration in executor.h? > /* > * ExecEvalExpr was formerly a function containing a switch statement; > * now it's just a macro invoking the function

Re: [HACKERS] Candidate for local inline function?

On Fri, Mar 17, 2017 at 3:23 PM, Andres Freund wrote: > On 2017-03-17 15:17:33 -0500, Kevin Grittner wrote: >> Why do we warn of a hazard here instead of eliminating said hazard >> with a static inline function declaration in executor.h? > > Presumably because it was written

Re: [HACKERS] Candidate for local inline function?

Hi Kevin, On 2017-03-17 15:17:33 -0500, Kevin Grittner wrote: > Why do we warn of a hazard here instead of eliminating said hazard > with a static inline function declaration in executor.h? Presumably because it was written long before we started relying on inline functions :/ > /* > *

Re: [HACKERS] increasing the default WAL segment size

On 3/16/17 21:10, Robert Haas wrote: > The changes to pg_standby seem to completely break the logic to wait > until the file has attained the correct size. I don't know how to > salvage that logic off-hand, but just breaking it isn't acceptable. I think we would have to extend restore_command

[HACKERS] Candidate for local inline function?

Why do we warn of a hazard here instead of eliminating said hazard with a static inline function declaration in executor.h? /* * ExecEvalExpr was formerly a function containing a switch statement; * now it's just a macro invoking the function pointed to by an ExprState * node. Beware of

Re: [HACKERS] pageinspect and hash indexes

Ashutosh Sharma writes: > Basically, when we started working on WAL for hash index, we found > that WAL routine 'XLogReadBufferExtended' does not expect a page to be > completely zero page else it returns Invalid Buffer. To fix this, we > started initializing freed overflow

Re: [HACKERS] pageinspect and hash indexes

On 3/17/17 13:24, Jeff Janes wrote: > And isn't it unhelpful to have the pageinspect module throw errors, > rather than returning a dummy value to indicate there was an error? Even if one agreed with that premise, it would be hard to satisfy reliably, because the user-facing pageinspect functions

Re: [HACKERS] <> join selectivity estimate question

Robert Haas writes: > On Fri, Mar 17, 2017 at 1:14 PM, Tom Lane wrote: >> It would not be too hard to convince me that neqjoinsel should >> simply return 1.0 for any semijoin/antijoin case, perhaps with >> some kind of discount for nullfrac. Whether or

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

I wrote: > Petr Jelinek writes: >> Thanks, now that I look at it again I think we might need to do cycle >> with the occurred_events and returned_events and not return on first >> find since theoretically there can be multiple sockets if this gets >> called directly

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

Andrew Dunstan writes: > On 03/17/2017 12:28 PM, Tom Lane wrote: >> I'll add some comments and push this. Does everyone agree that >> this had better get back-patched, too? > Confirmed that this fixes the problem on jacana. > +1 for backpatching. I've pushed

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

On 03/17/2017 12:28 PM, Tom Lane wrote: > Petr Jelinek writes: >> Now the documentation for WSAEventSelect says "The FD_WRITE network >> event is handled slightly differently. An FD_WRITE network event is >> recorded when a socket is first connected with a call to

[HACKERS] Re: [COMMITTERS] pgsql: Remove objname/objargs split for referring to objects

On 3/17/17 13:39, Alvaro Herrera wrote: > Oh yeah, buildfarm member sitella shows that. Does the attached patch > fix it? (pretty much the same thing Michael attached, but we also need > to handle typeoids) Yes, that makes the warning go away. -- Peter Eisentraut

Re: [HACKERS] pageinspect and hash indexes

On Fri, Mar 17, 2017 at 10:54 PM, Jeff Janes wrote: > While trying to figure out some bloating in the newly logged hash indexes, > I'm looking into the type of each page in the index. But I get an error: > > psql -p 9876 -c "select

[HACKERS] free space map and visibility map

With some intensive crash-recovery testing, I've run into a situation where I get some bad table bloat. There will be large swaths of the table which are empty (all results from heap_page_items other than lp are either zero or NULL), but have zero available space in the fsm, and are marked as

Re: [HACKERS] <> join selectivity estimate question

On Fri, Mar 17, 2017 at 1:14 PM, Tom Lane wrote: > After a bit more thought, it seems like the bug here is that "the > fraction of the LHS that has a non-matching row" is not one minus > "the fraction of the LHS that has a matching row". In fact, in > this example, *all* LHS

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > > \set x 'arg1 arg2' > > > \if false > > \cmd_that_takes_exactly_two_args :x > > \endif > > Yeah, throwing errors for bad arguments would also need to be suppressed. > > regards, tom lane > Ok, barring other feedback, I'm going to take my marching orders as "make

Re: [HACKERS] merging duplicate definitions of adjust_relid_set

On Fri, Mar 17, 2017 at 1:50 PM, Tom Lane wrote: > Robert Haas writes: >> While reviewing Ashutosh Bapat's partitionwise join code, I noticed >> he'd run up against the problem that adjust_relid_set() is defined as >> static in two different source

Re: [HACKERS] [COMMITTERS] pgsql: Fix and simplify check for whether we're running as Windows serv

Heikki Linnakangas writes: > Fix and simplify check for whether we're running as Windows service. This seems to have broken narwhal: Creating library file: libpostgres.a ../../src/port/libpgport_srv.a(win32security_srv.o)(.text+0x109): In function `pgwin32_is_admin':

[HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

Hi, Currently, clients wishing to know when the server exits hot standby have to resort to polling, which is often suboptimal. This adds the new "in_hot_standby" GUC variable that is reported via a ParameterStatus message. This allows the clients to: (a) know right away that they are

Re: [HACKERS] merging duplicate definitions of adjust_relid_set

Robert Haas writes: > While reviewing Ashutosh Bapat's partitionwise join code, I noticed > he'd run up against the problem that adjust_relid_set() is defined as > static in two different source files, and he wanted to call it from a > third file. I didn't much like his

[HACKERS] Re: [COMMITTERS] pgsql: Remove objname/objargs split for referring to objects

Peter Eisentraut wrote: > cc -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute > -Wformat-security -fno-strict-aliasing -fwrapv > -fexcess-precision=standard -g -O2 -I../../../src/include > -D_FORTIFY_SOURCE=2 -DLINUX_OOM_ADJ

[HACKERS] merging duplicate definitions of adjust_relid_set

While reviewing Ashutosh Bapat's partitionwise join code, I noticed he'd run up against the problem that adjust_relid_set() is defined as static in two different source files, and he wanted to call it from a third file. I didn't much like his solution to that problem, which was to rename one of

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Corey Huinker writes: >> In the end, I suspect that teaching all the backslash commands to do >> nothing after absorbing their arguments is likely to be the least messy >> way to tackle this, even if it makes for a rather bulky patch. > Perhaps, but just glancing at

[HACKERS] pageinspect and hash indexes

While trying to figure out some bloating in the newly logged hash indexes, I'm looking into the type of each page in the index. But I get an error: psql -p 9876 -c "select hash_page_type(get_raw_page('foo_index_idx',x)) from generate_series(1650,1650) f(x)" ERROR: page is not a hash page

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

Petr Jelinek writes: > On 17/03/17 17:28, Tom Lane wrote: >> Yeah, I'm afraid we had better do something more or less like this. >> It's interesting to speculate about whether WaitEventSet could keep >> additional state that would avoid the need for a dummy send()

Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM

I gave this patch a quick skim. At first I was confused by the term "catalog"; I thought it meant we stored options in a system table. But that's not what is meant at all; instead, what we do is build these "catalogs" in memory. Maybe a different term could have been used, but I'm not sure it's

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > That said, it seems this is something that has to wait for a later > release, I'm putting back in similar logic as there was before (not a > branch, but change the opcode to a non-checking variant). Yeah, I was wondering if changing the opcode would be

Re: [HACKERS] Parallel Append implementation

On 16 March 2017 at 18:18, Ashutosh Bapat wrote: > + * Check if we are already finished plans from parallel append. This > + * can happen if all the subplans are finished when this worker > + * has not even started returning tuples. > +

Re: [HACKERS] Parallel Append implementation

On 17 March 2017 at 01:37, Robert Haas wrote: > - You've added a GUC (which is good) but not documented it (which is > bad) or added it to postgresql.conf.sample (also bad). > > - You've used a loop inside a spinlock-protected critical section, > which is against project

Re: [HACKERS] <> join selectivity estimate question

I wrote: > The problem here appears to be that we don't have any MCV list for > the "twothousand" column (because it has a perfectly flat distribution), > and the heuristic that eqjoinsel_semi is using for the no-MCVs case > is falling down badly. Oh ... wait. eqjoinsel_semi's charter is to

Re: [HACKERS] [patch] reorder tablespaces in basebackup tar stream for backup_label

Hi, Am Freitag, den 17.03.2017, 20:46 +0900 schrieb Michael Paquier: > On Fri, Mar 17, 2017 at 7:18 PM, Michael Banck > wrote: > > Am Freitag, den 17.03.2017, 10:50 +0900 schrieb Michael Paquier: > >> The comment block format is incorrect. I would think as well that

Re: [HACKERS] <> join selectivity estimate question

Robert Haas writes: > The relevant code is in neqsel(). It estimates the fraction of rows > that will be equal, and then does 1 - that number. Evidently, the > query planner thinks that l1.l_suppkey = l2.l_suppkey would almost > always be true, and therefore l1.l_suppkey

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > In the end, I suspect that teaching all the backslash commands to do > nothing after absorbing their arguments is likely to be the least messy > way to tackle this, even if it makes for a rather bulky patch. > > Perhaps, but just glancing at \connect makes me think that for some commands

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Hello Tom, I also fear that there are corner cases where the behavior would still be inconsistent. Consider \if ... \set foo `echo \endif should not appear here` In this instance, ISTM that there is no problem. On "\if true", set is executed, all is well. On "\if false", the whole line

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

On 17/03/17 17:28, Tom Lane wrote: > Petr Jelinek writes: >> Now the documentation for WSAEventSelect says "The FD_WRITE network >> event is handled slightly differently. An FD_WRITE network event is >> recorded when a socket is first connected with a call to the

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Corey Huinker writes: > I think Fabien was arguing that inside a false block there would be no > syntax rules beyond "is the first non-space character on this line a '\' > and if so is it followed with a if/elif/else/endif?". If the answer is no, > skip the line. To me

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-17 11:36:30 -0400, Tom Lane wrote: > Having said all that, I think that 0001 is contributing very little to the > goals of this patch set. Andres stated that he wanted it so as to drop > some of the one-time checks that execQual.c currently does for Vars, but > I'm not really

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

Petr Jelinek writes: > Now the documentation for WSAEventSelect says "The FD_WRITE network > event is handled slightly differently. An FD_WRITE network event is > recorded when a socket is first connected with a call to the connect, > ConnectEx, WSAConnect,

[HACKERS] Re: [COMMITTERS] pgsql: Remove objname/objargs split for referring to objects

On 3/17/17 11:06, Alvaro Herrera wrote: > I don't get anything with my compiler (gcc (Debian 4.9.2-10) 4.9.2) and > I don't see anything in the few logs I looked at (clang, 9.6) from > buildfarm either. What are you seeing specifically? cc -Wall -Wmissing-prototypes -Wpointer-arith

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

I'm struggling to find a good way to share code between bt_page_items(text, int4) and bt_page_items(bytea). If we do it via the SQL route, as I had suggested, it makes the extension non-relocatable, and it will also create a bit of a mess during upgrades. If doing it in C, it will be a bit

Re: [HACKERS] QGIS Seem To Bypass PostgreSQL/PostGIS User Privileges/Permissions

Hi John, Thanks for your response. From my experience as a Software Developer, I don't think QGIS can logon to my database/schema/table with a dedicated user as they need authentication to do so. What you described about using a dedicated user in applications is only possible because that user

Re: [HACKERS] <> join selectivity estimate question

On Fri, Mar 17, 2017 at 1:54 AM, Thomas Munro wrote: > SELECT * >FROM lineitem l1 > WHERE EXISTS (SELECT * > FROM lineitem l2 > WHERE l1.l_orderkey = l2.l_orderkey); > > -> estimates 59986012 rows, actual rows 59,986,052

Re: [HACKERS] QGIS Seem To Bypass PostgreSQL/PostGIS User Privileges/Permissions

Hi all, 2017-03-17 17:09 GMT+01:00 John Scalia : > While I do not know QGIS, I'm wondering if it's similar to some of our > applications where they always use the same system login for the database > while each user provides a unique login to the application. Have you

Re: [HACKERS] QGIS Seem To Bypass PostgreSQL/PostGIS User Privileges/Permissions

While I do not know QGIS, I'm wondering if it's similar to some of our applications where they always use the same system login for the database while each user provides a unique login to the application. Have you ever set log_connections in your postgresql.conf file? That would show you which

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Fri, Mar 17, 2017 at 11:42 AM, Tom Lane wrote: > Fabien COELHO writes: > >> I also fear that there are corner cases where the behavior would still > >> be inconsistent. Consider > >> > >> \if ... > >> \set foo `echo \endif should not appear here` > >

Re: [HACKERS] logical decoding of two-phase transactions

On Thu, Mar 16, 2017 at 10:34 PM, Craig Ringer wrote: > On 17 March 2017 at 08:10, Stas Kelvich wrote: >> While working on this i’ve spotted quite a nasty corner case with aborted >> prepared >> transaction. I have some not that great ideas how

Re: [HACKERS] Adding the optional clause 'AS' in CREATE TRIGGER

> > > I am sending the review of this patch I found the following v Use tage in documentation v Don’t modified existing test case add new one instead v Comment in pg_constraint.c is extended make it short v Error message can be more guider if it tells about general rule v Wrong result

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

On 17/03/17 16:07, Tom Lane wrote: > Andrew Dunstan writes: >> I have confirmed on jacana Petr's observation that adding a timeout to >> the WaitLatchOrSocket cures the problem. > > Does anyone have a theory as to why that cures the problem? > I now have theory

Re: [HACKERS] QGIS Seem To Bypass PostgreSQL/PostGIS User Privileges/Permissions

Hi Giuseppe, Thanks for the response. I have provided the GRANTS and other PostgreSQL setup scripts below as it includes what you have suggested: ROLE - CREATE ROLE WITH NOLOGIN NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION; USER -- CREATE USER WITH PASSWORD ''

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Fabien COELHO writes: >> I also fear that there are corner cases where the behavior would still >> be inconsistent. Consider >> >> \if ... >> \set foo `echo \endif should not appear here` > In this instance, ISTM that there is no problem. On "\if true", set is > executed,

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > command.c:38:25: fatal error: conditional.h: No such file or directory > #include "conditional.h" > Odd, it's listed as a new file in git status. Anyway, my point of posting the WIP patch was to give people a reference point and spark discussion about the next step, and it succeeded at

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > [ latest patches ] I looked through 0001 (the composite-type-dependencies one). Although I agree that it'd be good to tighten things up in that area, I do not think we want this specific patch: it tightens things too much. Consider this variant of

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Hello Tom, ISTM that I've tried to suggest to work around that complexity by: - document that \if-related commands should only occur at line start (and extend to eol). - detect and complain when this is not the case. I think this is a lousy definition, and would never be considered

[HACKERS] Misleading bgworker log message

​​ A handful of rather surprising errors showed up in our log extract this morning, along the lines of: ​ 2017-03-17 05:01:55 CDT [5400]: [1-1] @ FATAL: 57P01: terminating connection due to administrator command ​After a moment of more than a little astonishment, a look at the full log revealed

Re: [HACKERS] QGIS Seem To Bypass PostgreSQL/PostGIS User Privileges/Permissions

Hi Osahon, 2017-03-17 15:54 GMT+01:00 Osahon Oduware : > Hi All, > > I created a "Read-only" User in PostgreSQL via a Role with "SELECT" ONLY > privilege on all tables in a schema as shown below: > > GRANT SELECT ON ALL TABLES IN SCHEMA [schema_name] TO [role_name] >

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

Andrew Dunstan writes: > I have confirmed on jacana Petr's observation that adding a timeout to > the WaitLatchOrSocket cures the problem. Does anyone have a theory as to why that cures the problem? What length of timeout is being suggested here? Would a long

[HACKERS] Re: [COMMITTERS] pgsql: Remove objname/objargs split for referring to objects

Peter Eisentraut wrote: > On 3/16/17 11:56, Alvaro Herrera wrote: > > Michael Paquier wrote: > > > >> What are you using as CFLAGS? As both typenames should be normally > >> set, what about initializing those fields with NULL and add an > >> assertion like the attached? > > > > Actually, my

Re: [HACKERS] Microvacuum support for Hash Index

On Fri, Mar 17, 2017 at 6:13 PM, Amit Kapila wrote: > On Fri, Mar 17, 2017 at 12:27 PM, Ashutosh Sharma > wrote: >> On Fri, Mar 17, 2017 at 8:20 AM, Amit Kapila wrote: >> >> As I said in my previous e-mail, I think you

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

I have committed the page_checksum function, will work on the bt stuff next. I left in the superuser check, because I was not confident how well pg_checksum_page() would handle messed up data. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

[HACKERS] QGIS Seem To Bypass PostgreSQL/PostGIS User Privileges/Permissions

Hi All, I created a "Read-only" User in PostgreSQL via a Role with "SELECT" ONLY privilege on all tables in a schema as shown below: GRANT SELECT ON ALL TABLES IN SCHEMA [schema_name] TO [role_name] GRANT [role_name] TO [user_name] Next, I test this by trying to UPDATE a column in a table (same

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

On 03/08/2017 08:29 PM, Andrew Dunstan wrote: > > On 03/08/2017 08:33 AM, Peter Eisentraut wrote: >> On 3/6/17 09:38, Peter Eisentraut wrote: >>> On 3/4/17 01:45, Petr Jelinek wrote: If that's the case, the attached should fix it, but I have no way of testing it on windows, I can only

Re: [HACKERS] Two phase commit in ECPG

> Thank you for pointing out. > Yeah, I agree that the twophase regression test should not be > performed by default as long as the default value of > max_prepared_transactions is 0. Similar to this, the isolation check > regression test does same thing. Attached patch removes sql/twophase > from

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Fabien COELHO writes: > ISTM that I've tried to suggest to work around that complexity by: > - document that \if-related commands should only occur at line start > (and extend to eol). > - detect and complain when this is not the case. I think this is a lousy

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

On 3/17/17 4:18 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa, >> Takayuki >> I made this ready for committer. The patch applied except for catversion.h, >> the patch content looks good, and the

Re: [HACKERS] wait events for disk I/O

Thanks Robert for the review. On Thu, Mar 16, 2017 at 8:05 PM, Robert Haas wrote: > On Thu, Mar 16, 2017 at 8:28 AM, Rahila Syed > wrote: > > Thank you for the updated patch. > > > > I have applied and tested it on latest sources and the patch

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Thu, Mar 16, 2017 at 10:21 PM, Michael Paquier wrote: > On Fri, Mar 17, 2017 at 11:17 AM, Robert Haas wrote: >> I understand that the point of renaming pg_clog to pg_xact is that >> pg_clog contains the dreaded letters l-o-g, which we

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Fri, Mar 17, 2017 at 10:58 PM, Robert Haas wrote: > Fine! I've committed the pg_clog renaming, but I'd really like to > draw the line here. I'm not going to commit the pg_subtrans -> > pg_subxact naming and am -1 on anyone else doing so. I think that > having the

[HACKERS] Guidelines for GSoC student proposals

I've found various sources that give hints about what a student proposal should look like, but nothing I could just give as a link, so I pulled together what I could find, tempered by my own ideas and opinions. I suggest that we send the below, or something like it to each student who expresses

Re: [HACKERS] PATCH: Configurable file mode mask

On 3/15/17 3:00 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele >>> But it might be worth thinking about whether we want to encourage >>> people to do manual chmod's at all; that's fairly easy to get

Re: [HACKERS] PATCH: Configurable file mode mask

On 3/15/17 1:56 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele >> Sure, but having the private key may allow them to get new data from the >> server as well as the data from the backup. > > You are

Re: [HACKERS] scram and \password

Robert Haas writes: > On Fri, Mar 17, 2017 at 8:32 AM, Heikki Linnakangas wrote: >> It would make sense to have \password obey password_encryption GUC. Then >> \password and ALTER USER would do the same thing, which would be less >> surprising. Although

Re: [HACKERS] [PATCH] ALTER DEFAULT PRIVILEGES with GRANT/REVOKE ON SCHEMAS

On 3/13/17 11:15 AM, David Steele wrote: > Hi Matheus, > > On 3/2/17 8:27 AM, David Steele wrote: >> On 1/18/17 7:18 PM, Petr Jelinek wrote: >>> >>> The patch looks good, the only thing I am missing is tab completion >>> support for psql. >> >> It looks like this patch is still waiting on an

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On 3/17/17 3:58 AM, Kyotaro HORIGUCHI wrote: > At Mon, 13 Mar 2017 10:42:05 -0400, David Steele wrote > in <1e8297fd-f7f2-feab-848d-5121e45c8...@pgmasters.net> >> It has been a while since this thread has received any comments or a new >> patch. The general consensus seems

Re: [HACKERS] [PATCH] Remove defunct and unnecessary link

On Thu, Mar 16, 2017 at 6:30 PM, David Christensen wrote: > The HA docs reference a “glossary” link which is no longer accessible, nor is > it likely to be useful in general to link off-site IMHO. This simple patch > removes this link. Committed and back-patched. Thanks.

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

"Daniel Verite" writes: > Tom Lane wrote: >> OT_WHOLE_LINE is not what you want because that results in verbatim >> copying, without variable expansion or anything > But if we want to implement "\if defined :foo" in the future > isn't it just what we need? I don't

Re: [HACKERS] scram and \password

On Fri, Mar 17, 2017 at 8:32 AM, Heikki Linnakangas wrote: > It would make sense to have \password obey password_encryption GUC. Then > \password and ALTER USER would do the same thing, which would be less > surprising. Although it's also a bit weird for a GUC to affect

Re: [HACKERS] Microvacuum support for Hash Index

On Fri, Mar 17, 2017 at 12:27 PM, Ashutosh Sharma wrote: > On Fri, Mar 17, 2017 at 8:20 AM, Amit Kapila wrote: > > As I said in my previous e-mail, I think you need >> to record clearing of this flag in WAL record XLOG_HASH_DELETE as you >> are not

[HACKERS] Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-R rate) options together.

On 3/17/17 2:08 AM, Fabien COELHO wrote: > > Hello David, > >>> Repost from bugs. >> >> This patch does not apply at cccbdde: > > Indeed. It should not. The fix is for the 9.6 branch. The issue has been > fixed by some heavy but very welcome restructuring in master. Whoops, sorry about that!

Re: [HACKERS] scram and \password

On 03/17/2017 02:01 PM, Robert Haas wrote: On Thu, Mar 16, 2017 at 11:38 PM, Michael Paquier wrote: At least this has the merit of making \password simpler from psql without a kind of --method option: if the backend is 9.6 or older, just generate a MD5-hash, and

  1   2   >