logical replication: fix OID type mapping mechanism
The logical replication type map seems to have been misused by its only
caller -- it would try to use the remote OID as input for local type
routines, which unsurprisingly could result in bogus "cache lookup
failed for type XYZ" errors, or random
logical replication: fix OID type mapping mechanism
The logical replication type map seems to have been misused by its only
caller -- it would try to use the remote OID as input for local type
routines, which unsurprisingly could result in bogus "cache lookup
failed for type XYZ" errors, or random
On Wed, Mar 14, 2018 at 11:23:35AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I think the problem is rather that we somehow need to tell it to link
> > src/common/string.c into pgtypeslib.
>
> Yeah, that's what I supposed.
>
> Looking at pgtypeslib, there's already infrastructure for
On Thu, Mar 15, 2018 at 9:41 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Andrew Dunstan writes:
>> > Basing an MV on pg_class could always be difficult for pg_upgrade. Maybe
>> > that's not a brilliant thing to do in a test (or maybe the test should drop
>> > the MV after it's done).
>>
>> OH.
On 2018-03-14 19:28, Tom Lane wrote:
Peter Eisentraut writes:
On 3/14/18 12:45, Erik Rijkers wrote:
pl_exec.c: In function ‘exec_stmt_call’:
pl_exec.c:2089:10: warning: variable ‘numargs’ set but not used
[-Wunused-but-set-variable]
I don't get that, and buildfarm animals of similar configu
Tom Lane wrote:
> Andrew Dunstan writes:
> > Basing an MV on pg_class could always be difficult for pg_upgrade. Maybe
> > that's not a brilliant thing to do in a test (or maybe the test should drop
> > the MV after it's done).
>
> OH. Is that what it's doing? The cause of the failure is immedia
Andrew Dunstan writes:
> Basing an MV on pg_class could always be difficult for pg_upgrade. Maybe
> that's not a brilliant thing to do in a test (or maybe the test should drop
> the MV after it's done).
OH. Is that what it's doing? The cause of the failure is immediately
obvious then. pg_class
Stephen Frost writes:
> I've not quite tracked it down, but I would caution against blaming this
> commit- when doing some parallel regression test runs, I was seeing
> failures also, but they've not been consistent and I was trying to get
> something else done so didn't focus on them, so they may
On Thu, Mar 15, 2018 at 7:43 AM, Andres Freund wrote:
> Hi,
>
> On 2018-03-14 19:35:40 +, Peter Eisentraut wrote:
> > Remove pg_class.relhaspkey
> >
> > It is not used for anything internally, and it cannot be relied on for
> > external uses, so it can just be removed. To correct recommended
On 2018-03-14 18:09:07 -0400, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2018-03-14 19:35:40 +, Peter Eisentraut wrote:
> > > Remove pg_class.relhaspkey
> > >
> > > It is not used for anything internally, and it cannot be relied on for
> > > exter
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-03-14 19:35:40 +, Peter Eisentraut wrote:
> > Remove pg_class.relhaspkey
> >
> > It is not used for anything internally, and it cannot be relied on for
> > external uses, so it can just be removed. To correct recommended way to
Hi,
On 2018-03-14 19:35:40 +, Peter Eisentraut wrote:
> Remove pg_class.relhaspkey
>
> It is not used for anything internally, and it cannot be relied on for
> external uses, so it can just be removed. To correct recommended way to
> check for a primary key is in pg_index.
>
> Discussion:
On 3/14/18 14:28, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 3/14/18 12:45, Erik Rijkers wrote:
>>> pl_exec.c: In function ‘exec_stmt_call’:
>>> pl_exec.c:2089:10: warning: variable ‘numargs’ set but not used
>>> [-Wunused-but-set-variable]
>
>> I don't get that, and buildfarm animals of s
Fix compiler warning
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8df5a1c868cc28f89ac6221cff8e2b5c952d0eb6
Modified Files
--
src/pl/plpgsql/src/pl_exec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Remove pg_class.relhaspkey
It is not used for anything internally, and it cannot be relied on for
external uses, so it can just be removed. To correct recommended way to
check for a primary key is in pg_index.
Discussion:
https://www.postgresql.org/message-id/flat/b1a24c6c-6913-f89c-674e-0704f0
Peter Eisentraut writes:
> On 3/14/18 12:45, Erik Rijkers wrote:
>> pl_exec.c: In function ‘exec_stmt_call’:
>> pl_exec.c:2089:10: warning: variable ‘numargs’ set but not used
>> [-Wunused-but-set-variable]
> I don't get that, and buildfarm animals of similar configuration don't
> either. Are y
On 3/14/18 12:45, Erik Rijkers wrote:
> On 2018-03-14 17:09, Peter Eisentraut wrote:
>> Support INOUT arguments in procedures
>
> gcc 6.3.0 (on debian stretch) mutters:
>
> pl_exec.c: In function ‘exec_stmt_call’:
> pl_exec.c:2089:10: warning: variable ‘numargs’ set but not used
> [-Wunused-but-
Fix typo in add_paths_to_append_rel()
The comment should have been referring to the number of workers, not the
number of paths.
Author: Ashutosh Bapat
Discussion:
https://postgr.es/m/cafjfprcbp4702jcp387pext3fnct62qjn8++dqgwbhsw6wr...@mail.gmail.com
Branch
--
master
Details
---
https:/
Fix function-header comments in planner.c
In b5635948ab1, a couple of function header comments weren't changed, or
weren't changed correctly, to reflect the arguments being passed into
the functions. Specifically, get_number_of_groups() had the wrong
argument name in the commit and create_groupin
On 2018-03-14 17:09, Peter Eisentraut wrote:
Support INOUT arguments in procedures
gcc 6.3.0 (on debian stretch) mutters:
pl_exec.c: In function ‘exec_stmt_call’:
pl_exec.c:2089:10: warning: variable ‘numargs’ set but not used
[-Wunused-but-set-variable]
int numargs;
^~~
> Please check these compiler warnings:
> ...
Fixed, thanks.
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,
Fixed compiler warnings in test case.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/20ba33dadedc46bad2eba5ca3c42bc500c36ade0
Modified Files
--
.../ecpg/test/compat_oracle/char_array.pgc | 16 ++-
.../ecpg/test/expected/compat_oracle-char_array.
Support INOUT arguments in procedures
In a top-level CALL, the values of INOUT arguments will be returned as a
result row. In PL/pgSQL, the values are assigned back to the input
arguments. In other languages, the same convention as for return a
record from a function is used. That does not requ
On 3/13/18 20:38, Michael Meskes wrote:
> Add Oracle like handling of char arrays.
>
> In some cases Oracle Pro*C handles char array differently than ECPG. This
> patch
> adds a Oracle compatibility mode to make ECPG behave like Pro*C.
Please check these compiler warnings:
char_array.pgc: In fu
Peter Eisentraut writes:
> I think the problem is rather that we somehow need to tell it to link
> src/common/string.c into pgtypeslib.
Yeah, that's what I supposed.
Looking at pgtypeslib, there's already infrastructure for collecting
stuff from src/port/, and I see you added some for src/common
Log when a BRIN autosummarization request fails
Autovacuum's 'workitem' request queue is of limited size, so requests
can fail if they arrive more quickly than autovacuum can process them.
Emit a log message when this happens, to provide better visibility of
this.
Backpatch to 10. While this rep
Log when a BRIN autosummarization request fails
Autovacuum's 'workitem' request queue is of limited size, so requests
can fail if they arrive more quickly than autovacuum can process them.
Emit a log message when this happens, to provide better visibility of
this.
Backpatch to 10. While this rep
Fix comment for ExecProcessReturning
resultRelInfo is the argument for the function, not projectReturning.
Author: Etsuro Fujita
Discussion: https://postgr.es/m/5aa8e11e.1040...@lab.ntt.co.jp
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/97d18ce27da47de2de60de8df
On 3/13/18 21:10, David Rowley wrote:
> On 14 March 2018 at 08:10, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> Move strtoint() to common
>>
>> Buildfarm seems to think this isn't quite baked for Windows.
>
> Yeah, "restrict" seems to be C99, and the Microsoft compilers don't
> quite know abo
Add tests for reinit.c
This tests how the different forks of unlogged tables behave in crash
recovery.
Author: David Steele
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/df411e7c664ee9a2395eb8c7a74ceddea818d489
Modified Files
--
src/test/recovery/t/
30 matches
Mail list logo
