Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.

Hello! > 18 янв. 2018 г., в 10:48, Kyotaro HORIGUCHI > написал(а): > > Gist imposes the ninth strategy to perform index only scan but > planner is not considering that > > Please find the attached patch. I agree with you that current behavior is a bug and your patch seems correct. I'm a bit

Re: [HACKERS] Reorder header files in alphabetical order

(2018/01/18 8:10), Bruce Momjian wrote: Applied, thanks. Thanks for picking this up! Best regards, Etsuro Fujita

Re: [HACKERS] Useless code in ExecInitModifyTable

(2018/01/18 4:46), Tom Lane wrote: Pushed. I think the long delay on this is really my fault for having raised an incorrect objection initially --- apologies for that. Thanks for committing! Best regards, Etsuro Fujita

Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

(2018/01/17 22:00), Stephen Frost wrote: Reviewing this thread, I tend to agree with Etsuro and I'm not sure I see where there's a good argument for having a foreign table under a view behave differently than a local table under a view for WCO (which is an option of the view- not about the table

Re: master make check fails on Solaris 10

Victor Wagner writes: > Tom Lane wrote: >> Attached is a draft patch to incorporate Victor's slimmed-down test >> into configure. If you have a chance, could you confirm it does >> the right thing on your Sparc machine? > It seems that what it does is not exactly a right thing. > I've applied i

Re: master make check fails on Solaris 10

On Wed, 17 Jan 2018 11:33:09 -0500 Tom Lane wrote: > Attached is a draft patch to incorporate Victor's slimmed-down test > into configure. If you have a chance, could you confirm it does > the right thing on your Sparc machine? It seems that what it does is not exactly a right thing. I've appli

Re: [HACKERS] postgres_fdw bug in 9.6

(2018/01/18 7:09), Robert Haas wrote: On Wed, Jan 17, 2018 at 4:08 PM, Tom Lane wrote: It's debatable perhaps -- I tend to err in the other direction. But likewise, I don't care deeply. Just push it ... Done. Thanks for taking the time to work on this issue, Robert and Tom! Best regards,

Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.

Hello, Gist imposes the ninth strategy to perform index only scan but planner is not considering that. At Wed, 17 Jan 2018 22:26:15 +0300, Sergei Kornilov wrote in <412861516217...@web38o.yandex.ru> > Hello > I can reproduce on actual 9.6.6, 10.1 and fresh master build > (9c7d06d60680c7f00d931

Re: Test-cases for exclusion constraints is missing in alter_table.sql file

On Thu, Jan 18, 2018 at 12:00 AM, Tom Lane wrote: > Ashutosh Sharma writes: >> While working on exclusion constraints for one of our internal >> project, I noticed that there is no test-case for exclusion >> constraints in alter_table.sql file. However, for other constraints i >> could see lots o

Re: [HACKERS] replace GrantObjectType with ObjectType

On Wed, Jan 17, 2018 at 05:23:25PM -0500, Peter Eisentraut wrote: > On 1/16/18 23:38, Michael Paquier wrote: >> + if (prop->objtype == OBJECT_TABLE) >> + /* >> +* If the property data says it's a table, dig a little deeper to get >> +* the real relation kind, so that callers

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

On Wed, Jan 17, 2018 at 6:20 PM, Robert Haas wrote: > I had forgotten about the previous discussion. The sketch in my > previous email supposed that we would use dynamic barriers since the > whole point, after all, is to handle the fact that we don't know how > many participants will really show

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

On Wed, Jan 17, 2018 at 10:40 AM, Robert Haas wrote: >> While it certainly did occur to me that that was kind of weird, and I >> struggled with it on my own for a little while, I ultimately agreed >> with Thomas that it added something to have ltsConcatWorkerTapes() >> call some buffile function i

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 18 January 2018 at 00:13, David Rowley wrote: > On 17 January 2018 at 23:48, Amit Langote wrote: >> I'm concerned that after your patch to remove >> match_clauses_to_partkey(), we'd be doing more work than necessary in >> some cases. For example, consider the case of using run-time pruning >>

Re: [HACKERS] GnuTLS support

Robert Haas writes: > ... Worse yet, users are > not going to intrinsically know which SSL implementation was compiled > into the server they have. That is a really good point. For precedent, note that darn near nobody seems to know whether their psql contains readline or libedit. If we force t

Re: [HACKERS] GnuTLS support

On Wed, Jan 17, 2018 at 6:48 PM, Tomas Vondra wrote: > What would be much worse is if a particular GUC did not have a matching > concept in the library. Say if an SSL library did not have a concept of > priority strings and instead used some other concept affecting cipher > suite choice (not sure

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

On Wed, Jan 17, 2018 at 7:00 PM, Peter Geoghegan wrote: > There seems to be some yak shaving involved in getting the barrier > abstraction to do exactly what is required, as Thomas went into at the > time. How should that prerequisite work be structured? For example, > should a patch be spun off f

[patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

Please add the attached patch and this discussion to the open commit fest. The original bugs thread is here: 2018011254.1408.8...@wrigleys.postgresql.org. Bug reference: 15005 Logged by: David Gould Email address: da...@sonic.net PostgreSQL version: 10.1 and earlier Operati

Re: [PROPOSAL] Shared Ispell dictionaries

On 01/15/2018 08:02 PM, Arthur Zakirov wrote: > On Sat, Jan 13, 2018 at 10:33:14PM +0100, Tomas Vondra wrote: >> Not sure if we really need to add the database/schema OIDs. I mentioned >> the unexpected consequences (cross-db sharing) but maybe that's a >> feature we should keep (it reduces memory

Re: Setting BLCKSZ 4kB

On 01/16/2018 11:17 AM, Giuseppe Broccolo wrote: > Hi Sanyam, > > Interesting topic! > > 2018-01-16 7:50 GMT+01:00 sanyam jain >: > > Hi, > > I am trying to solve WAL flooding due to FPWs. > > > What are the cons of setting BLCKSZ as 4kB? > > >

Re: PATCH: psql tab completion for SELECT

Edmund Horner writes: > On 15 January 2018 at 15:45, Andres Freund wrote: >> All worries like this are supposed to check the server version. > In psql there are around 200 such tab completion queries, none of > which checks the server version. Many would cause the user's > transaction to abort

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

On Wed, Jan 17, 2018 at 10:27 AM, Robert Haas wrote: > On Wed, Jan 17, 2018 at 12:27 PM, Peter Geoghegan wrote: >> I think that both problems (the live _bt_parallel_scan_and_sort() bug, >> as well as the general issue with needing to account for parallel >> worker fork() failure) are likely solva

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Haribabu Kommi writes: > [ pg_dump-and-pg_dumpall-database-handling-refactoring_v12.patch ] I've gone through this in a once-over-lightly fashion. Since there was quite a bit of debate upthread about how things should work, I'd like to start by summarizing the decisions this patch has made, in c

Re: [HACKERS] GnuTLS support

On 01/17/2018 11:14 PM, Peter Eisentraut wrote: > On 1/17/18 14:05, Tom Lane wrote: >> Although these corner cases are starting to make me feel like >> changing my original vote. Maybe we should forget the prefixes, in >> particular renaming gnutls_priorities to ssl_priorities, and just >> accept

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Thu, Jan 18, 2018 at 8:25 AM, Tom Lane wrote: > Haribabu Kommi writes: > > [ pg_dump-and-pg_dumpall-database-handling-refactoring_v12.patch ] > > I started to look through this, and almost immediately found that the > diff in t/002_pg_dump.pl doesn't seem necessary --- the test passes > for m

Re: [HACKERS] Reorder header files in alphabetical order

On Thu, Nov 9, 2017 at 09:42:40PM +0900, Etsuro Fujita wrote: > Hi, > > Attached is a patch to reorder header files in joinrels.c and pathnode.c > in alphabetical order, removing unnecessary ones. Applied, thanks. -- Bruce Momjian http://momjian.us EnterpriseDB

Re: PostgreSQL crashes with SIGSEGV

On Wed, Jan 17, 2018 at 1:00 PM, Tom Lane wrote: >> You could make the same objection to changing tuplesort_getdatum() >> outside of the master branch, though. I think that going back further >> than that for the (arguably independent) tuplesort_getdatum() subset >> fix might still be a good idea.

Re: [HACKERS] replace GrantObjectType with ObjectType

On 1/16/18 23:38, Michael Paquier wrote: > It seems to me that you could just use rel->rd_rel->relkind instead of > get_rel_relkind(RelationGetRelid(rel)). right > 0004 alone fails to compile as OBJECT_RELATION is still listed in > objectaddress.c. This is corrected in 0005. Yeah, the ordering i

Re: [HACKERS] GnuTLS support

On 1/17/18 14:05, Tom Lane wrote: > Although these corner cases are starting to make me feel like changing > my original vote. Maybe we should forget the prefixes, in particular > renaming gnutls_priorities to ssl_priorities, and just accept the need > to document some parameters as only relevant

Re: [HACKERS] postgres_fdw bug in 9.6

On Wed, Jan 17, 2018 at 4:08 PM, Tom Lane wrote: > It's debatable perhaps -- I tend to err in the other direction. > But likewise, I don't care deeply. Just push it ... Done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] GnuTLS support

On 1/17/18 13:18, Tom Lane wrote: >> The proposed GnuTLS patch does make use of ssl_dh_params_file. > > Right, but what happens if say macTLS doesn't? The previously proposed patch for that also makes use of ssl_dh_params_file. So while we can't guarantee that this will be the case for all TLS i

Re: PATCH: psql tab completion for SELECT

On 15 January 2018 at 15:45, Andres Freund wrote: > On January 14, 2018 5:44:01 PM PST, Edmund Horner wrote: >>In psql if you have readline support and press TAB, psql will often >>run a DB query to get a list of possible completions to type on your >>current command line. >> >>It uses the curren

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

В письме от 3 сентября 2017 11:45:43 пользователь Alvaro Herrera написал: > The new checks around toast table creation look like they belong to a > completely independent patch also ... the error message there goes > against message style guidelines also. Offered toast relation checks as a separa

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Haribabu Kommi writes: > [ pg_dump-and-pg_dumpall-database-handling-refactoring_v12.patch ] I started to look through this, and almost immediately found that the diff in t/002_pg_dump.pl doesn't seem necessary --- the test passes for me without applying that hunk. Is that a leftover from a previ

Re: [HACKERS] postgres_fdw bug in 9.6

Robert Haas writes: > On Wed, Jan 17, 2018 at 3:37 PM, Tom Lane wrote: >> Looks OK to me. Would it be worth annotating the added regression test >> case with a comment that this once caused EPQ-related planning problems? > I tend to think somebody who is curious about the origin of any > partic

Re: [HACKERS] postgres_fdw bug in 9.6

On Wed, Jan 17, 2018 at 3:37 PM, Tom Lane wrote: > Robert Haas writes: >> Thanks for the review. Updated patch attached. > > Looks OK to me. Would it be worth annotating the added regression test > case with a comment that this once caused EPQ-related planning problems? I tend to think somebod

Re: jsonpath

On 01/15/2018 07:24 PM, Andrew Dunstan wrote: > > On 01/10/2018 05:42 PM, Nikita Glukhov wrote: >> Attached new 8th version of jsonpath related patches. Complete >> documentation is still missing. >> >> The first 4 small patches are necessary datetime handling in jsonpath: >> 1. simple refactorin

Re: PostgreSQL crashes with SIGSEGV

Peter Geoghegan writes: > On Wed, Jan 17, 2018 at 12:31 PM, Tom Lane wrote: >> +1. If the problem isn't known to be reproducible in those branches, >> the risk of adding new bugs seems to outweigh any benefit. > You could make the same objection to changing tuplesort_getdatum() > outside of the

[PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist

Hi! This patch is part of a bigger patch I've offered before https://www.postgresql.org/message-id/flat/2146419.veIEZdk4E4@x200m#2146419.veIEZdk4E4@x200m as we agreed I am trying to commit it by smaller bits This patch raises error if user tries o set or change toast.* option for a table that doe

Re: PostgreSQL crashes with SIGSEGV

On Wed, Jan 17, 2018 at 12:31 PM, Tom Lane wrote: > Probably not very. It'd be nice to have it done by the next minor > releases, ie before 5-Feb ... but given that these bugs are years > old, missing that deadline would not be catastrophic. Got it. >> I'm not sure whether or not we should also

Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

On Tue, Jan 16, 2018 at 2:00 AM, Yoshimi Ichiyanagi wrote: > C-5. Running the 2 benchmarks(1. pgbench, 2. my insert benchmark) > C-5-1. pgbench > # numactl -N 1 pgbech -c 32 -j 8 -T 120 -M prepared [DB_NAME] > > The averages of running pgbench three times are: > wal_sync_method=fdatasync: tps =

Re: [HACKERS] postgres_fdw bug in 9.6

Robert Haas writes: > Thanks for the review. Updated patch attached. Looks OK to me. Would it be worth annotating the added regression test case with a comment that this once caused EPQ-related planning problems? regards, tom lane

Re: PostgreSQL crashes with SIGSEGV

Peter Geoghegan writes: > On Wed, Jan 17, 2018 at 11:23 AM, Tom Lane wrote: >> I don't feel particularly comfortable committing a patch that >> was clearly labeled as a rushed draft by its author. >> Peter, where do you stand on this work? > I would like to take another pass over > WIP-tuplesort

Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

On Tue, Jan 16, 2018 at 2:00 AM, Yoshimi Ichiyanagi wrote: > Using pgbench which is a PostgreSQL general benchmark, the postgres server > to which the patches is applied is about 5% faster than original server. > And using my insert benchmark, it is up to 90% faster than original one. > I will des

Re: PostgreSQL crashes with SIGSEGV

On Wed, Jan 17, 2018 at 11:23 AM, Tom Lane wrote: > Aleksandr Parfenov writes: >> The new status of this patch is: Ready for Committer > > I don't feel particularly comfortable committing a patch that > was clearly labeled as a rushed draft by its author. > Peter, where do you stand on this work?

Re: proposal: alternative psql commands quit and exit

On 17 January 2018 at 15:00, I wrote: > Ctrl-C quits immediately for me no matter what input stage I'm at in > Windows' psql. Ctrl-Z (DOS EOF) only quits after enter is pressed and > only at beginning-of-line, so I'd say suggesting the user uses Ctrl-C > in windows makes sense. ^D doesn't appear to

Re: General purpose hashing func in pgbench

Hello Fabien, 17/01/2018 10:52, Fabien COELHO пишет: >> Here is a new version of patch. I've splitted it into two parts. The >> first one is almost the same as v4 from [1] with some refactoring. >> The second part introduces random_seed variable as you proposed. > > Patch 1 applies. Compilations

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Jan 17, 2018 at 5:02 PM, Claudio Freire wrote: > > > On Sat, Jan 6, 2018 at 7:35 PM, Stephen Frost wrote: > >> Greetings, >> >> * Michael Paquier (michael.paqu...@gmail.com) wrote: >> > On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire >> wrote: >> > > They did apply at the time, but I thi

Re: proposal: alternative psql commands quit and exit

On 17 Jan 2018 20:12, "Robert Haas" wrote: On Wed, Jan 17, 2018 at 10:00 AM, Geoff Winkless wrote: > On 17 January 2018 at 14:50, Tom Lane wrote: >> (I'm still not very sure which of ^C and ^D have Windows equivalents.) > > Ctrl-C quits immediately for me no matter what input stage I'm at in >

Re: proposal: alternative psql commands quit and exit

On Wed, Jan 17, 2018 at 10:00 AM, Geoff Winkless wrote: > On 17 January 2018 at 14:50, Tom Lane wrote: >> (I'm still not very sure which of ^C and ^D have Windows equivalents.) > > Ctrl-C quits immediately for me no matter what input stage I'm at in > Windows' psql. Does it kill the whole progra

Re: [HACKERS] postgres_fdw bug in 9.6

On Mon, Jan 15, 2018 at 4:38 PM, Tom Lane wrote: > There *is* a problem with GetExistingLocalJoinPath not honoring its > API spec: it will sometimes return join nests that include remote > joins at levels below the top, as I'd speculated to begin with. > This turns out not to be a problem for post

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Sat, Jan 6, 2018 at 7:35 PM, Stephen Frost wrote: > Greetings, > > * Michael Paquier (michael.paqu...@gmail.com) wrote: > > On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire > wrote: > > > They did apply at the time, but I think major work on vacuum was > > > pushed since then, and also I was tr

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Sat, Jan 6, 2018 at 7:33 PM, Stephen Frost wrote: > Greetings Claudio, > > * Michael Paquier (michael.paqu...@gmail.com) wrote: > > On Mon, Nov 27, 2017 at 2:39 PM, Jing Wang > wrote: > > > A few general comments. > > > > > > + FreeSpaceMapVacuum(onerel, 64); > > > > > > Just want to know w

Re: [HACKERS] Useless code in ExecInitModifyTable

Etsuro Fujita writes: > (2018/01/15 11:35), Amit Langote wrote: >> On 2018/01/15 11:28, Stephen Frost wrote: >>> Seems like this has gotten a review (and quite a bit of down-stream >>> discussion that seemed pretty positive), and the latest patch still >>> applies cleanly and passes the regression

Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)

On Wed, Jan 17, 2018 at 8:53 AM, Simon Riggs wrote: > At present, one major use of Cursors is in postgres_fdw. > > In that usage, the query executes and returns all the rows. No other > side execution is possible. True, although foreign tables using postgres_fdw can't be scanned in parallel for o

Re: PostgreSQL crashes with SIGSEGV

Aleksandr Parfenov writes: > The new status of this patch is: Ready for Committer I don't feel particularly comfortable committing a patch that was clearly labeled as a rushed draft by its author. Peter, where do you stand on this work? In a quick look at the patches, WIP-kludge-fix.patch seems

Re: Unnecessary static variable?

Antonin Houska writes: > Tom Lane wrote: >> At one time, I think, readLen told how much data in readBuf was >> actually valid. It seems not to be used for that anymore, but >> I don't much like the idea that readBuf is only partially filled >> but there is *no* persistent state indicating how mu

Re: [HACKERS] GnuTLS support

Magnus Hagander writes: > On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane wrote: >> What I don't want to end up with is an unholy mixture of both approaches. >> Therefore, if we are going to use method #2, we must be certain that >> the basic "ssl_" parameters are supported by every implementation, >>

Re: CREATE ROUTINE MAPPING

On Wed, Jan 17, 2018 at 11:09:19AM -0500, Corey Huinker wrote: > > > CREATE ROUTINE MAPPING local_routine_name > > > > FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode ] [ > > argname ] > > > > argtype [ { DEFAULT | = } default_expr ] [, ...] ] ) > > > >[ RETURNS rettype > > > >

Re: [HACKERS] postgres_fdw bug in 9.6

Etsuro Fujita writes: > (2018/01/16 6:38), Tom Lane wrote: >> I'm also still pretty unhappy with the amount of useless planning work >> caused by doing GetExistingLocalJoinPath during path creation. It strikes >> me that we could likely replace the entire thing with some code that just >> reconst

Re: Unnecessary static variable?

Tom Lane wrote: > Antonin Houska writes: > but your patch also does this: Yes, that should have been a separate diff. > > *** retry: > > *** 11648,11654 > > } > > > > pgstat_report_wait_start(WAIT_EVENT_WAL_READ); > > ! if (read(readFile, readBuf, XLOG_BLCKSZ) !=

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

On Mon, Jan 15, 2018 at 7:54 PM, Peter Geoghegan wrote: >> BufFileView() looks fairly pointless. It basically creates a copy of >> the input and, in so doing, destroys the input, which is a lot like >> returning the input parameter except that it uses more cycles. It >> does do a few things. > >

Re: [HACKERS] GnuTLS support

On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane wrote: > Peter Eisentraut writes: > > On 1/17/18 12:39, Tom Lane wrote: > >> I don't know too much about the internals here, so looking at your > >> list, I wonder whether "ssl_dh_params_file" ought to be treated as > >> implementation-specific too. The

Re: Test-cases for exclusion constraints is missing in alter_table.sql file

Ashutosh Sharma writes: > While working on exclusion constraints for one of our internal > project, I noticed that there is no test-case for exclusion > constraints in alter_table.sql file. However, for other constraints i > could see lots of test-cases in alter_table.sql. There are hardly 1-2 > t

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

On Wed, Jan 17, 2018 at 12:27 PM, Peter Geoghegan wrote: > I think that both problems (the live _bt_parallel_scan_and_sort() bug, > as well as the general issue with needing to account for parallel > worker fork() failure) are likely solvable by not using > tuplesort_leader_wait(), and instead cal

Re: [HACKERS] GnuTLS support

Peter Eisentraut writes: > On 1/17/18 12:39, Tom Lane wrote: >> I don't know too much about the internals here, so looking at your >> list, I wonder whether "ssl_dh_params_file" ought to be treated as >> implementation-specific too. The other four files seem essential >> to any feature-complete i

Re: Builtin connection polling

+1 to the concept... A lot of user could benefit if we did this in a good way. On Wed, Jan 17, 2018 at 8:09 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > Hi hackers, > > My recent experiments with pthread version of Postgres show that although > pthread offers some performance adv

Re: Is there a "right" way to test if a database is empty?

Graham Leggett wrote: > Hi all, > > I need to test whether a database is empty, in other words “createdb” > has been executed but no data of any kind appears in that database. Why do you want to know? Depends on how you define empty. If a few functions exist but no tables, is the database empty

Re: [HACKERS] [PATCH] Improve geometric types

> I'm not sure what you mean by the "basic comparison ops" but I'm > fine with the policy, handling each component values in the same > way with float. So point_eq_point() is right and other functions > should follow the same policy. I mean <, >, <= and >= by basic comparison operators. Operator

Re: [HACKERS] GnuTLS support

On 1/17/18 12:39, Tom Lane wrote: > I don't know too much about the internals here, so looking at your > list, I wonder whether "ssl_dh_params_file" ought to be treated as > implementation-specific too. The other four files seem essential > to any feature-complete implementation, but is that one?

Re: Package version in PG_VERSION and version()

On 1/17/18 10:14, Christoph Berg wrote: > The difference is that when parsing version() (which is all my variant > is changing), people already have to deal with extra stuff at the end > (gcc version), while that would be new for "psql --version". For me, having the package identifier in "psql -ve

Re: [HACKERS] GnuTLS support

Peter Eisentraut writes: > Question for the group: We currently have a number of config settings > named ssl_*. Some of these are specific to OpenSSL, some are not, namely: > # general > ssl > ssl_dh_params_file > ssl_cert_file > ssl_key_file > ssl_ca_file > ssl_crl_file > # OpenSSL > ssl_ciph

Re: master make check fails on Solaris 10

В Wed, 17 Jan 2018 11:33:09 -0500 Tom Lane пишет: > Attached is a draft patch to incorporate Victor's slimmed-down test > into configure. If you have a chance, could you confirm it does > the right thing on your Sparc machine? > Definitely. As soon as next work day begins in Moscow. > BTW, it

Re: [HACKERS] GnuTLS support

On 1/2/18 10:35, Peter Eisentraut wrote: > On 11/26/17 20:05, Andreas Karlsson wrote: >> I have now implemented this in the attached patch (plus added support >> for channel binding and rebased it) but I ran into one issue which I >> have not yet solved. The script for the windows version takes t

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

On Wed, Jan 17, 2018 at 5:47 AM, Amit Kapila wrote: > I could still reproduce it. I think the way you have fixed it has a > race condition. In _bt_parallel_scan_and_sort(), the value of > brokenhotchain is set after you signal the leader that the worker is > done (by incrementing workersFinished)

Re: [PATCH] Logical decoding of TRUNCATE

Hi, I reviewed 0001 in its own thread. So I think that we generally want this patch and I think the design decisions are right. Namely: TRUNCATE being treated as DELETE in terms of DML filtering makes sense to me as it is basically bulk delete, needs to be mentioned in release notes though. Add

Re: Unnecessary static variable?

Antonin Houska writes: > While reading XLogPageRead() I was surprised that readLen variable is set but > not used in the read() call. Then I realized that it's declared static > although no other function uses it. Maybe it was used earlier to exit early if > sufficient amount of data was already r

Re: Is there a "right" way to test if a database is empty?

On Wed, Jan 17, 2018 at 9:39 AM, Graham Leggett wrote: > Would it be true to say that if this query returned more than zero rows > the database is not empty? > > db=# select distinct s.nspname from pg_class c join pg_namespace s on > s.oid = c.relnamespace where s.nspname not in ('pg_toast','info

Re: Is there a "right" way to test if a database is empty?

On 17 Jan 2018, at 6:34 PM, David G. Johnston wrote: > ​That was my original thought - though comparing the size of template1 to the > target database should be reasonably safe... > > If you do go for object detection you will want to ensure that no schemas > other than public exist in additi

Re: Is there a "right" way to test if a database is empty?

On Wed, Jan 17, 2018 at 9:10 AM, Graham Leggett wrote: > > db=# select count(s.nspname) from pg_class c join pg_namespace s on s.oid > = c.relnamespace where s.nspname in ('public'); > count > --- > 0 > (1 row) > > It is based on the idea that the database is not empty if there are any

Re: master make check fails on Solaris 10

Attached is a draft patch to incorporate Victor's slimmed-down test into configure. If you have a chance, could you confirm it does the right thing on your Sparc machine? BTW, it would be a good idea to set up a buildfarm member on that machine, if you care about whether that configuration contin

Re: [PATCH] session_replication_role = replica with TRUNCATE

Hi, On 02/01/18 17:16, Marco Nenciarini wrote: > Hi, > > I've tried to amend the documentation to be more clear. Feel free to > suggest further editing. Patch v2 attached. > I think the patch as is now looks okay. So marking as ready for committer. This is noteworthy for the release notes thou

Re: Is there a "right" way to test if a database is empty?

On 17 Jan 2018, at 5:47 PM, Graham Leggett wrote: > I need to test whether a database is empty, in other words “createdb” has > been executed but no data of any kind appears in that database. > > What is the correct postgresql way to do this? > > Is there a pg_isempty command or equivalent som

Re: CREATE ROUTINE MAPPING

> > CREATE ROUTINE MAPPING local_routine_name > > > FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode ] [ > argname ] > > > argtype [ { DEFAULT | = } default_expr ] [, ...] ] ) > > >[ RETURNS rettype > > > | RETURNS TABLE ( column_name column_type [, ...] ) ] > > > SERVER foreig

Builtin connection polling

Hi hackers, My recent experiments with pthread version of Postgres show that although pthread offers some performance advantages comparing with processes for large number of connections, them still can not eliminate need in connection pooling. Large number even of inactive connections cause s

Re: Is there a "right" way to test if a database is empty?

On 17 Jan 2018, at 6:01 PM, pinker wrote: > I always do: \l+ and then you can compare the size: new_one | postgres | UTF8 > | en_US.UTF-8 | en_US.UTF-8 | | 7869 kB | pg_default | template0 | postgres | > UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +| 7869 kB | pg_default | | | > | | postgre

Re: Is there a "right" way to test if a database is empty?

I always do:\l+and then you can compare the size:new_one | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | *7869 kB* | pg_default | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +| *7869 kB* | pg_default | |

Re: master make check fails on Solaris 10

On 17-01-2018 18:28, Tom Lane wrote: BTW, now that you've demonstrated that the bug exists in a current gcc release, you should definitely file a bug at https://gcc.gnu.org/bugzilla/ I think you can just give them int128test2.c as-is as a test case. Please do that and let me know the PR number -

Re: master make check fails on Solaris 10

Marina Polyakova writes: > On 17-01-2018 18:07, Tom Lane wrote: >> Yeah, I can work with this. What I propose to do is use a somewhat >> stripped-down version of this test as an AC_RUN_IFELSE test normally, >> but if cross-compiling, fall back to just seeing if we can link. > Thanks, I'll try to

Is there a "right" way to test if a database is empty?

Hi all, I need to test whether a database is empty, in other words “createdb” has been executed but no data of any kind appears in that database. What is the correct postgresql way to do this? Is there a pg_isempty command or equivalent somewhere? Regards, Graham — smime.p7s Description: S/

Re: master make check fails on Solaris 10

On 17-01-2018 18:07, Tom Lane wrote: Marina Polyakova writes: investigating the regression diffs, we found out that the error occurs when we pass int128 as not the first argument to the function (perhaps its value is replaced by the value of some address): ... Based on this, we modified the tes

Re: master make check fails on Solaris 10

Victor Wagner writes: > I'm attaching stripped-down version of test program, which demonstrate > the problem and two assembler listings produced with this C source using > alignment 8 and 16. May be this stripped-down version can be used as > base for configure test. Ah, thanks, this will be eas

Re: master make check fails on Solaris 10

Victor Wagner writes: > On Wed, 17 Jan 2018 10:07:37 -0500 > Tom Lane wrote: >> Yeah, I can work with this. What I propose to do is use a somewhat >> stripped-down version of this test as an AC_RUN_IFELSE test normally, >> but if cross-compiling, fall back to just seeing if we can link. > I'd s

Re: master make check fails on Solaris 10

On Wed, 17 Jan 2018 10:07:37 -0500 Tom Lane wrote: > Marina Polyakova writes: > Yeah, I can work with this. What I propose to do is use a somewhat > stripped-down version of this test as an AC_RUN_IFELSE test normally, > but if cross-compiling, fall back to just seeing if we can link. I'd sug

Re: master make check fails on Solaris 10

BTW, now that you've demonstrated that the bug exists in a current gcc release, you should definitely file a bug at https://gcc.gnu.org/bugzilla/ I think you can just give them int128test2.c as-is as a test case. Please do that and let me know the PR number --- I think it would be good to cite the

Re: Package version in PG_VERSION and version()

Re: Tom Lane 2018-01-17 <16522.1516201...@sss.pgh.pa.us> > I wrote: > > Yeah, but the same argument could be made against the variant > > you're proposing. In theory, people could have written arbitrarily > > brittle checks of version numbers/strings. I'm not exactly convinced > > that it's your

Re: master make check fails on Solaris 10

On Wed, 17 Jan 2018 18:02:26 +0300 Marina Polyakova wrote: > > Attached is a possible test program. I can confirm it passes on a > > machine with working __int128, but I have no idea whether it will > > detect the problem on yours. If not, maybe you can tweak it? > > Thank you! Using gcc 5.5.

Re: master make check fails on Solaris 10

Sorry, diff.patch is attached now. On 17-01-2018 18:02, Marina Polyakova wrote: [I added Victor Wagner as co-researcher of this problem] On 13-01-2018 21:10, Tom Lane wrote: In the end this might just be an instance of the old saw about avoiding dot-zero releases. Have you tried a newer gcc?

Re: master make check fails on Solaris 10

Marina Polyakova writes: > investigating the regression diffs, we found out that the error occurs > when we pass int128 as not the first argument to the function (perhaps > its value is replaced by the value of some address): > ... > Based on this, we modified the test program (see attached). He

Re: Package version in PG_VERSION and version()

I wrote: > Yeah, but the same argument could be made against the variant > you're proposing. In theory, people could have written arbitrarily > brittle checks of version numbers/strings. I'm not exactly convinced > that it's your (or our) problem if they did. BTW, as concrete evidence in this ar

Re: master make check fails on Solaris 10

[I added Victor Wagner as co-researcher of this problem] On 13-01-2018 21:10, Tom Lane wrote: In the end this might just be an instance of the old saw about avoiding dot-zero releases. Have you tried a newer gcc? (Digging in their bugzilla finds quite a number of __int128 bugs fixed in 5.4.x, t

  1   2   >