Re: [HACKERS] Enhancements to passwordcheck

2017-09-29 Thread Albe Laurenz
Michael Paquier wrote: > On Thu, Sep 28, 2017 at 12:06 AM, Alvaro Herrera > wrote: >> I think the passwordcheck module as a whole is a dead end, security- >> wise. Myself, I've never seen the point in it. It runs at the wrong >> time, and there's no way to fix that. >

Re: [HACKERS] Enhancements to passwordcheck

2017-09-27 Thread Albe Laurenz
Nathan Bossart wrote: >> As was pointed out in the original discussion >> d960cb61b694cf459dcfb4b0128514c203937...@exadv11.host.magwien.gv.at >> the weak point of "passwordcheck" is that it does not work very well >> for encrypted passwords. >> The only saving grace is that you can at least check

Re: [HACKERS] Enhancements to passwordcheck

2017-09-26 Thread Albe Laurenz
Nathan Bossart wrote: >>> passwordcheck.force_new_password >>> >> Does it mean a password different from the old one? +1. It could be >> different from the last 3 passwords but we don't store a password >> history. > > Yes. As Michael pointed out, this might be better to do as a separate

Re: [HACKERS] On Complex Source Code Reading Strategy

2017-07-26 Thread Albe Laurenz
Zeray Kalayu wrote: > I want to be PG hacker but it seems a complex beast to find my way out in it. > So, can anyone suggest me from his experience/style the general > approaches/techniques/strategies on how to read complex source code in > general and PG in particular effectively. > > Can you

[HACKERS] Typo in comment in postgres_fdw.c

2017-06-28 Thread Albe Laurenz
Attached is a fix for a small typo I found. Yours, Laurenz Albe comment.patch Description: comment.patch -- 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] Logical replication: stuck spinlock at ReplicationSlotRelease

2017-06-23 Thread Albe Laurenz
Peter Eisentraut wrote: > On 6/21/17 09:02, Albe Laurenz wrote: >> 2017-06-21 14:55:12.033 CEST [23124] LOG: could not send data to client: >> Broken pipe >> 2017-06-21 14:55:12.033 CEST [23124] FATAL: connection to client lost >> 2017-06-21 14:55:17.032 CEST [23133

Re: [HACKERS] Logical replication in the same cluster

2017-06-21 Thread Albe Laurenz
Tom Lane wrote: > Petr Jelinek writes: >> On 26/04/17 18:59, Bruce Momjian wrote: >>> ... it just hangs. My server logs say: > >> Yes that's result of how logical replication slots work, the transaction >> that needs to finish is your transaction. It can be worked

[HACKERS] Logical replication: stuck spinlock at ReplicationSlotRelease

2017-06-21 Thread Albe Laurenz
While playing with HEAD as of d14c85ed, I ran into the following: CREATE DATABASE source; CREATE DATABASE recipient; \c source CREATE TABLE repli(id integer PRIMARY KEY, val text NOT NULL); INSERT INTO repli VALUES (1, 'one'); CREATE PUBLICATION repsend FOR TABLE repli; SELECT

Re: [HACKERS] Index created in BEFORE trigger not updated during INSERT

2017-06-06 Thread Albe Laurenz
Tom Lane wrote: >> Andres Freund writes: >>> Hm, strategically sprinkled CheckTableNotInUse() might do the trick? > > Attached is a proposed patch that closes off this problem. I've tested > it to the extent that it blocks Albe's example and passes check-world. I tested it,

[HACKERS] Index created in BEFORE trigger not updated during INSERT

2017-05-22 Thread Albe Laurenz
Not that it is a useful use case, but I believe that this is a bug that causes index corruption: CREATE TABLE mytable( id integer PRIMARY KEY, id2 integer NOT NULL ); CREATE FUNCTION makeindex() RETURNS trigger LANGUAGE plpgsql AS $$BEGIN CREATE INDEX ON mytable(id2); RETURN NEW;

Re: [HACKERS] password_encryption, default and 'plain' support

2017-05-05 Thread Albe Laurenz
Tom Lane wrote: > Robert Haas writes: >> On Wed, May 3, 2017 at 7:31 AM, Heikki Linnakangas wrote: >>> So, I propose that we remove support for password_encryption='plain' in >>> PostgreSQL 10. If you try to do that, you'll get an error. >> I have no idea

Re: [HACKERS] CTE inlining

2017-05-05 Thread Albe Laurenz
Thomas Kellerer wrote: >> 1) we switch unmarked CTEs as inlineable by default in pg11. > > +1 from me for option 1 +1 from me as well, FWIW. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together

2017-02-01 Thread Albe Laurenz
Andrew Dunstan wrote: > On 01/29/2017 04:07 PM, David Rowley wrote: >> Looks like there's a few other usages of CountDBBackends() which >> require background workers to be counted too, so I ended up creating >> CountDBConnections() as I didn't really think adding a bool flag to >> CountDBBackends

Re: [HACKERS] ISO/IEC 9075-2:2016 for postgres community

2017-01-19 Thread Albe Laurenz
Wolfgang Wilhelm wrote: > are you looking for something like this: > jtc1sc32.org/doc/N2301-2350/32N2311T-text_for_ballot-CD_9075-2.pdf ? That looks like it is from 2013... Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together

2017-01-11 Thread Albe Laurenz
Amit Kapila wrote: > On Wed, Jan 11, 2017 at 2:44 AM, David Rowley > wrote: >> It has come to my attention that when a user has a CONNECTION LIMIT >> set, and they make use of parallel query, that their queries can fail >> due to the connection limit being exceeded.

Re: [HACKERS] Parallel execution and prepared statements

2016-12-05 Thread Albe Laurenz
Tobias Bussmann wrote: >> I think if we don't see any impact then we should backpatch this >> patch. However, if we decide to go some other way, then I can provide >> a separate patch for back branches. BTW, what is your opinion? > > I could not find anything on backporting guidelines in the

Re: [HACKERS] Parallel execution and prepared statements

2016-11-29 Thread Albe Laurenz
Amit Kapila wrote: >> But with Tobias' complete patch "make installcheck-world" succeeds. > > Okay. I have looked into patch proposed and found that it will > resolve the regression test problem (Create Table .. AS Execute). I > think it is slightly prone to breakage if tomorrow we implement

Re: [HACKERS] UNDO and in-place update

2016-11-23 Thread Albe Laurenz
Robert Haas wrote: > To implement this in PostgreSQL, I believe we would need support for > UNDO. > - Reading a page that has been recently modified gets significantly > more expensive; it is necessary to read the associated UNDO entries > and do a bunch of calculation that is significantly more

Re: [HACKERS] Parallel execution and prepared statements

2016-11-21 Thread Albe Laurenz
Robert Haas wrote: >>/* creates a parallel-enabled plan */ >>PQprepare(conn, "pstmt", "SELECT id FROM l WHERE val = $1", 1, NULL); >>/* blows up with "cannot insert tuples during a parallel operation" */ >>PQexec(conn, "CREATE TABLE bad(id) AS EXECUTE pstmt('abcd')"); > > Ouch. I

Re: [HACKERS] Parallel execution and prepared statements

2016-11-18 Thread Albe Laurenz
Amit Kapila wrote: > Can you once test by just passing CURSOR_OPT_PARALLEL_OK in > PrepareQuery() and run the tests by having forc_parallel_mode=regress? > It seems to me that the code in the planner is changed for setting a > parallelModeNeeded flag, so it might work as it is. No, that doesn't

Re: [HACKERS] Parallel execution and prepared statements

2016-11-18 Thread Albe Laurenz
Robert Haas wrote: > On Tue, Nov 15, 2016 at 10:41 AM, Albe Laurenz <laurenz.a...@wien.gv.at> > wrote: >> Tobias Bussmann has discovered an oddity with prepared statements. >> >> Parallel scan is used with prepared statements, but only if they have >>

[HACKERS] Parallel execution and prepared statements

2016-11-15 Thread Albe Laurenz
Tobias Bussmann has discovered an oddity with prepared statements. Parallel scan is used with prepared statements, but only if they have been created with protocol V3 "Parse". If a prepared statement has been prepared with the SQL statement PREPARE, it will never use a parallel scan. I guess

Re: [HACKERS] pg_dump, pg_dumpall and data durability

2016-11-14 Thread Albe Laurenz
Michael Paquier wrote: > Meh. I forgot docs and --help output updates. Looks good, except that you left the "N" option in the getopt_long call for pg_dumpall. I fixed that in the attached patch. I'll mark the patch "ready for committer". Yours, Laurenz Albe pgdump-sync-v5.patch Description:

Re: [HACKERS] pg_dump, pg_dumpall and data durability

2016-11-11 Thread Albe Laurenz
Michael Paquier wrote: > A typo s/pre_fsync_fname/pre_sync_fname, and a mistake from me because > I did not compile with -DPG_FLUSH_DATA_WORKS to check this code. > > v2 is attached, fixing those issues. The patch applies and compiles fine. I have tested it on Linux and MinGW and could see the

Re: [HACKERS] pg_dump, pg_dumpall and data durability

2016-11-07 Thread Albe Laurenz
Michael Paquier wrote: >> In my quest of making the backup tools more compliant to data >> durability, here is a thread for pg_dump and pg_dumpall. > > Okay, here is a patch doing the above. I have added a new --nosync > option to pg_dump and pg_dumpall to switch to the pre-10 behavior. I > have

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-11-07 Thread Albe Laurenz
Tom Lane wrote: >> Albe Laurenz <laurenz.a...@wien.gv.at> writes: >>> Anyway, I have prepared a patch along the lines you suggest. >> >> Pushed, we'll see if the buildfarm likes this iteration any better. > > And the answer is "not very much&quo

Re: [HACKERS] sequential scan result order vs performance

2016-10-31 Thread Albe Laurenz
Jim Nasby wrote: > On 10/30/16 9:12 AM, Tom Lane wrote: >> I think there will be a lot of howls. People expect that creating >> a table by inserting a bunch of rows, and then reading back those >> rows, will not change the order. We already futzed with that guarantee >> a bit with syncscans, but

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-25 Thread Albe Laurenz
I wrote: > Anyway, I have prepared a patch along the lines you suggest. It occurred to me that the documentation still suggests that you should add a declaration to a C function; I have fixed that too. I'll add the patch to the next commitfest. Yours, Laurenz Albe

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-24 Thread Albe Laurenz
Tom Lane wrote: > I poked at this a little bit. AFAICT, the only actual cross-file > references are in contrib/ltree/, which has quite a few. Maybe we > could hold our noses and attach PGDLLEXPORT to the declarations in > ltree.h. > > hstore's HSTORE_POLLUTE macro would also need

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-18 Thread Albe Laurenz
Tom Lane wrote: > No, it's cross *file* references within a single contrib module that > would be likely to need extern declarations in a header file. That's > not especially weird IMO. I'm not sure how many cases there actually > are though. I went through the contrib moules and tried to look

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-17 Thread Albe Laurenz
I wrote: > But I'd understand if you think that this is too much code churn for too > little > benefit, even if it could be considered a clean-up. > > In that case, I'd argue that in the sample in doc/src/sgml/xfunc.sgml > the function definitions should be changed to read > > PGDLLEXPORT

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-14 Thread Albe Laurenz
Tom Lane wrote: >> Well, the buildfarm doesn't like that even a little bit. It seems that >> the MSVC compiler does not like seeing both "extern Datum foo(...)" and >> "extern PGDLLEXPORT Datum foo(...)", so anything that had an extern in >> a .h file is failing. There is also quite a bit of

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Albe Laurenz
Tom Lane wrote: > I'm okay with adding PGDLLEXPORT to the extern, but we should update > that comment to note that it's not necessary with any of our standard > Windows build processes. (For that matter, the comment fails to explain > why this macro is providing an extern for the base function at

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Albe Laurenz
Tom Lane wrote: >> PostgreSQL itself seems to use export files that explicitly declare the >> exported symbols, so it gets away without these decorations. > > Except that we don't. There aren't PGDLLEXPORT markings for any > functions exported from contrib modules, and we don't use dlltool > on

Re: [HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Albe Laurenz
Tom Lane wrote: > Albe Laurenz <laurenz.a...@wien.gv.at> writes: >> Currently, PG_FUNCTION_INFO_V1 is defined as [...] > >> Is there a good reason why the "funcname" declaration is not decorated >> with PGDLLEXPORT? > > The lack of complaints about

[HACKERS] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

2016-10-12 Thread Albe Laurenz
Currently, PG_FUNCTION_INFO_V1 is defined as /* * Macro to build an info function associated with the given function name. * Win32 loadable functions usually link with 'dlltool --export-all', but it * doesn't hurt to add PGDLLIMPORT in case they don't. */ #define

[HACKERS] Nested loop join condition does not get pushed down to foreign scan

2016-09-13 Thread Albe Laurenz
I just noticed something surprising: -- create a larger local table CREATE TABLE llarge (id integer NOT NULL, val integer NOT NULL); INSERT INTO llarge SELECT i, i%100 FROM generate_series(1, 1) i; ALTER TABLE llarge ADD PRIMARY KEY (id); -- create a small local table CREATE TABLE small (id

Re: [HACKERS] Documentation fix for CREATE FUNCTION

2016-07-15 Thread Albe Laurenz
Tom Lane wrote: > Albe Laurenz <laurenz.a...@wien.gv.at> writes: >> I just noticed that the documentation for CREATE FUNCTION still mentions >> that the temporary namespace is searched for functions even though that >> has been removed with commit aa27977. > > T

[HACKERS] Documentation fix for CREATE FUNCTION

2016-07-13 Thread Albe Laurenz
I just noticed that the documentation for CREATE FUNCTION still mentions that the temporary namespace is searched for functions even though that has been removed with commit aa27977. Attached is a patch to fix that. Yours, Laurenz Albe

Re: [HACKERS] to_date_valid()

2016-07-05 Thread Albe Laurenz
Andreas Karlsson wrote: > On 07/04/2016 10:55 PM, Pavel Stehule wrote: >> 2016-07-04 22:15 GMT+02:00 Andreas Karlsson wrote: >>> I do not see a clear conclusion in the linked threads. For example >>> Bruce calls it a bug in one of the emails >>>

Re: [HACKERS] Bug in to_timestamp().

2016-06-20 Thread Albe Laurenz
Tom Lane wrote: > I don't necessarily have an opinion yet. I would like to see more than > just an unsupported assertion about what Oracle's behavior is. Also, > how should FM mode affect this? I can supply what Oracle 12.1 does: SQL> SELECT to_timestamp('2016-06-13 15:43:36', ' /MM/DD

Re: [HACKERS] Using FDW AddForeignUpdateTargets for a hidden pseudo-column

2016-06-14 Thread Albe Laurenz
Aleksey Demakov wrote: > I have a data store where tuples have unique identities that normally are not > visible. > I also have a FDW to work with this data store. As per the docs to implement > updates > for this data store I have AddForeignUpdateTargets() function that adds an > artificial >

Re: [HACKERS] Prepared statements and generic plans

2016-06-14 Thread Albe Laurenz
Bruce Momjian wrote: > However, for the wire protocol prepare/execute, how do you do EXPLAIN? > The only way I can see doing it is to put the EXPLAIN in the prepare > query, but I wasn't sure that works. So, I just wrote and tested the > attached C program and it properly output the explain

Re: [HACKERS] Prepared statements and generic plans

2016-06-13 Thread Albe Laurenz
Bruce Momjian wrote: > Also, is it possible to do an EXPLAIN prepare() with the libpq/wire > protocol? I can't do PREPARE EXPLAIN, but I can do EXPLAIN EXECUTE. > However, I don't see any way to inject EXPLAIN into the libpq/wire > prepare case. Can you specify prepare(EXPLAIN SELECT)? (PREPARE

Re: [HACKERS] Prepared statements and generic plans

2016-06-07 Thread Albe Laurenz
Bruce Momjian wrote: >> !distinct column values, a generic plan assumes a column equality >> !comparison will match 33% of processed rows. Column statistics >> >> ... assumes *that* a column equality comparison will match 33% of *the* >> processed rows. > > Uh, that seems overly wordy.

Re: [HACKERS] Prepared statements and generic plans

2016-06-06 Thread Albe Laurenz
Bruce Momjian wrote: > OK, updated version attached. I added "potential" to the first > paragraph, and added "estimated cost" to the later part, fixed the > "cheaper than", and clarified that we add the plan time cost to the > non-generic plan, which is how it can be cheaper than the generic

Re: [HACKERS] Prepared statements and generic plans

2016-06-03 Thread Albe Laurenz
David G. Johnston wrote: > On Thu, Jun 2, 2016 at 9:56 PM, Bruce Momjian wrote: >> In Postgres 9.2 we improved the logic of when generic plans are used by >> EXECUTE. We weren't sure how well it would work, and the docs included >> a vague description on when generic plans are

Re: [HACKERS] Rename max_parallel_degree?

2016-06-03 Thread Albe Laurenz
Robert Haas wrote: > On Wed, Jun 1, 2016 at 5:29 PM, Tom Lane wrote: > > Robert Haas writes: > >> I've largely given up hope of coming up with an alternative that can > >> attract more than one vote and that is also at least mildly accurate, > >> but

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-13 Thread Albe Laurenz
Pavel Stehule wrote: > I like a strategy based on risks. Probably there are situation, when the > generic plan is great every > time - INSERTs, UPDATEs via PK, simple SELECTs via PK. generic plan can be > well if almost all data has > similar probability. Elsewhere on bigger data, the

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-12 Thread Albe Laurenz
Vladimir Sitnikov wrote: > Here's the simplified testcase: > https://gist.github.com/vlsi/df08cbef370b2e86a5c1 > > It reproduces the problem in both 9.4.4 and 9.5rc1. > It is reproducible via both psql and pgjdbc. > > I use a single table, however my production case includes a join of > two

Re: [HACKERS] Experimental evaluation of PostgreSQL's query optimizer

2015-12-21 Thread Albe Laurenz
Viktor Leis wrote: > We have recently performed an experimental evaluation of PostgreSQL's > query optimizer. For example, we measured the contributions of > cardinality estimation and the cost model on the overall query > performance. You can download the resulting paper here: >

Re: [HACKERS] Costing foreign joins in postgres_fdw

2015-12-19 Thread Albe Laurenz
Robert Haas wrote: >> Maybe, to come up with something remotely realistic, a formula like >> >> sum of locally estimated costs of sequential scan for the base table >> plus count of estimated result rows (times a factor) > > Was this meant to say "the base tables", plural? Yes. > I think

Re: [HACKERS] Costing foreign joins in postgres_fdw

2015-12-18 Thread Albe Laurenz
Ashutosh Bapat wrote: > Costs for foreign queries are either obtained from the foreign server using > EXPLAIN (if > use_remote_estimate is ON) otherwise they are cooked up locally based on the > statistics available. For > joins as well, we have to do the same. If use_remote_estimates [1] is ON,

Re: [HACKERS] Fdw cleanup

2015-12-14 Thread Albe Laurenz
Feng Tian wrote: > I need some help to understand foreign table error handling. > > For a query on foreign table, ExecInitForeignScan is called, which in turn > calls the BeginForeignScan > hook. Inside this hook, I allocated some resource, > > > node->fdw_state = allocate_resource(...); >

Re: [HACKERS] Disabling an index temporarily

2015-12-12 Thread Albe Laurenz
Tatsuo Ishii wrote: >> Wouldn't something like: >> >> ALTER INDEX foo SET DISABLED; >> >> See more in line with our grammar? > > But this will affect other sessions, no? Not if it is used in a transaction that ends with a ROLLBACK, but then you might as well use DROP INDEX, except that DROP INDEX

Re: [HACKERS] Errors in our encoding conversion tables

2015-11-27 Thread Albe Laurenz
Tom Lane wrote: > There's a discussion over at > http://www.postgresql.org/message-id/flat/2sa.dhu5.1hk1yrptnfy.1ml...@seznam.cz > of an apparent error in our WIN1250 -> LATIN2 conversion. I looked into this > and found that indeed, the code will happily translate certain characters > for which

Re: [HACKERS] Git cartoon

2015-11-09 Thread Albe Laurenz
Fabrízio de Royes Mello wrote: > Em domingo, 8 de novembro de 2015, Bruce Momjian escreveu: >> This git cartoon was too funny not to share: >> >> http://xkcd.com/1597/ >> >> Maybe we need it on our git wiki page. ;-) > > I think we need our own cartoon with a funny

Re: [HACKERS] [PATCH] RFC: Add length parameterised dmetaphone functions

2015-11-06 Thread Albe Laurenz
Christian Marie wrote: > A developer I work with was trying to use dmetaphone to group people names > into > equivalence classes. He found that many long names would be grouped together > when they shouldn't be, this turned out to be because dmetaphone has an > undocumented upper bound on its

[HACKERS] Documentation fix for psql

2015-11-03 Thread Albe Laurenz
The psql documentation calls the \pset options unicode_*_style when in reality they are called unicode_*_linestyle. This should be backpatched to 9.5. Yours, Laurenz Albe 0001-Fix-documentation-for-pset-unicode_-_linestyle.patch Description:

[HACKERS] Documentation for min_wal_size and max_wal_size

2015-10-20 Thread Albe Laurenz
Wouldn't it be better to have these two parameters documented next to each other, as in the attached patch? Yours, Laurenz Albe 0001-Move-documentation-for-min_wal_size-before-max_wal_s.patch Description: 0001-Move-documentation-for-min_wal_size-before-max_wal_s.patch -- Sent via

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

2015-10-16 Thread Albe Laurenz
Shay Rojansky wrote: > Just to give some added reasoning... > > As Andres suggested, Npgsql sends ssl_renegotiation_limit=0 because we've > seen renegotiation bugs with > the standard .NET SSL implementation (which Npgsql uses). Seems like everyone > has a difficult time > with renegotiation.

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

2015-09-22 Thread Albe Laurenz
Peter Geoghegan wrote: > On Mon, Sep 21, 2015 at 9:32 PM, Erik Rijkers wrote: >> I think this compulsive 'he'-avoiding is making the text worse. >> >> >> - environment variable); any user can make such a change for his >> session. >> + environment variable); any user

Re: [HACKERS] Horizontal scalability/sharding

2015-09-02 Thread Albe Laurenz
Etsuro Fujita wrote: > On 2015/09/02 16:40, Amit Langote wrote: >> On 2015-09-02 PM 04:07, Albe Laurenz wrote: >>> Amit Langote wrote: >>>> On 2015-09-02 PM 03:25, Amit Kapila wrote: >>>>> Will it handle deadlocks across different table partitions. C

Re: [HACKERS] Horizontal scalability/sharding

2015-09-02 Thread Albe Laurenz
Amit Langote wrote: > On 2015-09-02 PM 03:25, Amit Kapila wrote: >> Will it handle deadlocks across different table partitions. Consider >> a case as below: >> >> T1 >> 1. Updates row R1 of T1 on shard S1 >> 2. Updates row R2 of T2 on shard S2 >> >> T2 >> 1. Updates row R2 of T2 on shard S2 >> 2.

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

2015-08-19 Thread Albe Laurenz
Victor Wagner wrote: I wonder how useful this is at the present time. If the primary goes down and the client gets connected to the standby, it would have read-only access there. Most applications wouldn't cope well with that. It is supposed that somebody (either system administrator or

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

2015-08-19 Thread Albe Laurenz
Victor Wagner wrote: Idea is that we don't need any extra administration actions such as IP migration to do it. Clients have list of alternate servers and discover which one to work with by trial and error. Yes, but that will only work reliably if the (read-only) standby does not

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

2015-08-18 Thread Albe Laurenz
Hans-Jürgen Schönig wrote: in addition to that you have the “problem” of transactions. if you failover in the middle of a transaction, strange things might happen from the application point of view. the good thing, however, is that stupid middleware is sometimes not able to handle

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

2015-08-18 Thread Albe Laurenz
Victor Wagner wrote: Rationale = Since introduction of the WAL-based replication into the PostgreSQL, it is possible to create high-availability and load-balancing clusters. However, there is no support for failover in the client libraries. So, only way to provide transparent for

Re: [HACKERS] Autonomous Transaction is back

2015-08-17 Thread Albe Laurenz
Noah Misch wrote: If the autonomous transaction can interact with uncommitted work in a way that other backends could not, crazy things happen when the autonomous transaction commits and the suspended transaction aborts: CREATE TABLE t (c) AS SELECT 1; BEGIN; UPDATE t SET c =

Re: [HACKERS] [NOVICE] psql readline Tab insert tab

2015-06-02 Thread Albe Laurenz
Peter Eisentraut wrote: On 6/1/15 7:00 AM, Albe Laurenz wrote: Hans Ginzel wrote: how to make psql (readline) to insert tab when Tab is pressed? E.g. for pasting. I know, there is -n option. But then the history is not accessible. It could be done by adding the following lines to your

Re: [HACKERS] [NOVICE] psql readline Tab insert tab

2015-06-01 Thread Albe Laurenz
Hans Ginzel wrote: how to make psql (readline) to insert tab when Tab is pressed? E.g. for pasting. I know, there is -n option. But then the history is not accessible. It could be done by adding the following lines to your ~/.inputrc file: $if Psql TAB: tab-insert $endif Great! Thank

Re: [HACKERS] 9.5 release notes may need ON CONFLICT DO NOTHING compatibility notice for FDW authors

2015-05-26 Thread Albe Laurenz
Peter Geoghegan wrote: In any case, third party foreign data wrappers that target other database system will totally ignore ON CONFLICT DO NOTHING when built against the master branch (unless they consider these questions). They should perhaps make a point of rejecting DO NOTHING outright

Re: [HACKERS] Rounding to even for numeric data type

2015-03-30 Thread Albe Laurenz
Michael Paquier wrote: Well, I am not sure about that... But reading this thread changing the default rounding sounds unwelcome. So it may be better to just put in words the rounding method used now in the docs, with perhaps a mention that this is not completely in-line with the SQL spec if

Re: [HACKERS] MD5 authentication needs help

2015-03-06 Thread Albe Laurenz
Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Bruce Momjian br...@momjian.us writes: Let me update my list of possible improvements: 1) MD5 makes users feel uneasy (though our usage is mostly safe) 2) The per-session salt sent to the client is only 32-bits, meaning that it

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

2015-03-03 Thread Albe Laurenz
Etsuro Fujita wrote: While updating the patch, I noticed that in the previous patch, there is a bug in pushing down parameterized UPDATE/DELETE queries; generic plans for such queries fail with a can't-happen error. I fixed the bug and tried to add the regression tests that execute the

Re: [HACKERS] SSL renegotiation

2015-02-23 Thread Albe Laurenz
Florian Weimer wrote: On 02/22/2015 02:05 PM, Andres Freund wrote: On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote: I honestly wonder why postgres uses renegotiation at all. The motivation that cryptoanalysis is easier as more data is sent seems quite far-fetched. I don't think so.

Re: [HACKERS] POLA violation with \c service=

2014-12-17 Thread Albe Laurenz
David Fetter wrote: I've noticed that psql's \c function handles service= requests in a way that I can only characterize as broken. This came up in the context of connecting to a cloud hosting service named after warriors or a river or something, whose default hostnames are long,

Re: [HACKERS] Using RTLD_DEEPBIND to handle symbol conflicts in loaded libraries

2014-11-26 Thread Albe Laurenz
Ants Aasma wrote: I had to make oracle_fdw work with PostgreSQL compiled using --with-ldap. The issue there is that Oracle's client library has the delightful property of linking against a ldap library they bundle that has symbol conflicts with OpenLDAP. At PostgreSQL startup libldap is

Re: [HACKERS] Functions used in index definitions shouldn't be changed

2014-11-21 Thread Albe Laurenz
Robert Haas wrote: On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote: I don't think that there is a universally compelling right or wrong to questions like this, it is more a matter of taste. Is it more important to protect the casual DBA from hurting himself

Re: [HACKERS] Functions used in index definitions shouldn't be changed

2014-11-20 Thread Albe Laurenz
Tom Lane wrote: Antonin Houska a...@cybertec.at writes: Albe Laurenz laurenz.a...@wien.gv.at wrote: Currently it is possible to change the behaviour of a function with CREATE OR REPLACE FUNCTION even if the function is part of an index definition. I think that should be forbidden, because

[HACKERS] Unlogged tables can vanish after a crash

2014-11-19 Thread Albe Laurenz
I observed an interesting (and I think buggy) behaviour today after one of our clusters crashed due to an out of space condition in the data directory. Five databases in that cluster have each one unlogged table. The log reads as follows: PANIC could not write to file pg_xlog/xlogtemp.1820: No

Re: [HACKERS] Unlogged tables can vanish after a crash

2014-11-19 Thread Albe Laurenz
Andres Freund wrote: On 2014-11-19 11:26:56 +, Albe Laurenz wrote: I observed an interesting (and I think buggy) behaviour today after one of our clusters crashed due to an out of space condition in the data directory. Hah, just a couple days I pushed a fix for that ;) http

[HACKERS] Functions used in index definitions shouldn't be changed

2014-11-19 Thread Albe Laurenz
Currently it is possible to change the behaviour of a function with CREATE OR REPLACE FUNCTION even if the function is part of an index definition. I think that should be forbidden, because it is very likely to corrupt the index. I expect the objection that this would break valid use cases where

Re: [HACKERS] plpgsql plan changes causing failure after repeated invocation

2014-11-11 Thread Albe Laurenz
Merlin Moncure wrote: I chased down a problem today where users were reporting sporadic failures in the application. Turns out, the function would work exactly 5 times and then fail; this is on 9.2. I think I understand why this is happening and I'm skeptical it's a bug in postgres, but I

Re: [HACKERS] Let's drop two obsolete features which are bear-traps for novices

2014-11-04 Thread Albe Laurenz
David Fetter wrote: On Tue, Nov 04, 2014 at 07:51:06AM +0900, Tatsuo Ishii wrote: Just out of curiosity, why is Oracle's NUMBER (I assume you are talking about this) so fast? I suspect that what happens is that NUMBER is stored as a native type (int2, int4, int8, int16) that depends on its

Re: [HACKERS] PostgreSQL Service Name Enhancement - Wildcard support for LDAP/DNS lookup

2014-10-29 Thread Albe Laurenz
I have suggested a similar feature before and met with little enthusiasm: http://www.postgresql.org/message-id/d960cb61b694cf459dcfb4b0128514c2f34...@exadv11.host.magwien.gv.at I still think it would be a nice feature and would make pg_service.conf more useful than it is now. Yours, Laurenz Albe

Re: [HACKERS] WIP: multivariate statistics / proof of concept

2014-10-13 Thread Albe Laurenz
Tomas Vondra wrote: attached is a WIP patch implementing multivariate statistics. I think that is pretty useful. Oracle has an identical feature called extended statistics. That's probably an entirely different thing, but it would be very nice to have statistics to estimate the correlation

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

2014-09-12 Thread Albe Laurenz
Tom Lane wrote: Stephen Frost sfr...@snowman.net writes: I have to admit that, while I applaud the effort made to have this change only be to postgres_fdw, I'm not sure that having the update/delete happening during the Scan phase and then essentially no-op'ing the

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

2014-09-09 Thread Albe Laurenz
Etsuro Fujita wrote: I agree with you on that point. So, I've updated the patch to have the explicit flag, as you proposed. Attached is the updated version of the patch. In this version, I've also revised code and its comments a bit. Thank you, I have set the patch to Ready for Committer.

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

2014-09-08 Thread Albe Laurenz
I wrote: I gave it a spin and could not find any undesirable behaviour, and the output of EXPLAIN ANALYZE looks like I'd expect. I noticed that you use the list length of fdw_private to check if the UPDATE or DELETE is pushed down to the remote server or not. While this works fine, I

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

2014-09-02 Thread Albe Laurenz
Etsuro Fujita wrote: Please find attached the updated version of the patch. I gave it a spin and could not find any undesirable behaviour, and the output of EXPLAIN ANALYZE looks like I'd expect. I noticed that you use the list length of fdw_private to check if the UPDATE or DELETE is pushed

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

2014-08-25 Thread Albe Laurenz
Etsuro Fujita wrote: Done. (I've left deparseDirectUpdateSql/deparseDirectDeleteSql as-is, though.) Other changes: * Address the comments from Eitoku-san. * Add regression tests. * Fix a bug, which fails to show the actual row counts in EXPLAIN ANALYZE for UPDATE/DELETE without a

Re: [HACKERS] How to manage shared library lifetime through C functions

2014-08-04 Thread Albe Laurenz
Seref Arikan wrote: I hope this is the right group to ask this question; apologies if this should go the general or some other list. I have multiple shared libraries that can be called from C that I'd like to use from a C based postgresql function. These libraries perform some

Re: [HACKERS] How to manage shared library lifetime through C functions

2014-08-04 Thread Albe Laurenz
Craig Ringer wrote: On 08/04/2014 06:31 PM, Seref Arikan wrote: Thanks a lot Heikki and Albe. Exactly what I was asking for. Heikki: the libraries are written in languages that have their own runtime and their documentation insists that both init and dispose calls are performed when used from

[HACKERS] Re: [GENERAL] pg_dump behaves differently for different archive formats

2014-07-28 Thread Albe Laurenz
Tom Lane wrote on Dec 16, 2013: Albe Laurenz laurenz.a...@wien.gv.at writes: Restoring a plain format dump and a custom format dump of the same database can lead to different results: pg_dump organizes the SQL statements it creates in TOC entries. If a custom format dump is restored

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

2014-07-25 Thread Albe Laurenz
Shigeru Hanada wrote: * Naming of new behavior You named this optimization Direct Update, but I'm not sure that this is intuitive enough to express this behavior. I would like to hear opinions of native speakers. How about batch foreign update or batch foreign modification? (Disclaimer: I'm

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

2014-07-01 Thread Albe Laurenz
Michael Paquier wrote: After sleeping on it, I have put my hands on the postgres_fdw portion and came up with a largely simplified flow, resulting in the patch attached. [...] Ronan, what do you think of those patches? I have nothing more to add, and I think that they should be looked by

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

2014-05-26 Thread Albe Laurenz
Ronan Dunklau wrote: Since my last proposal didn't get any strong rebuttal, please find attached a more complete version of the IMPORT FOREIGN SCHEMA statement. I tried to follow the SQL-MED specification as closely as possible. This adds discoverability to foreign servers. The structure

Re: [HACKERS] Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)

2014-05-02 Thread Albe Laurenz
Amit Langote wrote: Is the following behavior perceived fix-worthy? -- note the '1's in the outputs postgres=# CREATE TABLE test AS SELECT; SELECT 1 postgres=# insert into test select; INSERT 0 1 Or maybe, it just means 1 'null' row/record and not no row at all? Right, I'd say you end

Re: [HACKERS] 9.4 Proposal: Initdb creates a single table

2014-04-23 Thread Albe Laurenz
Simon Riggs wrote: I propose we add a single table called Postgres when we Initdb CREATE TABLE Postgres (Id Integer, Data Jsonb); COMMENT ON TABLE Postgres IS 'Single table for quick start usage - design your database'; The purpose of this is to make the database immediately usable.

  1   2   3   4   5   >