On Thu, Mar 19, 2015 at 3:41 PM, David Christensen
wrote:
> The two-arg form of the current_setting() function will allow a
> fallback value to be returned instead of throwing an error when an
> unknown GUC is provided. This would come in most useful when using
> custom
Seems better to just pass the info the
caller does have and let this function do the rest.
Pushed, thanks for reviewing!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
such.setting = 'nada';
> +select current_setting('nosuch.setting','fallback');
> + current_setting
> +-
> + nada
> +(1 row)
> +
> diff --git a/src/test/regress/sql/guc.sql b/src/test/regress/sql/guc.sql
> index 3de8a6b..48c0bed 100644
> --- a/src/test/regress/sql/guc.sql
> +++ b/src/test/regress/sql/guc.sql
> @@ -275,3 +275,15 @@ set default_text_search_config = no_such_config;
> select func_with_bad_set();
>
> reset check_function_bodies;
> +
> +-- check multi-arg custom current_setting
> +
> +-- this should error:
> +select current_setting('nosuch.setting');
> +
> +-- this should return 'fallback'
> +select current_setting('nosuch.setting','fallback');
> +
> +-- this should return 'nada', not 'fallback'
> +set nosuch.setting = 'nada';
> +select current_setting('nosuch.setting','fallback');
> --
> 2.3.3
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
lect func_with_bad_set();
reset check_function_bodies;
+
+-- check multi-arg custom current_setting
+
+-- this should error:
+select current_setting('nosuch.setting');
+
+-- this should return 'fallback'
+select current_setting('nosuch.setting','fallback');
+
+-- this should return 'nada', n
ly avoids live locks,
but those are fairly unlikely and easy to detect and abort.
Thank you for a constructive email, we are on the way to somewhere good.
I have more to add, but wanted to get back to you soonish.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
351711493487...@web53g.yandex.ru
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
accordingly, whereas in PG they are all
table-like, and thus optimizer barriers.
Nico
--
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
uld
be a pain to determine number of blocks for each range, so I'm looking
for a simple way to fix it without imposing so much overhead.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsq
t one
row ... but sure, we can spell that out.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
g.
Committed incorporating that suggestion.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ngContext *ctx, XLogRecPtr lsn, TransactionId xid,
/* Send keepalive if the time has come */
WalSndKeepaliveIfNecessary(now);
+ /* If we finished clearing the buffered data, we're done here. */
+ if (!pq_is_send_pending())
+ break;
+
sleeptime = WalSndComputeSleeptime(now);
wake
On Wed, Nov 1, 2017 at 9:04 AM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> Anybody willing to take the hat of the commit fest manager? If nobody,
> I am fine to take the hat as default choice this time.
And now it is open. Let's the fest begin.
--
Michael
--
Sent via p
On Wed, Nov 1, 2017 at 2:24 PM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> Committed to master. I suppose this should be backpatched?
Thanks! Yes this should be back-patched.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
. I suppose this should be backpatched?
(I changed the strcpy() to strlcpy() for better karma.)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
ts reported within
a particular chunk of code. It's meant to catch something like "name not
found" but could produce this too.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ing significant cost on existing users. And it'd make it
way simpler to build a layer on top for a 1:m 2-way comms system like
Ildus is talking about.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsq
Between 9.6.5 and 10, the handling of parenthesized single-column UPDATE
statements changed. In 9.6.5, they were treated identically to
unparenthesized single-column UPDATES. In 10, they are treated as
multiple-column updates. This results in this being valid in Postgres
9.6.5, but an error in
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Oct 28, 2017 at 3:07 PM, Robert Haas wrote:
> On Fri, Oct 27, 2017 at 1:01 PM, Jeevan Chalke
> wrote:
> > 1. Added separate patch for costing Append node as discussed up-front in
> the
> > patch-set.
> > 2. Since we now cost Append
As a brief note, this is probably not the best list for this. You would do
better to ask questions like this on -general where you have more
application developers and so forth. This is more of an SQL question so
asking people who are hacking the codebase may not be the best way to get
it
why can we ignore selectivity.
Similarly for the changes in create_minmaxagg_path().
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ot;7.hello" as "7".
Committed.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, Postgr
ches
quickly.
Regards.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
App is moving to Postgre from Oracel . After migrating the store procedure
is throwing an error with collection type.
*Oracle :*
create or replace PROCEDURE"PROC1"
(
, REQ_CURR_CODE IN VARCHAR2
, IS_VALID OUT VARCHAR2
, ERROR_MSG OUT VARCHAR2
) AS
TYPE INV_LINES_RT IS RECORD(
] [PATTERN]list tables\n"));
fprintf(output, _(" \\dT[S+] [PATTERN] list data types\n"));
fprintf(output, _(" \\du[S+] [PATTERN] list roles\n"));
fprintf(output, _(" \\dv[S+] [PATTERN] list views\n"));
fprintf(output, _(" \
se of some leftover errposition() value, but why is it being
reported in this message?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
Any comments?
2017-10-26 16:03 GMT+08:00 高增琦 :
> Hi,
>
> I tried some tests with ecpg informix mode.
> When trying to store float data into a integer var, I got endless loop.
>
> The reason is:
> In informix mode, ecpg can accept
> string form of float number when processing
e result sets
> fetch result
> stop timer
> foreach result set
> print result
>
> but that would have a lot more overhead, potentially.
>
> Thoughts?
>
Has the total time sense in this case?
should not be total time related to any fetched result?
Rega
Hi all,
Thanks Stephen for the suggestion. I wan't thinking globally enough. I was
planning to look at it today but Amit was faster. So thanks Amit too!
Have a nice day (UGT),
Lætitia
2017-11-01 1:35 GMT+01:00 Amit Langote :
> On 2017/10/31 21:31, Stephen Frost
Hi all,
At the moment of writing this email, it is 9PM AoE (Anywhere on Earth)
31st of October. This means that the next commit fest will begin in 3
hours, and that any hackers willing to register patches for this
commit fest have roughly three hours to do so (plus/minus N hours).
This current
ore descriptive name but
> currently did not remove the old function yet.
>
>
> Feedback is very welcome. pg_rewind is a very nice piece of software. I
> am hoping that these sorts of changes will help ensure that it is easier to
> use and provides more predictable results.
&
On Tue, Oct 31, 2017 at 1:38 PM, Robert Haas wrote:
> On Mon, Oct 30, 2017 at 6:44 PM, Chris Travers
> wrote:
> > The attached patch is cleaned up and filed for the commit fest this next
> > month:
>
> It's generally better to post the patch on
side me
understand it easily by looking at the code? :)
Thank you,
Tels
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2017-11-01 6:07 GMT+01:00 Serge Rielau :
> "Although the syntax of CREATE TEMPORARY TABLE resembles that of the SQL
> standard, the effect is not the same. In the standard, temporary tables are
> defined just once and automatically exist (starting with empty contents) in
> every
" Although the syntax of CREATE TEMPORARY TABLE resembles that of the SQL
standard, the effect is not the same. In the standard, temporary tables are
defined just once and automatically exist (starting with empty contents) in
every session that needs them. PostgreSQL instead requires each
Here is a rebased version of the patch.
Andreas
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index a0ca2851e5..f8c59ea127 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -926,6 +926,7 @@ ERROR: could not serialize access due to read/write dependencies among
our temp tables - so
at session end the temp variables are destroyed, but it can be assigned to
transaction.
>
>
>
>
> --
> Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-
> f1928748.html
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
ame in the relevant threads, so you know that. To save
others the time, see:
* https://lwn.net/Articles/724198/
* https://lwn.net/Articles/671649/
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hack
sbehavior too. Looking ...
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
e worthwhile to see whether doing the merging ourselves allows
for deeper queues.
I think we really should start incorporating explicit prefetching in
more places. Ordered indexscans might actually be one case that's not
too hard to do in a simple manner - whenever at an inner node, prefetch
the lea
be assumed to be empty. Any
> thoughts?
>
You also meant that the applying WAL for AccessExclusiveLock is always
skipped on standby servers to allow scans to access the relation?
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
eResults().
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t like we can't
> control what rows get inserted on the foreign server when they violate
> local constraints.
I think that's a fair point.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
just use a BufFileSet directly as a member of SharedSort.
FWIW, I agree with you that nobody uses temp_tablespaces this way
these days. This seems like a discussion for your hash join patch,
though. I'm happy to buy into that.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ion_bound_spec
is:
+
+IN ( { numeric_literal |
string_literal | NULL } [, ...] ) |
+FROM ( { numeric_literal |
string_literal | MINVALUE |
MAXVALUE } [, ...] )
+ TO ( { numeric_literal |
string_literal | MINVALUE |
MAXVALUE } [, ...] )
+
+
Description
--
Sent via pgsql-hackers mailing list (
Hackers,
Normally we'll only ever remove a LEFT JOIN relation if it's unused
and there's no possibility that the join would cause row duplication.
To check that the join wouldn't cause row duplicate we make use of
proofs, such as unique indexes, or for sub-queries, we make use of
DISTINCT
, we should really use
> a low-level operation as well.
I'm sorry I may not have been clear. With this patch, write_eventlog() outputs
the message to event log with ReportEventA() when CurrentMemoryContext is NULL.
It doesn't write to stderr. So the message won't be lost.
Regards
Takayuki Tsunakaw
In the newest version I changed that
flexible array to tablespaces[8], because 8 should be enough
tablespaces for anyone (TM). I don't really believe anyone uses
temp_tablespaces for IO load balancing anymore and I hate code like
the above. So I think Rushabh should now remove the above-quot
HAVING expression once
per group row, whether the row passes the qual or not.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 31, 2017 at 4:31 PM, Tels wrote:
>
>
> That looks odd to me, it first uses output_tuples in a formula, then
> overwrites the value with a new value. Should these lines be swapped?
>
IIUC it is correct: the additional total_cost comes from
Hackers,
a few years ago generic WAL was proposed by Alexander Korotkov
(https://www.postgresql.org/message-id/flat/CAPpHfdsXwZmojm6Dx%2BTJnpYk27kT4o7Ri6X_4OSWcByu1Rm%2BVA%40mail.gmail.com#capphfdsxwzmojm6dx+tjnpyk27kt4o7ri6x_4oswcbyu1rm...@mail.gmail.com).
and was committed into PostgreSQL
ses output_tuples in a formula, then
overwrites the value with a new value. Should these lines be swapped?
Best regards,
Tels
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
5, and I don't even need to run the
UPDATE part. That is, INSERT + VACUUM running concurrently is enough to
produce broken BRIN indexes :-(
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
epted a conformant subset of the standard syntax.
Oh well.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
orgot to say that in the last case the DECLARE statement can be used
so I don't see the reason of this kind of "temporary" variables.
Maybe the variable object like used in DB2 and defined in document :
https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/sqlref/src/tpc/db2z
On Tue, Oct 31, 2017 at 3:43 PM, Tom Lane wrote:
> According to the spec, the elements of a parenthesized
> SET list should be assigned from the fields of a composite RHS. If
> there's just one element of the SET list, the RHS should be a single-field
> composite value, and
On Tue, Oct 31, 2017 at 3:14 PM, Rob McColl wrote:
>
>> I believe that this is not an intended change or behavior, but is instead
>> an unintentional side effect of 906bfcad7ba7cb3863fe0e2a7810be8e3cd84fbd
>> Improve handling of "UPDATE ... SET (column_list) =
psql sessions, though, to simulate concurrent
activity).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
brin-test.sql
Description: application/sql
--
Sent via pgsql-hackers mailin
ould just
leave off the word ROW; but it is a critical distinction if we're ever to
get to the point of allowing other composite-returning constructs here,
for example composite-returning functions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
P" is used
otherwise it will persist after the transaction end. I guess that this
is the same as using TEMP keyword?
--
Gilles Darold
Consultant PostgreSQL
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
w.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
man) whom I am attaching in CC.
pgBackRest does not use pg_rewind. However, pgBackRest does use the
same exclusion list for backups as pg_basebackup.
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
for (processing large query
results in efficient way).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,b,a) = ('bugle', b+11, DEFAULT) WHERE c = 'bungle';
SELECT * FROM update_test;
UPDATE update_test SET (c,b) = ('car', a+b), a = a + 1 WHERE a = 10;
SELECT * FROM update_test;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
quals,
Cost input_startup_cost, Cost input_total_cost,
double input_tuples);
extern void initial_cost_nestloop(PlannerInfo *root,
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2017-10-31 22:08 GMT+01:00 Serge Rielau :
> Pavel,
>
> I can imagine, so DECLARE command will be introduced as short cut for
> CREATE TEMP VARIABLE, but in this moment I would not to open this topic. I
> afraid of bikeshedding and I hope so CREATE TEMP VAR is anough.
>
>
>
>>>
>>> Agree.
>>>
>>
>> I have updated the location of CheckForSerializableConflictIn() and
>> changed the status of the patch to "needs review".
>>
>
> Now, ITSM that predicate locks and conflict checks are placed right for
&g
REATE TABLE cp_test3 (x text, y text);
+INSERT INTO cp_test3 VALUES ('abc', 'def'), ('foo', 'bar');
+
+CREATE PROCEDURE pdrstest1()
+LANGUAGE SQL
+AS $$
+DECLARE c1 CURSOR WITH RETURN FOR SELECT * FROM cp_test2;
+DECLARE c2 CURSOR WITH RETURN FOR SELECT * FROM cp_test3;
+$$;
+
+CALL pdrstest1();
+
+
-- cleanup
DROP PROCEDURE ptest1;
DROP PROCEDURE ptest2;
-DROP TABLE cp_test;
+DROP TABLE cp_test, cp_test2, cp_test3;
DROP USER regress_user1;
--
2.14.3
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Pavel, I can imagine, so DECLARE command will be introduced as short cut
for CREATE TEMP VARIABLE, but in this moment I would not to open this
topic. I afraid of bikeshedding and I hope so CREATE TEMP VAR is anough.
Language is important because language stays. You choice of syntax will
orked with previously.)
>
Not sure if disabling RETURN is good idea. I can imagine so optional
returning something like int status can be good idea. Cheaper than raising
a exception.
Regards
Pavel
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Dev
TEMP VAR is anough.
Regards
Pavel
> Cheers
> Serge Rielau
> Salesforce.com
>
>
>
> --
> Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-
> f1928748.html
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
s worked with previously.)
>
great. I hope so I can help with testing
Regards
Pavel
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
Normal(oldlp))
{
LockBuffer(oldbuf, BUFFER_LOCK_UNLOCK);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
te("INSERT INTO test1 (a) VALUES (%d)" % i)
+if i % 2 == 0:
+ plpy.commit()
+else:
+ plpy.rollback()
+$$;
+
+CALL transaction_test1();
+
+SELECT * FROM test1;
+
+
+TRUNCATE test1;
+
+DO
+LANGUAGE plpythonu
+$$
+for i in range(0, 10):
+plpy.execute("INSERT I
spotted in brin_doupdate. There's apparently at least one
more, but given the error message it must be something like not
checking for a page to have turned into a revmap page. Shouldn't
be too hard to find...
regards, tom lane
--
Sent via pgsql-hackers mailing list
eudotypes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David,
* Stephen Frost (sfr...@snowman.net) wrote:
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > Since CREATE USER is officially an alias for CREATE ROLE other parts of the
> > documentation should point to CREATE ROLE, not CREATE USER. Most do but I
> > noticed when looking at
t along with your fix.
>
> regards, tom lane
>
Oops. I missed it in "describe.c" because I grepped for exact "::name" string.
Thank you very much!
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
r system. Both Robert and Stephen
seem to be almost sold on what I suggest, so I think that I've
probably already explained my position quite well.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ull.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
CF 2017/11. I hope I will complete the patch
in this CF.
Regards
Takayuki Tsunakawa
stmt_rollback_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
velopment, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
chema set.
Yeah, there are quite a few unqualified casts in pg_dump, but AFAICS
all the rest are OK because the search_path is just pg_catalog.
But I did find psql's describe.c making a similar mistake :-(.
Pushed that along with your fix.
regards, tom lane
--
code does, so there is
something wrong there.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e not
needed, because with your patch the segments of the prior checkpoint
are getting recycled. So it seems to me that based on that the formula
ought to use 1.0 instead of 2.0...
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
cks. Shouldn't
that be done someplace else?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e
OK, just for convenience I'm attaching your version of the fix.
I left an other "NULL::name AS rolname" at
src/bin/pg_dump/pg_dump.c:2978 because can't check (remoteVersion <
9) it and it is under strict "selectSourceSchema(fout,
"pg_catalog");" schema set.
thousands of prefetches (and effective_io_concurrency of 1000 actually
means 7485 prefetches). At some point those i/o are going to start
completing before Postgres even has a chance to start processing the
data.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
default:
+ break;
+ }
+
+ appendStringInfoString(buf, "VALUES (");
pindex = 1;
first = true;
--
2.14.3
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
"could not create new dictionary");
+ return NULL;
PG_TRY();
{
@@ -675,6 +675,8 @@ PLyList_FromArray_recurse(PLyDatumToOb *elm, int *dims, int
ndim, int dim,
PyObject *list;
list = PyList_New(dims[dim]);
+ if (!list)
+ return NULL;
if (dim < ndim - 1)
{
--
2.14.3
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
an
> continue to review the patch.
I will wait.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
sequence_type,
pg_dump doesn't particularly care whether the column comes back marked
as 'name' or 'text' or 'unknown'.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
cient
pedigree, but I do not think it's very good design.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Here is a patch that adds const decorations to many char * arguments in
functions. It should have no impact otherwise; there are very few code
changes caused by it. Some functions have a strtol()-like behavior
where they take in a const char * and return a pointer into that as
another argument.
behave
differently from those on other rowtypes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
if you still think it should be removed? I can see the
> argument both ways.
>
> Or maybe we need another patch to account for manual checkpoints.
Revised patch to implement this
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
ned if they weren't all matched. So it should
also have failed, albeit with a different error message, if it were
passed an offnum corresponding to a no-longer-live tuple.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
701 - 800 of 318580 matches
Mail list logo