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.
>
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
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
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
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
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,
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;
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
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:
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
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
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.
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
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
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
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
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
>>
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>>>
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
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
>
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
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
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
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
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
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
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:
>
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
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
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
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
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:
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
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.
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
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.
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
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
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 transparent for
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 =
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
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
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
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 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
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
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.
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,
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
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
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
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
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
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
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
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
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
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
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, I
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
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
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
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
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
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
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
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
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
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 - 100 of 457 matches
Mail list logo