Re: [HACKERS] Subscriber resets additional columns to NULL on UPDATE

On 10/26/17 05:20, Petr Jelinek wrote: > I found bug in logical replication where extra (nullable) columns on > subscriber will be reset to NULL value when update comes from provider. > > The issue is apparently that we /points finger at himself/ forgot to > check specifically for columns that

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Do we still need the complication in brinsummarize to discriminate > >> against the last partial range? Now that the lock consideration > >> is gone, I think that might be a wart. > > > In the case of

Re: [HACKERS] Exclude pg_internal.init from base backup

Hi, On 02/09/17 21:08, David Steele wrote: > Hackers, > > The cache in pg_internal.init was reused in days of yore but has been > rebuilt on postmaster startup since v8.1. It appears there is no reason > for this file to be backed up. > Makes sense. > I also moved the RELCACHE_INIT_FILENAME

Re: [HACKERS] Skip unneeded temp file in 'make html'

On Fri, Nov 03, 2017 at 11:34:18AM -0400, Peter Eisentraut wrote: > On 11/2/17 22:07, David Fetter wrote: > > postgres.xml: $(srcdir)/postgres.sgml $(ALLSGML) > > - $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< >$@.tmp > > - $(call mangle-xml,book) > > + $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x

Re: [HACKERS] Skip unneeded temp file in 'make html'

On 11/2/17 22:07, David Fetter wrote: > postgres.xml: $(srcdir)/postgres.sgml $(ALLSGML) > - $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< >$@.tmp > - $(call mangle-xml,book) > + $(OSX) $(SPFLAGS) $(SGMLINCLUDE) -x lower $< | $(call mangle-xml,book) The reason why it's not done that

Re: [HACKERS] WIP: Aggregation push-down

Antonin Houska wrote: > This is another version of the patch. > shard.tgz demonstrates the typical postgres_fdw use case. One query shows base > scans of base relation's partitions being pushed to shard nodes, the other > pushes down a join and performs aggregation of the join

Re: [HACKERS] Walsender timeouts and large transactions

Hi, thanks for checking. On 02/11/17 10:00, Robert Haas wrote: > On Wed, Nov 1, 2017 at 8:19 PM, Petr Jelinek > wrote: >> sorry for the delay but I didn't have much time in past weeks to follow >> this thread. > > +TimestampTz now = GetCurrentTimestamp(); > +

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-11-02 06:05:51 -0700, Andres Freund wrote: > Hi, > > On 2017-11-02 13:49:47 +0100, Alvaro Herrera wrote: > > Andres Freund wrote: > > > I think the problem is on the pruning, rather than the freezing side. We > > > can't freeze a tuple if it has an alive predecessor - rather than > > >

Re: [HACKERS] Small improvement to compactify_tuples

On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote: > Sokolov Yura writes: >> [ 0001-Improve-compactify_tuples.patch, v5 or thereabouts ] > > I started to review this patch. I spent a fair amount of time on > beautifying the code, because I found it

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Alvaro Herrera writes: > Tom Lane wrote: >> Do we still need the complication in brinsummarize to discriminate >> against the last partial range? Now that the lock consideration >> is gone, I think that might be a wart. > In the case of VACUUM, it's not desirable to

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Tom Lane wrote: > Alvaro Herrera writes: > > > Yeah, I think this approach results in better code. The attached patch > > implements that, and it passes the test for me (incl. calling > > brin_summarize_new_values concurrently with vacuum, when running the > > insert;

Re: [HACKERS] MERGE SQL Statement for PG11

On 3 November 2017 at 08:26, Robert Haas wrote: > On Fri, Nov 3, 2017 at 1:05 PM, Simon Riggs wrote: >>> Therefore, if MERGE eventually uses INSERT .. ON CONFLICT >>> UPDATE when a relevant unique index exists and does something else, >>> such as

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Alvaro Herrera writes: > Alvaro Herrera wrote: >> Maybe a solution is to call RelationGetNumberOfBlocks() after the >> placeholder tuple has been inserted, for the case where we would be >> scanning past end of relation; passing InvalidBlockNumber as stop point >> would

Re: [HACKERS] [PATCH] A hook for session start

On Fri, Nov 3, 2017 at 11:43 AM, Aleksandr Parfenov < a.parfe...@postgrespro.ru> wrote: > > README file in patch 0003 is a copy of README from test_pg_dump module > without any changes. > Thanks, I'll fix it. Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira:

Re: [HACKERS] [PATCH] A hook for session start

On Fri, Nov 3, 2017 at 11:19 AM, Michael Paquier wrote: > > /* > + * Setup handler to session end hook > + */ > +if (IsUnderPostmaster) > +on_proc_exit(do_session_end_hook, 0); > I think that it would be better to place that in ShutdownPostgres.

Re: [HACKERS] [PATCH] A hook for session start

README file in patch 0003 is a copy of README from test_pg_dump module without any changes. -- Aleksandr Parfenov Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] [PATCH] A hook for session start

On Thu, Nov 2, 2017 at 11:36 PM, Fabrízio de Royes Mello wrote: > On Thu, Nov 2, 2017 at 5:42 AM, Aleksandr Parfenov > wrote: >> Unfortunately, patches 0001 and 0002 don't apply to current master. >> >> The new status of this patch is: Waiting

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Alvaro Herrera wrote: > Maybe a solution is to call RelationGetNumberOfBlocks() after the > placeholder tuple has been inserted, for the case where we would be > scanning past end of relation; passing InvalidBlockNumber as stop point > would indicate to do things that way. I'll try with that

[HACKERS] LDAPS

Hi hackers, I've run into a few requests for $SUBJECT in the field. I understand that this is a bit controversial: LDAP + StartTLS (what we already support) is better than LDAPS because it's a proper standard, and LDAP auth in general is not as good as some other authentication methods that we

Re: [HACKERS] parallelize queries containing initplans

On Mon, Oct 30, 2017 at 10:07 AM, Robert Haas wrote: > On Mon, Oct 30, 2017 at 9:00 AM, Amit Kapila wrote: >> Now that the PARAM_EXTERN issue is fixed, I have rebased this patch. >> This patch had been switched to Ready For Committer in last CF,

[HACKERS] LDAP URI decoding bugs

Hi hackers, 1. If you set up a pg_hba.conf with a URL that lacks a base DN or hostname, hba.c will segfault on startup when it tries to pstrdup a null pointer. Examples: ldapurl="ldap://localhost; and ldapurl="ldap://;. 2. If we fail to bind but have no binddn configured, we'll pass NULL to

Re: [HACKERS] proposal: schema variables

Some thoughts on this. On Thu, Nov 2, 2017 at 4:48 PM, Tom Lane wrote: > Nico Williams writes: > > With access controls, GUCs could become schema variables, and settings > > from postgresql.conf could move into the database itself (which I think > >

Re: [HACKERS] dropping partitioned tables without CASCADE

Ashutosh Bapat wrote: > On Fri, Nov 3, 2017 at 1:42 PM, Alvaro Herrera > wrote: > > I think adding "is partitioned" at end of line isn't good; looks like a > > phrase but isn't translatable. Maybe add keyword PARTITIONED instead? > > In that case may be we should

Re: [HACKERS] SQL/JSON in PostgreSQL

On Fri, Nov 3, 2017 at 12:07 PM, Michael Paquier wrote: > The patch sent previously does not directly apply on HEAD, and as far > as I can see the last patch set published on > https://www.postgresql.org/message-id/2361ae4a-66b1-c6c5-ea6a-84851a1c0...@postgrespro.ru >

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

On Mon, Oct 16, 2017 at 10:08 PM, Andres Freund wrote: > On 2017-10-16 16:59:59 -0400, Peter Eisentraut wrote: >> On 9/20/17 04:32, Andres Freund wrote: >> > Here's what I roughly was thinking of. I don't quite like the name, and >> > the way the version is specified for

Re: [HACKERS] dropping partitioned tables without CASCADE

On Fri, Nov 3, 2017 at 1:42 PM, Alvaro Herrera wrote: > Amit Langote wrote: >> On 2017/09/06 19:14, Amit Langote wrote: >> > On 2017/09/06 18:46, Rushabh Lathia wrote: >> >> Okay, I have marked this as ready for committer. >> > >> > Thanks Ashutosh and Rushabh for

Re: [HACKERS] SQL/JSON in PostgreSQL

On Fri, Nov 3, 2017 at 11:29 AM, Nikita Glukhov wrote: > By standard only string literals can be used in JSON path specifications. > But of course it is possible to allow to use variable jsonpath expressions > in > SQL/JSON functions. > > Attached patch implements this

Re: [HACKERS] postgres_fdw: Add support for INSERT OVERRIDING clause

On Tue, Oct 31, 2017 at 3:45 PM, Peter Eisentraut wrote: > It has been pointed out to me that the command deparsing in postgres_fdw > does not support the INSERT OVERRIDING clause that was added in PG10. > Here is a patch that seems to fix that. I don't know

Re: [HACKERS] SQL/JSON in PostgreSQL

On 03.11.2017 00:32, Piotr Stefaniak wrote: On 2017-02-28 20:08, Oleg Bartunov wrote: The standard describes SQL/JSON path language, which used by SQL/JSON query operators to query JSON. It defines path language as string literal. We implemented the path language as JSONPATH data type, since

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Tom Lane wrote: > Alvaro Herrera writes: > > Rather than remove the capability, I'd be inclined to make > > brin_summarize_new_values summarize the final partial range, and have > > VACUUM not do it. Would that be too inconsistent? > > That doesn't really get you out

Re: [HACKERS] [bug fix] postgres.exe crashes with access violation on Windows while starting up

On Wed, Nov 1, 2017 at 12:07 AM, Tsunakawa, Takayuki wrote: > From: Michael Paquier [mailto:michael.paqu...@gmail.com] >> On Tue, Oct 31, 2017 at 6:59 AM, Tsunakawa, Takayuki >> wrote: >> > When CurrentMemoryContext is NULL, the

Re: [HACKERS] Linking libpq statically to libssl

* Stephen Frost (sfr...@snowman.net) wrote: > and we've certainly not spent effort that I've seen to try to actually > make libpq work when multiple versions of libpq are linked into the same > running backend. ... errr, same running application, that is, not backend. Thanks! Stephen

Re: [HACKERS] MERGE SQL Statement for PG11

* Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Nov 3, 2017 at 1:05 PM, Simon Riggs wrote: > > We seem to have a few options for PG11 > > > > 1. Do nothing, we reject MERGE > > > > 2. Implement MERGE for unique index situations only, attempting to > > avoid errors

Re: [HACKERS] Client Connection redirection support for PostgreSQL

> pg_hba.conf is "host based access [control]" . I'm not sure it's really the > right place. I am open to have another configuration file, say routing_list.conf to define the routing rules, but felt it is easy to extend the hba conf file. > But we now have a session-intent stuff though. So we

Re: [HACKERS] Client Connection redirection support for PostgreSQL

> What advantages do you see in doing this in the backend over the current > system where the concerns are separated, i.e. people use connection poolers > like pgbouncer to do the routing? IMHO connection pooler is not great for latency sensitive applications. For small deployments, proxy is

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Hi, On 11/02/2017 06:45 PM, Alvaro Herrera wrote: > Tomas Vondra wrote: > >> Unfortunately, I think we still have a problem ... I've been wondering >> if we end up producing correct indexes, so I've done a simple test. > > Here's a proposed patch that should fix this problem (and does, in my >

Re: [HACKERS] Try to fix endless loop in ecpg with informix mode

> Although this error message is not wrong, I think it should be better > to > give error message as "invalid input syntax for type int" for "7.a". > This could be done by delete "return false;" after "while(...)", let > the following if to decide which to return. Ah, now I understand. Sorry, I

Re: [HACKERS] How to implement a SP-GiST index as a extension module?

Yeah, unfortunately, the way these type of metric trees work, the entire search procedure is a function of both the target value and the allowed search distance. The only way I can think of to return ordered results without just scanning the entire index would be to repeatedly search the index

Re: [HACKERS] MERGE SQL Statement for PG11

On 3 November 2017 at 07:46, Thomas Kellerer wrote: > PMFJI > >> We seem to have a few options for PG11 >> >> 1. Do nothing, we reject MERGE >> >> 2. Implement MERGE for unique index situations only, attempting to >> avoid errors (Simon OP) >> >> 3. Implement MERGE, but

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Nov 3, 2017 at 1:05 PM, Simon Riggs wrote: >> Therefore, if MERGE eventually uses INSERT .. ON CONFLICT >> UPDATE when a relevant unique index exists and does something else, >> such as your proposal of taking a strong lock, or Peter's proposal of >> doing this in a

Re: [HACKERS] dropping partitioned tables without CASCADE

Amit Langote wrote: > On 2017/09/06 19:14, Amit Langote wrote: > > On 2017/09/06 18:46, Rushabh Lathia wrote: > >> Okay, I have marked this as ready for committer. > > > > Thanks Ashutosh and Rushabh for rebasing and improving the patch. Looks > > good to me too. > > Patch needed to be rebased

Re: [HACKERS] MERGE SQL Statement for PG11

PMFJI > We seem to have a few options for PG11 > > 1. Do nothing, we reject MERGE > > 2. Implement MERGE for unique index situations only, attempting to > avoid errors (Simon OP) > > 3. Implement MERGE, but without attempting to avoid concurrent ERRORs > (Peter) > > 4. Implement MERGE, while

Re: [HACKERS] MERGE SQL Statement for PG11

On 2 November 2017 at 22:59, Nico Williams wrote: > On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote: >> Nico Williams wrote: >> >A MERGE mapped to a DML like this: >> >> This is a bad idea. An implementation like this is not at all >>

Re: [HACKERS] MERGE SQL Statement for PG11

On 2 November 2017 at 17:06, Robert Haas wrote: > On Tue, Oct 31, 2017 at 5:14 PM, Simon Riggs wrote: >> I've proposed a SQL Standard compliant implementation that would do >> much more than be new syntax over what we already have. >> >> So these two

Re: [HACKERS] How to implement a SP-GiST index as a extension module?

On Thu, Nov 2, 2017 at 9:53 AM, Connor Wolf wrote: > As such: > Will compound queries as I describe above basically require a custom type to > make it possible? My (admittedly naive) expectation > is that the eventual query for this index will look something like

Re: [HACKERS] Try to fix endless loop in ecpg with informix mode

Hi, I found the last commit changed as: ``` /* skip invalid characters */ do { (*scan_length)++; - } while (**scan_length != ' ' && **scan_length != '\0' && isdigit(**scan_length)); + } while (isdigit(**scan_length)); return

Re: [HACKERS] ArrayLists instead of List (for some things)

On 3 November 2017 at 12:41, David Rowley wrote: > On 3 November 2017 at 03:26, Craig Ringer wrote: >> On 2 November 2017 at 22:22, David Rowley >> wrote: >>> Maybe, but the new implementation is not going to do

Re: [HACKERS] Setting pd_lower in GIN metapage

On Fri, Nov 3, 2017 at 1:10 AM, Amit Kapila wrote: > On Fri, Nov 3, 2017 at 2:54 AM, Tom Lane wrote: >> I've marked the CF entry closed. However, I'm not sure if we're quite >> done with this thread. Weren't we going to adjust nbtree and hash to >>

Re: [HACKERS] pgbench - use enum for meta commands

[ pgbench-enum-meta-2.patch ] Pushed with some trivial cosmetic adjustments (pgindent changed it more than I did). Ok. Thanks. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] PATCH: pgbench - option to build using ppoll() for larger connection counts

Hello, Could you rebase the v11 patch? -- Fabien. -- 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] ArrayLists instead of List (for some things)

On 3 November 2017 at 03:26, Craig Ringer wrote: > On 2 November 2017 at 22:22, David Rowley > wrote: >> Maybe, but the new implementation is not going to do well with places >> where we perform lcons(). Probably many of those places could be

Re: [HACKERS] SSL and Encryption

On Fri, Nov 3, 2017 at 3:19 AM, Craig Ringer wrote: > This is probably off topic for pgsql-hackers. > > For password crypto please go read the SCRAM thread and the PostgreSQL > 10 release notes. The SCRAM discussion is spread across two threads mainly with hundreds of

Re: [HACKERS] path toward faster partition pruning

On 31 October 2017 at 21:43, Amit Langote wrote: > Attached updated version of the patches addressing some of your comments I've spent a bit of time looking at these but I'm out of time for now. So far I have noted down the following; 1. This comment seem wrong.

Re: [HACKERS] SSL and Encryption

On 3 November 2017 at 11:16, chiru r wrote: > Hi , > > Please suggest the best chiper suite to configure openSSL for PostgreSQL > Server and client?. > > How to use other than md5 encryption algorithm to encrypt the passwords in > PostgreSQL? This is probably off topic for

[HACKERS] SSL and Encryption

Hi , Please suggest the best chiper suite to configure openSSL for PostgreSQL Server and client?. How to use other than md5 encryption algorithm to encrypt the passwords in PostgreSQL? Thanks, Chiru

Re: [HACKERS] path toward faster partition pruning

On 31 October 2017 at 21:43, Amit Langote wrote: > Attached updated version of the patches addressing some of your comments > above and fixing a bug that Rajkumar reported [1]. As mentioned there, > I'm including here a patch (the 0005 of the attached) to tweak the

Re: [HACKERS] Small improvement to compactify_tuples

Sokolov Yura writes: > [ 0001-Improve-compactify_tuples.patch, v5 or thereabouts ] I started to review this patch. I spent a fair amount of time on beautifying the code, because I found it rather ugly and drastically undercommented. Once I had it to the point where

[HACKERS] Skip unneeded temp file in 'make html'

Folks, Please find attached a patch for $Subject. Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate Don't make an unneeded temp file In passing, make a slight

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

On Fri, Nov 3, 2017 at 2:24 PM, Peter Geoghegan wrote: > Thomas Munro wrote: >> That way you don't have to opt in to BufFile's >> double buffering and segmentation schemes just to get shared file >> clean-up, if for some reason you want direct file

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

Thomas Munro wrote: I'm going to make an item on my personal TODO list for that. No useful insights on that right now, though. I decided to try that, but it didn't really work: fd.h gets included by front-end code, so I can't very well define a struct and

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

On Wed, Nov 1, 2017 at 2:11 PM, Peter Geoghegan wrote: > On Tue, Oct 31, 2017 at 5:07 PM, Thomas Munro > wrote: >> Another complaint is that perhaps fd.c >> knows too much about buffile.c's business. For example, >> RemovePgTempFilesInDir() knows

Re: [HACKERS] Setting pd_lower in GIN metapage

On Fri, Nov 3, 2017 at 2:54 AM, Tom Lane wrote: > Amit Langote writes: >> On 2017/09/26 16:30, Michael Paquier wrote: >>> Cool, let's switch it back to a ready for committer status then. > >> Sure, thanks. > > Pushed with some cosmetic

Re: [HACKERS] Parallel Hash take II

On Mon, Oct 30, 2017 at 1:49 PM, Thomas Munro wrote: > A couple of stupid things outstanding: > > 1. EXPLAIN ANALYZE for Parallel Hash "actual" shows the complete row > count, which is interesting to know (or not? maybe I should show it > somewhere else?), but the

Re: [HACKERS] Linking libpq statically to libssl

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 10/27/17 08:24, Daniele Varrazzo wrote: > > I have a problem building binary packages for psycopg2. Binary > > packages ship with their own copies of libpq and libssl; > > Aside from the advice of "don't do that" ... > > >

Re: [HACKERS] [PATCH] A hook for session start

On Thu, Nov 2, 2017 at 5:42 AM, Aleksandr Parfenov < a.parfe...@postgrespro.ru> wrote: > > The following review has been posted through the commitfest application: > make installcheck-world: not tested > Implements feature: not tested > Spec compliant: not tested > Documentation:

Re: [HACKERS] SQL/JSON in PostgreSQL

On 2017-02-28 20:08, Oleg Bartunov wrote: > Attached patch is an implementation of SQL/JSON data model from SQL-2016 > standard (ISO/IEC 9075-2:2016(E)) I've faintly started looking into this. > We created repository for reviewing (ask for write access) - >

Re: [HACKERS] MERGE SQL Statement for PG11

On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote: > Nico Williams wrote: > >A MERGE mapped to a DML like this: > > This is a bad idea. An implementation like this is not at all > maintainable. Assuming the DELETE issue can be addressed, why would this not

Re: [HACKERS] pgbench - use enum for meta commands

Fabien COELHO writes: > [ pgbench-enum-meta-2.patch ] Pushed with some trivial cosmetic adjustments (pgindent changed it more than I did). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] GnuTLS support

On 09/18/2017 07:04 PM, Jeff Janes wrote:> You fixed the first issue, but I still get the second one: be-secure-gnutls.c: In function 'get_peer_certificate': be-secure-gnutls.c:667: error: 'GNUTLS_X509_CRT_LIST_SORT' undeclared (first use in this function) be-secure-gnutls.c:667: error: (Each

Re: [HACKERS] MERGE SQL Statement for PG11

Nico Williams wrote: A MERGE mapped to a DML like this: WITH updated AS ( UPDATE SET ... WHERE RETURNING ) , inserted AS ( INSERT INTO SELECT ... WHERE NOT IN (SELECT FROM updated) AND .. ON

Re: [HACKERS] MERGE SQL Statement for PG11

On Thu, Nov 02, 2017 at 02:05:19PM -0700, Peter Geoghegan wrote: > Simon Riggs wrote: > >So in your view we should make no attempt to avoid concurrent errors, > >even when we have the capability to do so (in some cases) and doing so > >would be perfectly compliant with the

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Alvaro Herrera writes: > Tom Lane wrote: >> So what would happen if we just don't summarize partial ranges? > Index scan would always have to read all the heap pages for that partial > range. Maybe not a big issue, but when you finish loading a table, it'd > be good to

Re: [HACKERS] Setting pd_lower in GIN metapage

Amit Langote writes: > On 2017/09/26 16:30, Michael Paquier wrote: >> Cool, let's switch it back to a ready for committer status then. > Sure, thanks. Pushed with some cosmetic adjustments --- mostly, making the comments more explicit about why we need the

Re: [HACKERS] MERGE SQL Statement for PG11

Simon Riggs wrote: I think people imagined you had worked out how to make MERGE run concurrently, I certainly did, but in fact you're just saying you don't believe it ever should. I'm certain that they didn't think that at all. But I'll let them speak for themselves.

Re: [HACKERS] Deadlock in ALTER SUBSCRIPTION REFRESH PUBLICATION

On 10/24/17 13:13, Konstantin Knizhnik wrote: > The reason of this deadlock seems to be clear: ALTER SUBSCRIPTION starts > transaction at one node and tries to create slot at other node, which waiting > for completion of all active transaction while building scnapshpot. > Is there any way to

Re: [HACKERS] [PATCH] Add ALWAYS DEFERRED option for constraints

On Thu, Nov 02, 2017 at 04:20:19PM -0400, Peter Eisentraut wrote: > I haven't really thought about this feature too hard; I just want to > give you a couple of code comments. Thanks! > I think the catalog structure, and relatedly also the parser structures, > could be made more compact. We

Re: [HACKERS] Linking libpq statically to libssl

On 10/27/17 08:24, Daniele Varrazzo wrote: > I have a problem building binary packages for psycopg2. Binary > packages ship with their own copies of libpq and libssl; Aside from the advice of "don't do that" ... > however if > another python package links to libssl the library will be imported >

Re: [HACKERS] Dynamic result sets from procedures

Peter Eisentraut wrote: > CREATE PROCEDURE pdrstest1() > LANGUAGE SQL > AS $$ > DECLARE c1 CURSOR WITH RETURN FOR SELECT * FROM cp_test2; > DECLARE c2 CURSOR WITH RETURN FOR SELECT * FROM cp_test3; > $$; > > CALL pdrstest1(); > > and that returns those two result sets to the client. If

Re: [HACKERS] MERGE SQL Statement for PG11

On 2 November 2017 at 19:16, Peter Geoghegan wrote: > Simon Riggs wrote: >> >> So if I understand you correctly, in your view MERGE should just fail >> with an ERROR if it runs concurrently with other DML? > > > That's certainly my opinion on the matter. It

Re: [HACKERS] MERGE SQL Statement for PG11

On Thu, Nov 02, 2017 at 12:51:45PM -0700, Peter Geoghegan wrote: > Nico Williams wrote: > >If you want to ignore conflicts arising from concurrency you could > >always add an ON CONFLICT DO NOTHING to the INSERT DML in the mapping I > >proposed earlier. Thus a MERGE

Re: [HACKERS] [PATCH] Add ALWAYS DEFERRED option for constraints

I haven't really thought about this feature too hard; I just want to give you a couple of code comments. I think the catalog structure, and relatedly also the parser structures, could be made more compact. We currently have condeferrable and condeferred to represent three valid states (NOT

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> If VACUUM and brin_summarize_new_values both ignore the partial > >> range, then what else would request this? Can't we just decree > >> that we don't summarize the partial range, period? > > >

Re: [HACKERS] MERGE SQL Statement for PG11

Simon Riggs wrote: So if I understand you correctly, in your view MERGE should just fail with an ERROR if it runs concurrently with other DML? That's certainly my opinion on the matter. It seems like that might be the consensus, too. Obviously there are things that you

Re: [HACKERS] MERGE SQL Statement for PG11

Nico Williams wrote: If you want to ignore conflicts arising from concurrency you could always add an ON CONFLICT DO NOTHING to the INSERT DML in the mapping I proposed earlier. Thus a MERGE CONCURRENTLY could just do that. Is there any reason not to map MERGE as I

Re: [HACKERS] proposal: schema variables

On Thu, Nov 02, 2017 at 11:48:44AM -0400, Tom Lane wrote: > Nico Williams writes: > > With access controls, GUCs could become schema variables, and settings > > from postgresql.conf could move into the database itself (which I think > > would be nice). > > People

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

Haribabu Kommi writes: > The changes are fine and now it reports proper live tuples in both > pg_class and stats. The other issue of continuous vacuum operation > leading to decrease of number of live tuples is not related to this > patch and that can be handled

Re: [HACKERS] MERGE SQL Statement for PG11

On Thu, Nov 02, 2017 at 06:49:18PM +, Simon Riggs wrote: > On 1 November 2017 at 18:20, Peter Geoghegan wrote: > > In Postgres, you can avoid duplicate violations with MERGE by using a > > higher isolation level (these days, those are turned into a > > serialization error at

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Alvaro Herrera writes: > Tom Lane wrote: >> If VACUUM and brin_summarize_new_values both ignore the partial >> range, then what else would request this? Can't we just decree >> that we don't summarize the partial range, period? > brin_summarize_range() can do it. So

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Tom Lane wrote: > Alvaro Herrera writes: > > 2. when summarization is requested on the partial range at the end of a > > table, we acquire extension lock on the rel, then compute relation size > > and run summarization with the lock held. This guarantees that we don't >

Re: [HACKERS] MERGE SQL Statement for PG11

If nothing else, anyone needing MERGE can port their MERGE statements to a DML with DML-containing CTEs... The generic mapping would be something like this, I think: WITH rows AS (SELECT FROM WHERE ) , updated AS ( UPDATE SET ... WHERE IN (SELECT FROM rows) /* matched */

Re: [HACKERS] MERGE SQL Statement for PG11

On 1 November 2017 at 18:20, Peter Geoghegan wrote: > In Postgres, you can avoid duplicate violations with MERGE by using a > higher isolation level (these days, those are turned into a > serialization error at higher isolation levels when no duplicate is > visible to the xact's

Re: [HACKERS] MERGE SQL Statement for PG11

Robert Haas wrote: And if, in the meantime, MERGE can only handle the cases where there is a unique index, then it can only handle the cases INSERT .. ON CONFLICT UPDATE can cover, which makes it, as far as I can see, syntactic sugar over what we already have. Maybe it's

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Alvaro Herrera writes: > 1. in VACUUM or brin_summarize_new_values, we only process fully loaded > ranges, and ignore the partial range at end of table. OK. > 2. when summarization is requested on the partial range at the end of a > table, we acquire extension lock on

Re: [HACKERS] Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Tomas Vondra wrote: > Unfortunately, I think we still have a problem ... I've been wondering > if we end up producing correct indexes, so I've done a simple test. Here's a proposed patch that should fix this problem (and does, in my testing). Would you please give it a try? This patch changes

Re: [HACKERS] initdb w/ restart

On 9/28/17 15:40, Jesper Pedersen wrote: > In a case of > > initdb /tmp/pgsql > > followed by > > pg_ctl -D /tmp/pgsql/ -l /tmp/logfile restart > > you'll get > > pg_ctl: PID file "/tmp/pgsql/postmaster.pid" does not exist > Is server running? > starting server anyway > pg_ctl: could not read

Re: [HACKERS] proposal: schema variables

On Thu, Nov 2, 2017 at 9:05 PM, Nico Williams wrote: >> Overloading SET to handle both variables and GUCs seems likely to >> create problems, possibly including security problems. For example, >> maybe a security-definer function could leave behind variables to >> trick

[HACKERS] Parallel Plans and Cost of non-filter functions

I'm working on a custom aggregate, that generates a serialized data format. The preparation of the geometry before being formatted is pretty intense, so it is probably a good thing for that work to be done in parallel, in partial aggregates. Here's an example SQL call: EXPLAIN analyze SELECT

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Nov 2, 2017 at 10:26 PM, Peter Geoghegan wrote: > On Thu, Nov 2, 2017 at 9:44 AM, Robert Haas wrote: >> The second commit (22576734b805fb0952f9be841ca8f643694ee868) is where >> I think things get a lot more dangerous. The problem (as Andres >>

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Oct 31, 2017 at 5:14 PM, Simon Riggs wrote: > I've proposed a SQL Standard compliant implementation that would do > much more than be new syntax over what we already have. > > So these two claims aren't accurate: "radical difference" and "syntax > sugar over a

Re: [HACKERS] pgbench - use enum for meta commands

On Thu, 2 Nov 2017 17:50:52 +0100 (CET) Fabien COELHO wrote: > Updated version attached. . Here is the patch. Sorry for the noise. Everything alright. Patch is ready for commiter. -- Aleksandr Parfenov Postgres Professional: http://www.postgrespro.com Russian Postgres

<    1   2   3   4   5   6   7   8   9   10   >