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.
>
> Client commands may be
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 a
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
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 re
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
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
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 around by
>> creating the slot
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 pg_create_logical_r
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, and it works fine.
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;
E
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 how widely used that option is.
> Is it
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:
http://www.postgresql.org/
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 w
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 subscrip
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.
>>
>> Simple test case:
>>
>> p
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 wiki
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 usa
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 c
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
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 wo
Robert Haas wrote:
> On Tue, Nov 15, 2016 at 10:41 AM, Albe Laurenz
> wrote:
>> 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 "Par
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 that
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: p
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 f
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 a
Tom Lane wrote:
>> Albe Laurenz 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". The Windows builds aren'
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
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
0001-Add-PGDLLEXPORT-to-PG_FU
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 PGDLLEXPORT-ifi
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 t
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 Datu
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 phas
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
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 t
Tom Lane wrote:
> Albe Laurenz 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 this suggest that it's not
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 PG_FUNCTION_INF
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 i
Tom Lane wrote:
> Albe Laurenz 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.
>
> The example you propose to cor
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
0001-Fix-mention-of-pg_temp-in-CREATE-FUNCTION-documentat.p
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
>>> (https://www.postgresql.org/message-id/201107200103.p
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 HH24
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
> c
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 inform
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
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.
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 plan.
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 chosen.
>>
>> I ha
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 one idea is max_parallel_workers_per_gather_no
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 probability
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 table
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:
> http://www.vldb.or
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 whatever
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,
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(...);
>
>
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
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 th
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 DB story.
What, lik
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 outp
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: 0001-Fix-documentation-for-pset-unicode_-_linestyle.p
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 pgsql-hacker
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.
A
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 can make such a cha
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
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. U
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 d
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 administr
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
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 transpar
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;
> >
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
>>>>
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
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 w
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
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Bruce Momjian 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 i
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 gen
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 t
Heikki Linnakangas wrote:
>> Can we work-around that easily? I believe we can. The crucial part is
>> that we mustn't let SSL_write() to process any incoming application
>> data. We can achieve that if we always call SSL_read() to drain such
>> data, before calling SSL_write(). But that's not quite
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, conf
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
> l
Robert Haas wrote:
> On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz 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 fro
Tom Lane wrote:
> Antonin Houska writes:
>> Albe Laurenz 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
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
Andres Freund wrote:
> On 2014-11-19 11:26:56 +0000, 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
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":
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
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
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
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 be
Tom Lane wrote:
> Stephen Frost 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 ExecForeignUpdate/ExecForeignDelete i
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
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,
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 do
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
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 u
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 s
Tom Lane wrote on Dec 16, 2013:
> Albe Laurenz 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".
>
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"?
(Disclai
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
> look
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 struct
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?
R
1 - 100 of 459 matches
Mail list logo