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
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
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
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
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
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:
> 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:
>> 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
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:
> 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
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
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
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
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'
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
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:
> 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
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
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
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:
>>/* 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
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
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
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".
>
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
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
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:
> 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
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
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
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
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/
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
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:
>> 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.
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
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
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
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;
> >
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
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:
>> 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
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
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
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
Craig Ringer wrote:
> Out of personal interest (in pain and suffering) I was recently looking
> into how to compile extensions out-of-tree on Windows using Visual
> Studio (i.e. no PGXS).
>
> It looks like the conventional answer to this is "Do a source build of
> PG, compile your ext in-tree in c
Rushabh Lathia wrote:
> I found constraints on foreign table is very useful for the application when
> the multiple
> user accessing same remote table using fdw and both user want to enforce
> different
> constraint on particular table or different user want to enforce different
> DEFAULT
> expr
Andreas Karlsson wrote:
> On 01/28/2014 10:56 PM, Andres Freund wrote:
>> On 2014-01-28 21:48:09 +, Thom Brown wrote:
>>> On 28 January 2014 21:37, Robert Haas wrote:
On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas
wrote:
The point of Andres's patch set is to introduce a new tec
Michael Paquier wrote:
> On Fri, Feb 7, 2014 at 3:02 PM, James Sewell
> wrote:
>
>> Node A could get ahead even if it has been shut down cleanly BEFORE the
>> promotion?
>> I'd always assumed if I shut down the master the slave would be at the same
>> point after shutdown
>> - is this incorrec
[CC'ed -hackers]
Tsubasa Sakamoto wrote:
>> Not sure that it makes a difference but the docs say psql looks at
>> LC_CTYPE not LANG for Unix systems. You did not say what OS you are
>> working on though from the examples I am guessing some form of Unix.
> The LC_CTYPE environment variable was set
> I'm applying for GSoC 2014 with Postgresql and would appreciate your comments
> on my proposal
> (attached). I'm looking for technical corrections/comments and your opinions
> on the project's
> viability. In particular, if the community has doubts about its usefulness, I
> would start working
Josh Berkus wrote:
> What makes these GUCs worse is that nobody knows how to set them; nobody
> on this list and nobody in the field. Heck, I doubt 1 in 1000 of our
> users (or 1 in 10 people on this list) know what a multixact *is*.
I won't contend your first statement, but multixacts are explai
Magnus Hagander wrote:
>> The patch should still be good, but if we keep the deprecated
>> OpenLDAP API, it might be more consistent to use ldap_simple_bind_s
>> instead of ldap_sasl_bind_s.
>>
>> If you agree, I'll change that.
>
> Sorry, you got this one in just as my vacation started.
>
> Yes,
Vivek Singh Raghuwanshi wrote:
> I am trying to install postgresql-jdbc but facing java error.
It would be helpful to know which error you are facing.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
This is a review for patch
caaphdvpagtypzb2kwa0mmtksayg9+vashyjmjfatngxr1ad...@mail.gmail.com
The patch is readable, applies fine and builds without warnings.
It contains sufficient documentation.
It works as it should, no crashes or errors.
It is well written, in fact it improves the readabili
David Rowley wrote:
> I moved the source around and I've patched against it again. New patch
> attached.
Thank you, marked as ready for committer.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
Abhijit Menon-Sen wrote:
> I read through the patch, and it looks sensible.
Thanks for the thorough review!
> I would have preferred the ldap_simple_bind_s() call in the HAVE_LIBLDAP
> branch to not be inside an else {} (the if block above returns if there
> is an error anyway), but that's a mino
Peter Eisentraut wrote:
[good suggestions for improvement]
I'll send an updated patch on Monday.
Yours,
Laurenz Albe
--
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:
>> --- 3511,3534
>> }
>>
>> /*
>> ! * Perform an explicit anonymous bind.
>> ! * This is not necessary in principle, but we want to set a timeout
>> ! * of PGLDAP_TIMEOUT seconds and return 2 if the connection fails.
>> ! * Unfortunately there
Naman wrote:
> I have an 3 indexes on a relation t2(A,B,C) index1 , index2 ,index3
>
> What i need is if i know the indexname (say index1) then is their any
> programmatic way by which i can
> get the list of tuples which comes under the index specified( i.e index1)
Do you need anything that e
Arul Shaji Arulappan wrote:
> Attached is a patch that implements the first set of changes discussed
> in this thread originally. They are:
>
> (i) Implements NCHAR/NVARCHAR as distinct data types, not as synonyms so
> that:
> - psql \d can display the user-specified data types.
> - pg
MauMau wrote:
> From: "Albe Laurenz"
>> If I understood the discussion correctly the use case is that
>> there are advantages to having a database encoding different
>> from UTF-8, but you'd still want sume UTF-8 columns.
>>
>> Wouldn't i
I have a question concerning the Foreign Data Wrapper API:
I find no mention of this in the documentation, but I remember that
you can only add a resjunk column that matches an existing attribute
of the foreign table and not one with an arbitrary name or
definition.
Ist that right?
Yours,
Lauren
Tom Lane wrote:
> Albe Laurenz writes:
>> I have a question concerning the Foreign Data Wrapper API:
>> I find no mention of this in the documentation, but I remember that
>> you can only add a resjunk column that matches an existing attribute
>> of the foreign table an
Tom Lane wrote:
> Albe Laurenz writes:
>> What I would like to do is add a custom resjunk column
>> (e.g. a bytea) in AddForeignUpdateTargets that carries a row identifier
>> from the scan state to the modify state.
>> Would that be possible? Can I have anything else
MauMau wrote:
> Let me repeat myself: I think the biggest and immediate issue is that
> PostgreSQL does not support national character types at least officially.
> "Officially" means the description in the manual. So I don't have strong
> objection against the current (hidden) implementation of nc
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
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
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
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
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
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
Shigeru Hanada wrote:
> Thanks for the review. Attached patches are revised version, though
> only fdw_helper_v5.patch is unchanged.
Two questions:
- Is it on purpose that you can specify all SSL client options
except "sslcompression"?
- Since a rescan is done by rewinding the cursor, is it nec
Shigeru Hanada wrote:
>> - Since a rescan is done by rewinding the cursor, is it necessary
>>to have any other remote isolation level than READ COMMITED?
>>There is only one query issued per transaction.
>
> If multiple foreign tables on a foreign server is used in a local
query,
> multipl
Greg Stark wrote:
> I suspect this is wrong for similar reasons as "pure" but I'll throw
> it out there: "hermetic"
I personally have no problem with "leakproof", but if it does not tickle
the right associations with many people:
What about "secure"? It is also not self-explanatory, but it might
I wrote:
> Shigeru Hanada wrote:
>>> - Since a rescan is done by rewinding the cursor, is it necessary
>>>to have any other remote isolation level than READ COMMITED?
>>>There is only one query issued per transaction.
>>
>> If multiple foreign tables on a foreign server is used in a local
q
Kevin Grittner wrote:
> > If your query involves foreign scans on two foreign tables on the
> > same foreign server, these should always see the same snapshot,
> > because that's how it works with two scans in one query on local
> > tables.
>
> That makes sense.
> > So I think it should be REPEAT
Shigeru Hanada wrote:
[pgsql_fdw_v12.patch]
I know this is not the latest version, but I played around with it and
tickled a bug.
It seems to have a problem with rolled back subtransactions.
test=> \d+ remote
Foreign table "laurenz.remote"
Column | Type | Modifiers |
Shigeru Hanada wrote:
>Connection should be closed only when the trigger is a
> top level transaction and it's aborting, but isTopLevel flag was not
> checked. I fixed the bug and added regression tests for such cases.
I wondered about that - is it really necessary to close the re
Robert Haas wrote:
> Well, I guess I'm still of the opinion that the real question is
> whether the particular lint checks that Pavel's implemented are good
> and useful things. Has anyone spent any time looking at *that*?
Actually, I did when I reviewed the patch the first time round.
I think th
Tom Lane wrote:
> Shigeru Hanada writes:
>> Thanks for the review. Agreed to write own depraser for pgsql_fdw
>> which handles nodes which can be pushed down. Every SQL-based FDW
>> which constructs SQL statement for each local query would need such
>> module inside.
>
> Yeah. That's kind of a
MUHAMMAD ASIF wrote:
> We have noticed the following issue with vacuumlo database that have millions
> of record
> in pg_largeobject i.e.
[...]
> ~/work/pg/postgresql-9.1.2/inst$ bin/vacuumlo vacuumlo_test
>
> WARNING: out of shared memory
> Failed to remove lo 36726: ERROR: out of shared mem
Shigeru HANADA wrote:
> I've implemented pgsql_fdw's own deparser and enhanced some features
> since last post. Please apply attached patches in the order below:
> Changes from previous version
> =
>
> 1) Don't use remote EXPLAIN for cost/rows estimation, so now plann
Shigeru HANADA wrote:
>> My gut feeling is that planning should be done by the server which
>> will execute the query.
>
> Agreed, if selectivity of both local filtering and remote filtering
were
> available, we can estimate result rows correctly and choose better
plan.
>
> How about getting # of
I wrote:
>> How about getting # of rows estimate by executing EXPLAIN for
>> fully-fledged remote query (IOW, contains pushed-down WHERE clause),
and
>> estimate selectivity of local filter on the basis of the statistics
>> which are generated by FDW via do_analyze_rel() and FDW-specific
>> samplin
I wrote:
>> Changes from previous version
>> =
>>
>> 1) Don't use remote EXPLAIN for cost/rows estimation, so now planner
>> estimates result rows and costs on the basis of local statistics such
>> as pg_class and pg_statistic. To update local statistics, I added
>> pgs
Robert Haas wrote:
> I suppose one interesting question is to figure out if there's a way I
> can optimize the disk configuration in this machine, or the Linux I/O
> scheduler, or something, so as to reduce the amount of time it spends
> waiting for the disk.
I'd be curious to know if using the de
Shigeru HANADA wrote:
> Attached are latest version of pgsql_fdw patches. Note that
> pgsql_fdw_analyze.patch is only for test the effect of local
statistics.
> Please apply patches in the order below:
>
> (1) pgsql_fdw_v18.patch
> (2) pgsql_fdw_pushdown_v11.patch
> (3) pgsql_fdw_analyze.patch (
Shigeru HANADA wrote:
>> During a foreign scan, type input functions are used to convert
>> the text representation of values. If a foreign table is
misconfigured,
>> you can get error messages from these functions, like:
>>
>> ERROR: invalid input syntax for type double precision: "etwas"
>> or
Atri Sharma wrote:
> I submitted a proposal for GSoc 2012.Please review it and let me know
> your comments.
>
> The link is:
>
>
https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/
atrisharma/1001
I think that this is a pretty cool idea.
Have you contacted the developers of
Maciej Gajewski wrote:
> I know this topic was discussed before, but there doesn't seem to be
> any conclusion.
>
> The lack of unsigned integer types is one of the biggest sources of
> grief in my daily work with pgsql.
>
> Before I go and start hacking, I'd like to discuss few points:
>
> 1. I
Clark C. Evans wrote:
> I'd really love the ability to grant a *user*
> role-based privileges database by database.
>
> For background, I have several databases running
> in a single cluster, one database per business unit.
> Each database has the same core schema with the same
> basic role permis
Clark C. Evans wrote:
>>> I'd really love the ability to grant a *user*
>>> role-based privileges database by database.
>>
>> The only cluster-wide role permissions are the options
>> SUPERUSER, CREATEDB, CREATEROLE, INHERIT,
>> LOGIN and REPLICATION.
>
> Incorrect; role-to-role membership (differ
This is a review of the patch in 5192d7d2.8020...@catalyst.net.nz
The patch applies cleanly (with the exception of catversion.h of course),
compiles without warnings and passes the regression tests.
It contains enough documentation, though I'd prefer
"Estimated number of rows modified since the t
Dmitriy Igrishin wrote:
> Sent: Thursday, June 20, 2013 5:09 PM
> To: PostgreSQL Hackers
> Subject: [HACKERS] Frontend/backend protocol improvements proposal (request).
>
> Hackers,
>
> While developing a C++ client library for Postgres I felt lack of extra
> information in command tags in the Co
I want to draw attention to this thread on -general:
camq5dgq4sujpbht2-9xlapasvknul2-bb0cpyci2fp+pfsf...@mail.gmail.com
Would you concur that this is a bug?
The fine manual says about CASE:
If the condition's result is true, the value of the CASE expression
is the result that follows the con
Andres Freund wrote:
> On 2013-06-21 08:16:22 +0000, Albe Laurenz wrote:
> > I want to draw attention to this thread on -general:
> > camq5dgq4sujpbht2-9xlapasvknul2-bb0cpyci2fp+pfsf...@mail.gmail.com
>
> There's also a bug reported for it:
> #8237: e1uovmc-0007
Abhijit Menon-Sen wrote:
> Sorry to nitpick, but I don't like that either, on the grounds that if I
> had been in Tom Duffey's place, this addition to the docs wouldn't help
> me to understand and resolve the problem.
>
> I'm not entirely convinced that any brief mention of extra_float_digits
> wo
Noah Misch wrote:
>> If fixing the behaviour is undesirable, at least the documentation
>> should be fixed.
>
> A brief documentation mention sounds fine. Perhaps add a paragraph on
> constant folding in general and reference that from the CASE page.
How about the attached?
Yours,
Laurenz Albe
Dean Rasheed wrote:
>> How should reviewers get credited in the release notes?
>>
>> a) not at all
>> b) in a single block titled "Reviewers for this version" at the bottom.
>> c) on the patch they reviewed, for each patch
>>
>
> b) Unless they contribute enough to the patch to be considered a co-
1 - 100 of 459 matches
Mail list logo
