Re: [HACKERS] [COMMITTERS] pgsql: Add transforms feature

On 5/3/15 2:27 PM, Tom Lane wrote: > 1. Preventing undefined-symbol errors at link time might be standard > according to some platforms, but it is not the universal default, and > I think there is no very good reason to assume that it is possible > everywhere. So I'm afraid that prairiedog is just

Re: [HACKERS] Implementing SQL ASSERTION

On 4/30/15 6:36 PM, Joe Wildish wrote: > I’m wondering if there are other people out there working on implementing SQL > ASSERTION functionality? I was the last one, probably: . I intend to pick up that work sometim

Re: [HACKERS] replication slot restart_lsn initialization

Hi, On 2015-05-06 00:42:14 +, Duran, Danilo wrote: > I am looking to better understand the thought behind a replication > slot's restart_lsn initialization. Currently in 9.4 and master, a > replication slot's restart_lsn is set to InvalidXLogRecPtr and will > only start tracking restart_lsn on

Re: [HACKERS] BRIN range operator class

On 05/05/2015 01:10 PM, Emre Hasegeli wrote: I already replied his email [1]. Which issues do you mean? Sorry, my bad please ignore the previous email. -- Andreas Karlsson -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On Tue, May 5, 2015 at 8:40 AM, Andres Freund wrote: > One additional thing I'm wondering about is the following: Right now > INSERT ... ON CONFLICT NOTHING does not acquire a row level lock on the > 'target' tuple. Are we really ok with that? Because in this form ON > CONFLICT NOTHING really does

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On Tue, May 5, 2015 at 9:36 AM, Andres Freund wrote: > Theoretically this changes the pictures for FDWs, right? Right now > there's > + > + INSERT with an ON CONFLICT clause is not > + supported with a unique index inference specification, since a > + conflict arbitrating unique in

Re: [HACKERS] BRIN range operator class

Can you please explain what is the purpose of patch 07? I'm not sure I understand; are we trying to avoid having to add pg_amproc entries for these operators and instead piggy-back on btree opclass definitions? Not too much in love with that idea; I see that there is less tedium in that the brin o

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

Hi, On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote: > Remaining challenges > = One additional thing I'm wondering about is the following: Right now INSERT ... ON CONFLICT NOTHING does not acquire a row level lock on the 'target' tuple. Are we really ok with that? Because in t

Re: [HACKERS] INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote: > Remaining challenges > = Another thing I'm wondering about is dealing with deferrable constraints/deferred indexes. a) Why does ExecCheckIndexConstraints() check for indisimmediate for *all* indexes and not just when it's a

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On 2015-05-04 14:16:42 -0700, Peter Geoghegan wrote: > On Sun, Apr 26, 2015 at 2:22 AM, Heikki Linnakangas wrote: > > The ability to specify a constraint by name hasn't been implemented, but > > that would read quite naturally as: > > > > INSERT INTO mytable ON CONFLICT ON CONSTRAINT my_constraint

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Tue, May 5, 2015 at 11:10 AM, Sawada Masahiko wrote: > On Fri, May 1, 2015 at 9:04 PM, Robert Haas wrote: >> On Thu, Apr 30, 2015 at 11:05 PM, Sawada Masahiko >> wrote: >>> VACUUM has both syntax: with parentheses and without parentheses. >>> I think we should have both syntax for REINDEX li

Re: [HACKERS] Disabling trust/ident authentication configure option

On Tue, May 5, 2015 at 8:05 AM, Volker Aßmann wrote: > Changing the password to something simple is immediately obvious as a > security flaw for most people who may come across database configurations, > but for the TRUST mode you actually need to know some background on why this > is dangerous an

Re: [HACKERS] add -s to vacuumdb

On Tue, May 5, 2015 at 4:26 PM, Joshua D. Drake wrote: > > > On 05/05/2015 12:22 PM, Andrew Dunstan wrote: >> >> >> >> On 05/05/2015 03:06 PM, Joshua D. Drake wrote: >>> >>> >>> Hey folks, >>> >>> Just had your standard... our pg_ tables are all bloated out, what is >>> a good way to take care of

Re: [HACKERS] initdb start server recommendation

On 5/1/15 10:55 AM, Euler Taveira wrote: > On 01-05-2015 11:14, Bruce Momjian wrote: >> Currently initdb outputs suggested text on starting the server: >> >> Success. You can now start the database server using: >> >> /u/pgsql/bin/postgres -D /u/pgsql/data >> or >>

Re: [HACKERS] add -s to vacuumdb

On 05/05/2015 12:22 PM, Andrew Dunstan wrote: On 05/05/2015 03:06 PM, Joshua D. Drake wrote: Hey folks, Just had your standard... our pg_ tables are all bloated out, what is a good way to take care of that. We have -s for reindexdb but not vacuumdb. Thoughts? What command will it run? V

Re: [HACKERS] add -s to vacuumdb

On 05/05/2015 03:06 PM, Joshua D. Drake wrote: Hey folks, Just had your standard... our pg_ tables are all bloated out, what is a good way to take care of that. We have -s for reindexdb but not vacuumdb. Thoughts? What command will it run? VACUUM doesn't have a SYSTEM flag, unlike REIND

Re: [HACKERS] BRIN range operator class

Alvaro Herrera wrote: > Looking at patch 04, it seems to me that it would be better to have > the OpcInfo struct carry the typecache struct rather than the type OID, > so that we can avoid repeated typecache lookups in brin_deform_tuple; Here's the patch. -- Álvaro Herrerahttp://

Re: [HACKERS] Auditing extension for PostgreSQL (Take 2)

On 5/4/15 8:37 PM, Stephen Frost wrote: > I don't follow this logic. The concerns raised above are about changing > our in-core logging. We haven't got in-core auditing and so I don't see > how they apply to it. How is session "auditing" substantially different from statement logging? I think i

Re: [HACKERS] BRIN range operator class

Looking at patch 04, it seems to me that it would be better to have the OpcInfo struct carry the typecache struct rather than the type OID, so that we can avoid repeated typecache lookups in brin_deform_tuple; something like /* struct returned by "OpcInfo" amproc */ typedef struct BrinOpcInfo {

[HACKERS] add -s to vacuumdb

Hey folks, Just had your standard... our pg_ tables are all bloated out, what is a good way to take care of that. We have -s for reindexdb but not vacuumdb. Thoughts? JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting

Re: [HACKERS] BRIN range operator class

After looking at 05 again, I don't like the "same as %" business. Creating a whole new class of exceptions is not my thing, particularly not in a regression test whose sole purpose is to look for exceptional (a.k.a. "wrong") cases. I would much rather define the opclasses for those two datatypes u

Re: [HACKERS] Fixing busted citext function declarations

"David G. Johnston" writes: > On Tue, May 5, 2015 at 10:20 AM, Tom Lane wrote: >> Alvaro Herrera writes: >>> I think we should keep the 1.0 version this time, in back branches. >> Agreed. Maybe we shouldn't even make 1.1 the default in the back >> branches. > ​Does 9.0 get different treatme

Re: [HACKERS] Fixing busted citext function declarations

On Tue, May 5, 2015 at 10:20 AM, Tom Lane wrote: > Alvaro Herrera writes: > > (I think it is possible that the behavior change is actually problematic > > as opposed to just behaving differently. For instance, if the function > > is used in a subselect that's expected to return only one row, an

Re: [HACKERS] Fixing busted citext function declarations

Alvaro Herrera writes: > (I think it is possible that the behavior change is actually problematic > as opposed to just behaving differently. For instance, if the function > is used in a subselect that's expected to return only one row, and it > suddenly starts returning more, the query would rais

Re: [HACKERS] Fixing busted citext function declarations

On May 5, 2015, at 10:07 AM, Alvaro Herrera wrote: >> So AFAICS we need to actually drop and recreate >> the citext regexp_matches() functions in the upgrade script. That means >> "ALTER EXTENSION citext UPDATE" will fail if these functions are being >> used in any views. That's annoying but I

Re: [HACKERS] Fixing busted citext function declarations

Tom Lane wrote: > * We can't use CREATE OR REPLACE FUNCTION in the upgrade script because > that intentionally doesn't let you change the result type of an existing > function. I considered doing a manual UPDATE of the pg_proc entry, but > then remembered why CREATE OR REPLACE FUNCTION is picky a

Re: [HACKERS] parallel mode and parallel contexts

On Sat, May 2, 2015 at 12:35 PM, Noah Misch wrote: > Perhaps, rather than model it as master M waiting on worker list W1|W2|W3, > model it with queue-nonempty and queue-nonfull events, one pair per queue. Each individual queue has only a single reader and a single writer. In your example, there w

[HACKERS] Fixing busted citext function declarations

In http://www.postgresql.org/message-id/bn1pr04mb37467aa1d412223b3d4a595df...@bn1pr04mb374.namprd04.prod.outlook.com it's revealed that the citext extension misdeclares its versions of regexp_matches(): they should return SETOF text[] but they're marked as returning just text[]. We know generally

[HACKERS] INSERT ... ON CONFLICT error messages

I've read through all the error messages in the patch. Some comments: postgres=# create table foo (id int4); CREATE TABLE postgres=# create unique index foo_y on foo (id) where id > 0; CREATE INDEX postgres=# insert into foo values (-1) on conflict (id) where id > 0 do nothing; ERROR: in

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Fri, May 1, 2015 at 9:04 PM, Robert Haas wrote: > On Thu, Apr 30, 2015 at 11:05 PM, Sawada Masahiko > wrote: >> VACUUM has both syntax: with parentheses and without parentheses. >> I think we should have both syntax for REINDEX like VACUUM does >> because it would be pain to put parentheses w

Re: [HACKERS] feature freeze and beta schedule

On Tue, May 5, 2015 at 3:47 PM, Robert Haas wrote: > On Fri, May 1, 2015 at 1:16 PM, Stephen Frost wrote: > > We really need to segregate the two.. By that what I mean is this: I > > want an "always-open" "bugfix" CF, which allows us to keep track of > > bugfix patches. Having something about

Re: [HACKERS] feature freeze and beta schedule

On Fri, May 1, 2015 at 1:16 PM, Stephen Frost wrote: > We really need to segregate the two.. By that what I mean is this: I > want an "always-open" "bugfix" CF, which allows us to keep track of > bugfix patches. Having something about "applies to versions X, Y, Z" > would be nice too... > > /me

Re: [HACKERS] pg_dump: CREATE TABLE + CREATE RULE vs. relreplident

On Fri, May 1, 2015 at 1:06 PM, Andres Freund wrote: > On 2015-05-01 13:03:39 -0400, Bruce Momjian wrote: >> Applied and backpatched to 9.4. > > Ah. Forgot about that. Thanks! > > Andres > > .oO(bugtracker?) I don't really see how that would help. People can forget about a ticket in a bugtracker

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On Mon, May 4, 2015 at 5:21 AM, Petr Korobeinikov wrote: > I'm proposing to add two new subcommands in psql: > 1. \ev viewname - edit view definition with external editor (like \ef for > function) > 2. \sv viewname - show view definition (like \sf for function, for > consistency) Sounds nice. Ma

Re: [HACKERS] extend pgbench expressions with functions

v4, rebase (after pgbench moved to src) and use of the recently added syntax_error function. v5 which adds a forgotten header declaration for a new function, so as to avoid a warning. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index a808546..d09b2bf

Re: [HACKERS] initdb -S and tablespaces

On Tue, May 5, 2015 at 6:26 AM, David Rowley wrote: > On 5 May 2015 at 06:23, Robert Haas wrote: >> >> OK, committed and back-patched. > > There's a couple of problems with this that the windows buildfarm members > are not happy with. > > The attached patch seems to work locally. Thanks. I thin

[HACKERS] Patch for bug #12845 (GB18030 encoding)

Hi, Can someone look at this patch. It should fix bug #12845. The current tests for conversions are very minimal. I expanded them a bit for this bug. I think the binary search in the .map files should be removed but I leave that for another patch. 0001-Have-GB18030-handle-more-than-2-byte-Unic

Re: [HACKERS] INSERT ... ON CONFLICT syntax issues

On 05/05/2015 12:16 AM, Peter Geoghegan wrote: On Sun, Apr 26, 2015 at 2:22 AM, Heikki Linnakangas wrote: The ability to specify a constraint by name hasn't been implemented, but that would read quite naturally as: INSERT INTO mytable ON CONFLICT ON CONSTRAINT my_constraint UPDATE ... For th

Re: [HACKERS] Disabling trust/ident authentication configure option

Hello, I am the one who suggested the patch to Credativ, so let me explain my reasoning. It is clear that it is basically impossible to get perfect security but this patch would help to solve one small but for our use case quite dangerous issue. Changing the password to something simple is immedi

Re: [HACKERS] BRIN range operator class

> Nice, I think it is ready now other than the issues Alvaro raised in his > review[1]. Have you given those any thought? I already replied his email [1]. Which issues do you mean? [1] http://www.postgresql.org/message-id/CAE2gYzxQ-Gk3q3jYWT=1enlebsgcgu28+1axml4omcwjbkp...@mail.gmail.com --

Re: [HACKERS] initdb -S and tablespaces

On 5 May 2015 at 06:23, Robert Haas wrote: > > OK, committed and back-patched. > There's a couple of problems with this that the windows buildfarm members are not happy with. The attached patch seems to work locally. Regards David Rowley fsync_win32_fix.patch Description: Binary data -- S

Re: [HACKERS] BRIN range operator class

On 05/05/2015 11:57 AM, Emre Hasegeli wrote: From my point of view as a reviewer this patch set is very close to being committable. Thank you. The new versions are attached. Nice, I think it is ready now other than the issues Alvaro raised in his review[1]. Have you given those any thought

Re: [HACKERS] BRIN range operator class

> Indeed, I have done some testing of the patch but more people testing would > be nice. The inclusion opclass should work for other data types as long required operators and SQL level support functions are supplied. Maybe it would work for PostGIS, too. -- Sent via pgsql-hackers mailing list (

Re: [HACKERS] BRIN range operator class

On 05/05/2015 04:24 AM, Alvaro Herrera wrote: Stefan Keller wrote: I'm keen to see if a PostGIS specialist jumps in and adds PostGIS geometry support. Did you test the patch proposed here already? It could be a very good contribution. Indeed, I have done some testing of the patch but more p

Re: [HACKERS] Unexpected speed PLAIN vs. MAIN

On Mon, May 04, 2015 at 01:50:45PM -0400, Tom Lane wrote: > Sandro Santilli writes: > > I'm comparing speed of some queries against tables having the same data > > but different storage, and got an unexpected behavior. > > > The tables have 2 integer fields and a PcPatch field > > ("p", custom t