This is wrong, current code does well for this case. I should
broke the code during investigating the problem.
> > So, to make the windows version behave as the same,
> > dsm_impl_windows should return false if GetLastError() ==
> > ERROR_ALREADY_EXISTS regardless of hmap is valid. The current
> >
On Thu, Oct 15, 2015 at 6:52 PM, Robert Haas wrote:
>
> On Thu, Oct 15, 2015 at 7:00 AM, Amit Kapila
wrote:
> >
> > From what I understood by looking at code in this area, I think the
check
> > params != estate->paramLI and code under it is required for parameters
> > that are setup by setup_unsh
On 16 October 2015 at 02:47, Pavel Stehule wrote:
> postgres=# do $$
> x = plpy.SPIError('Nazdarek');
> x.spidata = (100, "Some detail", "some hint", None, None);
> raise x;
> $$ language plpythonu;
Shouldn't that look more like
raise plpy.SPIError(msg="Message", sqlstate="0P001", hint="Turn i
On 16 October 2015 at 01:07, Robbie Harwood wrote:
> The short - and probably most important - answer is that no, I haven't
> tested it, and it would be difficult for me to do so quickly.
IIRC it's pretty easy to fire up AWS instances that're primary domain
controllers, and then join a Pg box to
Sorry, forgot to close the valid handle on return.
> > Currently we are using error level as ERROR for creating dsm during
> > postmaster startup which is not right and rather we should use error
> > level as LOG. Can you please try with the attached patch and see
> > if the issue is fixed for
On 14 October 2015 at 04:01, Robert Haas wrote:
> This patch is marked as Ready for Committer in the CommitFest
> application. Here is my attempt to summarize the votes upthread:
>
> Tom Lane: plpgsql RAISE is sufficient; we don't need this.
> Pavel Stehule: could be replaced by custom function,
Hello,
> Currently we are using error level as ERROR for creating dsm during
> postmaster startup which is not right and rather we should use error
> level as LOG. Can you please try with the attached patch and see
> if the issue is fixed for you.
It seems somewhat strange. Looking into the crea
2015-10-16 2:47 GMT+02:00 Jim Nasby :
> On 9/10/15 10:56 AM, Andres Freund wrote:
>
>> >The only complaint I've seen in this thread that seems like a valid
>>> >deficiency is that RAISE can't deal with treating the error severity
>>> level
>>> >as a variable. But surely we should address that as
On Fri, Oct 16, 2015 at 8:40 AM, Haribabu Kommi
wrote:
>
> On Thu, Oct 15, 2015 at 11:45 PM, Amit Kapila
wrote:
> > On Thu, Oct 15, 2015 at 5:39 PM, Haribabu Kommi <
kommi.harib...@gmail.com>
> > wrote:
> >>
> >
> > I am aware of that and purposefully kept it for a consecutive patch.
> > There ar
On 16 October 2015 at 11:51, Craig Ringer wrote:
> Document it as a "don't do that, if you do it you get to keep the pieces"?
Thinking about this some more, having per-change origins makes sense
when you're not using origin LSNs, such as when you're not replaying
from another PostgreSQL instance.
On Mon, Oct 5, 2015 at 8:20 AM, Amit Kapila wrote:
> [ new patch for heapam.c changes ]
I went over this in a fair amount of detail and reworked it somewhat.
The result is attached as parallel-heapscan-revised.patch. I think
the way I did this is a bit cleaner than what you had, although it's
ba
On 15 October 2015 at 20:55, Andres Freund wrote:
> On 2015-10-15 20:52:41 +0800, Craig Ringer wrote:
>> You'll note that the tests fail. When the replication origin is reset
>> and set again with pg_replication_origin_xact_setup mid-xact, the
>> origin identity exposed to the decoding plugin call
Andrew Dunstan writes:
> On 10/15/2015 05:16 PM, Josh Berkus wrote:
>> On 10/15/2015 01:10 PM, Tom Lane wrote:
>>> I think this means that we should get rid of proc->globals and instead
>>> manufacture a new globals dict locally in each call to PLy_exec_function
>>> or PLy_exec_trigger.
>> Don't
On Fri, Oct 16, 2015 at 2:10 PM, Haribabu Kommi
wrote:
> On Thu, Oct 15, 2015 at 11:45 PM, Amit Kapila wrote:
>> On Thu, Oct 15, 2015 at 5:39 PM, Haribabu Kommi
>> wrote:
>>>
>>>
>>>
>>> On Thu, Oct 15, 2015 at 6:32 PM, Amit Kapila
>>> wrote:
>>> > On Wed, Oct 14, 2015 at 3:29 AM, Robert Haas
On Thu, Oct 15, 2015 at 8:35 PM, Dmitry Vasilyev
wrote:
> I think that function dsm_impl_windows() with EACCES error should not
> do ereport() with FATAL level. It works, but it is likely to make an
> infinite loop if the user will receive EACCES error.
>
>
Currently we are using error level as E
On 2015/10/16 2:14, Robert Haas wrote:
On Thu, Oct 15, 2015 at 3:04 AM, Kyotaro HORIGUCHI
wrote:
I confirmed that an epqtuple of foreign parameterized scan is
correctly rejected by fdw_recheck_quals with modified outer
tuple.
I have no objection to this and have two humble comments.
In file_f
On Thu, Oct 15, 2015 at 11:45 PM, Amit Kapila wrote:
> On Thu, Oct 15, 2015 at 5:39 PM, Haribabu Kommi
> wrote:
>>
>>
>>
>> On Thu, Oct 15, 2015 at 6:32 PM, Amit Kapila
>> wrote:
>> > On Wed, Oct 14, 2015 at 3:29 AM, Robert Haas
>> > wrote:
>> > I think this got messed up while rebasing on top
I have spend the past few days updating our TODO list, removing
completed and now-unnecessary items:
https://wiki.postgresql.org/wiki/Todo
I encourage others to also update the list to make it more accurate.
Thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Fri, Oct 16, 2015 at 9:07 AM, Thomas Munro
wrote:
> On Wed, Oct 7, 2015 at 8:52 AM, Robert Haas wrote:
>> On Thu, Oct 1, 2015 at 11:01 PM, Michael Paquier
>> wrote:
Right, see attached.
>>>
>>> It seems to me that we could as well simplify checkpoint.c and
>>> logical.c. In those files v
Also, please make sure your patch is registered in
https://commitfest.postgresql.org/7/ so that we don't forget.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hack
zhangjinyu wrote:
> However I wonder if it would be simpler to have the dtup structure have
> the pointers, so that you can pass it as NULL in the first call and then
> followup calls reuse the one allocated in the first call.
> Jinyu: the memory is allocated from perRangeCxt and per
On 10/7/15 6:44 AM, Filip Rembiałkowski wrote:
Oct 2 2015 01:19 "Michael Paquier" mailto:michael.paqu...@gmail.com>> wrote:
>
> On Thu, Oct 1, 2015 at 10:43 PM, Filip Rembiałkowski
mailto:filip.rembialkow...@gmail.com>>
wrote:
> > I just want to understand why there is LOCK TABLE not LOCK TABL
On 9/10/15 10:56 AM, Andres Freund wrote:
>The only complaint I've seen in this thread that seems like a valid
>deficiency is that RAISE can't deal with treating the error severity level
>as a variable. But surely we should address that as a new RAISE feature,
>not by inventing a SQL wrapper tha
On 10/13/15 10:18 AM, Jinyu wrote:
At 2015-10-12 23:46:12, "Jim Nasby" wrote:
On 10/11/15 6:55 AM, Jinyu wrote:
Are there other solutions to improve the concurency of vacuum
full/cluster and select statement on the same relation?
ISTM that if we were going to put effort into this it makes mo
On Thu, Oct 15, 2015 at 12:05:53PM -0400, Robert Haas wrote:
> On Thu, Oct 15, 2015 at 1:51 AM, Noah Misch wrote:
> >> This wouldn't require any
> >> modification to the current plpgsql_param_fetch() at all, but the new
> >> function would steal its bms_is_member() test. Furthermore, no user
> >
On Wed, Oct 7, 2015 at 8:52 AM, Robert Haas wrote:
> On Thu, Oct 1, 2015 at 11:01 PM, Michael Paquier
> wrote:
>>> Right, see attached.
>>
>> It seems to me that we could as well simplify checkpoint.c and
>> logical.c. In those files volatile casts are used as well to protect
>> from reordering f
On 2015/10/16 0:21, Alvaro Herrera wrote:
> Amit Langote wrote:
>> Came across a couple of unclear comments about functions returning
>> ObjectAddress. Attached fixes them.
>
> Thanks, pushed to 9.5 and master.
Thanks, Alvaro.
Regards,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hack
On 10/15/2015 02:16 PM, Josh Berkus wrote:
On 10/15/2015 01:10 PM, Tom Lane wrote:
I think this means that we should get rid of proc->globals and instead
manufacture a new globals dict locally in each call to PLy_exec_function
or PLy_exec_trigger. For SETOF functions it would be necessary to ke
On Tuesday, September 15, 2015 12:07 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> Alvaro Herrera wrote:
>>> I would place it inside src/test/modules, so that buildfarm
>>> runs it automatically; I'm not sure it will pick up things in
>>> src/test.
>>
>> As it stands now, the test is get
On 10/15/2015 05:16 PM, Josh Berkus wrote:
On 10/15/2015 01:10 PM, Tom Lane wrote:
I think this means that we should get rid of proc->globals and instead
manufacture a new globals dict locally in each call to PLy_exec_function
or PLy_exec_trigger. For SETOF functions it would be necessary to
On 10/15/2015 01:10 PM, Tom Lane wrote:
> I think this means that we should get rid of proc->globals and instead
> manufacture a new globals dict locally in each call to PLy_exec_function
> or PLy_exec_trigger. For SETOF functions it would be necessary to keep
> the globals dict reference somewher
I looked into bug #13683,
http://www.postgresql.org/message-id/20151015135804.3019.31...@wrigleys.postgresql.org
It looks to me like plpython basically doesn't work at all for re-entrant
calls to plpython functions, because all executions of a given function
share the same "globals" dict, which do
2015-10-13 17:22 GMT-03:00 Rodolfo Campero :
> La lista de correo apropiada para tu consulta es pgsql-es-ayuda
> (pgsql-es-ayuda(at)postgresql(dot)org).
> Saludos,
>
> El 13 de octubre de 2015, 16:51, Enrique Escobar
> escribió:
>>
>> Hola
>> Tengo una duda, que tan pesado es poner ssl en una base
Hi
2015-10-09 15:22 GMT+02:00 Peter Eisentraut :
> On 10/8/15 6:11 AM, Pavel Stehule wrote:
> > We cannot to raise PostgreSQL exception with setting all possible
> > fields.
>
> Such as? If there are fields missing, let's add them.
>
> > I propose new function
> >
> > plpy.ereport(level, [ messa
Robert Haas writes:
> On Thu, Oct 15, 2015 at 1:23 PM, Tom Lane wrote:
>> Curious that you didn't see something similar. Perhaps it depends on
>> make version? But I spot-checked a couple of buildfarm critters and
>> they both showed similar noise in the make step.
> Yeah, I did to a parallel
On Wed, Oct 14, 2015 at 3:14 AM, Andres Freund wrote:
>> What would happen if we didn't do anything at all?
>
> Nothing, really. It's essentially some code beautification. A worthwhile
> goal, but certainly not a release blocker.
While I agree with this assessment, I think that there is value in
On Thu, Oct 15, 2015 at 1:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 15, 2015 at 1:01 PM, Tom Lane wrote:
>>> This patch appears to have broken parallel builds. I get this:
>
>> Thanks for the report. I have reverted the patch.
>
> Problem's gone, so it definitely was that pat
Robert Haas wrote:
> - Oversize item computation needs more testing (c.f. ereport(ERROR)
> calls in brin_getinsertbuffer). This is pretty vague, and there's no
> thread linked. If there's a stability issue here, presumably it falls
> to Alvaro to fix it. But I don't know who added this item or
Robert Haas writes:
> On Thu, Oct 15, 2015 at 1:01 PM, Tom Lane wrote:
>> This patch appears to have broken parallel builds. I get this:
> Thanks for the report. I have reverted the patch.
Problem's gone, so it definitely was that patch and not something else.
Curious that you didn't see som
On Tue, Oct 13, 2015 at 3:47 PM, Robert Haas wrote:
> On Tue, Aug 18, 2015 at 12:08 PM, Alvaro Herrera
> wrote:
>> Robert Haas wrote:
>>> On Sat, Aug 15, 2015 at 6:45 PM, Mark Johnston wrote:
>>
>>> > The bug is in src/backend/Makefile. probes.o, the dtrace(1)-generated
>>> > object file, depend
On Thu, Oct 15, 2015 at 1:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> Have dtrace depend on object files directly, not objfiles.txt
>
> This patch appears to have broken parallel builds. I get this:
>
> $ make -j8 -s
> cat: access/objfiles.txt: No such file or directory
> cat: bootstrap/objf
On Thu, Oct 15, 2015 at 3:04 AM, Kyotaro HORIGUCHI
wrote:
> I confirmed that an epqtuple of foreign parameterized scan is
> correctly rejected by fdw_recheck_quals with modified outer
> tuple.
>
> I have no objection to this and have two humble comments.
>
> In file_fdw.c, the comment for the last
Craig Ringer writes:
> On 14 October 2015 at 06:34, Robbie Harwood wrote:
>> Alright, here's v3. As requested, it's one patch now.
>
> I hate to ask, but have you looked at how this interacts with Windows?
>
> We support Windows SSPI (on a domain-member host) authenticating to a
> PostgreSQL se
Robert Haas writes:
> Have dtrace depend on object files directly, not objfiles.txt
This patch appears to have broken parallel builds. I get this:
$ make -j8 -s
cat: access/objfiles.txt: No such file or directory
cat: bootstrap/objfiles.txt: No such file or directory
cat: catalog/objfiles.txt:
On Wed, Oct 14, 2015 at 6:30 AM, Andres Freund wrote:
> On 2015-10-14 01:54:46 +0300, Amir Rohan wrote:
>> Andres, please see upthread for quite a bit on what it doesn't do, and
>> why having it in the server is both an advantages and a shortcoming.
>
> As far as I have skimmed the thread it's onl
On Wed, Oct 14, 2015 at 7:11 PM, Peter Geoghegan wrote:
> On Wed, Oct 14, 2015 at 4:09 PM, Robert Haas wrote:
>> I wonder if it wouldn't be better to just add a separate Boolean
>> indicating exactly the thing we care about. This doesn't seem
>> particularly easy to understand and verify.
>
> I'
On Thu, Oct 15, 2015 at 1:51 AM, Noah Misch wrote:
> Tests of prm->prmtype and paramLI->paramFetch appear superfluous. Given that
> the paramListCopyHook callback would return a complete substitute
> ParamListInfo, I wouldn't expect SerializeParamList() to examine the the
> original paramLI->para
Amit Langote wrote:
> Came across a couple of unclear comments about functions returning
> ObjectAddress. Attached fixes them.
Thanks, applied.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsq
Amit Langote wrote:
> Came across a couple of unclear comments about functions returning
> ObjectAddress. Attached fixes them.
Thanks, pushed to 9.5 and master.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
I think that function dsm_impl_windows() with EACCES error should not
do ereport() with FATAL level. It works, but it is likely to make an
infinite loop if the user will receive EACCES error.
On Чт, 2015-10-15 at 17:46 +0300, Dmitry Vasilyev wrote:
> I’ve created 2 unprivileged users: user1 and u
I’ve created 2 unprivileged users: user1 and user2; and registered 2
services thorough pg_ctl register respectively under these 2 users. If
first service is running second could not start and vice versa.
Dmitry Vasilyev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Comp
2015-10-15 15:42 GMT+02:00 Tom Lane :
> "Shulgin, Oleksandr" writes:
> > I was thinking about this and what seems to be the biggest problem is
> when
> > to actually turn the feature on. It seems unlikely that someone will
> want
> > to enable it unconditionally. Enabling per-backend also doesn
Hello, Michal.
Take a look in MicroOLAP Database Designer for PostgreSQL.
You may use it in such way:
1. Reverse Engineering for existent database
2. Apply some changes
3. Modify database - you will get SQL script with all changes
http://microolap.com/products/database/postgresql-designer/
You
"Shulgin, Oleksandr" writes:
> I was thinking about this and what seems to be the biggest problem is when
> to actually turn the feature on. It seems unlikely that someone will want
> to enable it unconditionally. Enabling per-backend also doesn't seem to be
> a good approach because you don't k
On Thu, Oct 15, 2015 at 7:00 AM, Amit Kapila wrote:
> On Mon, Oct 12, 2015 at 9:16 PM, Robert Haas wrote:
>> On Sun, Oct 11, 2015 at 7:56 PM, Noah Misch wrote:
>> > I see no mention in this thread of varatt_indirect, but I anticipated
>> > datumSerialize() reacting to it the same way datumCopy()
On 2015-10-15 20:52:41 +0800, Craig Ringer wrote:
> You'll note that the tests fail. When the replication origin is reset
> and set again with pg_replication_origin_xact_setup mid-xact, the
> origin identity exposed to the decoding plugin callbacks for all
> records (including those created before
On 15 October 2015 at 20:11, Craig Ringer wrote:
> On 15 October 2015 at 19:04, Andres Freund wrote:
>
>> As far as I can see all the other places have it assigned.
>
> Ok, thanks. Not much need for a followup patch then, if you're not
> using the test changes part.
Here's what I used for my tes
On Thu, Oct 15, 2015 at 5:39 PM, Haribabu Kommi
wrote:
>
>
>
> On Thu, Oct 15, 2015 at 6:32 PM, Amit Kapila
wrote:
> > On Wed, Oct 14, 2015 at 3:29 AM, Robert Haas
wrote:
> > I think this got messed up while rebasing on top of Gather node
> > changes, but nonetheless, I have changed it such that
On 14 October 2015 at 06:34, Robbie Harwood wrote:
> Alright, here's v3. As requested, it's one patch now.
I hate to ask, but have you looked at how this interacts with Windows?
We support Windows SSPI (on a domain-member host) authenticating to a
PostgreSQL server using gssapi with spnego.
We
On 15 October 2015 at 19:04, Andres Freund wrote:
> As far as I can see all the other places have it assigned.
Ok, thanks. Not much need for a followup patch then, if you're not
using the test changes part.
>>table public.origin_tbl: INSERT: id[integer]:6 data[text]:'from second
>>origin' -- or
On Thu, Oct 15, 2015 at 6:32 PM, Amit Kapila
wrote:
> On Wed, Oct 14, 2015 at 3:29 AM, Robert Haas
wrote:
> I think this got messed up while rebasing on top of Gather node
> changes, but nonetheless, I have changed it such that PartialSeqScan
> node handling is after SeqScan.
Currently, the expl
On Wed, Oct 14, 2015 at 7:34 AM, Robbie Harwood wrote:
> Alright, here's v3. As requested, it's one patch now. Other things
> addressed herein include:
> Essentially, the problem is that socket_putmessage_noblock() needs to
> know the size of the message to put in the buffer but we can't know
>
> -Original Message-
> From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp]
> Sent: Thursday, October 15, 2015 7:00 PM
> To: Kaigai Kouhei(海外 浩平); Kyotaro HORIGUCHI
> Cc: pgsql-hackers@postgresql.org; shigeru.han...@gmail.com;
> robertmh...@gmail.com
> Subject: Re: [HACKERS] Foreign joi
On October 15, 2015 1:02:04 PM GMT+02:00, Craig Ringer
wrote:
>On 15 October 2015 at 17:43, Andres Freund wrote:
>
>>> I guess since it'll be InvalidRepOriginId otherwise, that makes
>sense.
>>
>> That's not the point. XACT_XINFO_HAS_ORIGIN is about
>> origin_lsn/timestamp, it doesn't have anyth
On 15 October 2015 at 17:43, Andres Freund wrote:
>> I guess since it'll be InvalidRepOriginId otherwise, that makes sense.
>
> That's not the point. XACT_XINFO_HAS_ORIGIN is about
> origin_lsn/timestamp, it doesn't have anything to do with the record
> origin (which is included in many more type
On Mon, Oct 12, 2015 at 9:16 PM, Robert Haas wrote:
>
> On Sun, Oct 11, 2015 at 7:56 PM, Noah Misch wrote:
> > I see no mention in this thread of varatt_indirect, but I anticipated
> > datumSerialize() reacting to it the same way datumCopy() reacts. If
> > datumSerialize() can get away without d
On Thu, Oct 15, 2015 at 2:27 AM, Robert Haas wrote:
> On Wed, Oct 14, 2015 at 7:30 AM, Ashutosh Bapat
> wrote:
> > The patch uses a factor of 1.1 (10% increase) to multiple the startup and
> > total costs in fpinfo for unsorted data.
> >
> > This change has caused the plans for few queries in th
On Thu, Oct 15, 2015 at 11:27 AM, FattahRozzaq wrote:
> Hi guys,
>
> I'm running some test.
>
>
> However, I'm stuck in restoring a PostgreSQL 9.2.4 dump to PostgreSQL
> 9.4.5 database.
> I'm doing the backup using pg_dump version PostgreSQL 9.2.4 in text
> file (SQL dump).
> I'm trying to restor
Hi
2015-10-15 11:27 GMT+02:00 FattahRozzaq :
> Hi guys,
>
> I'm running some test.
>
>
> However, I'm stuck in restoring a PostgreSQL 9.2.4 dump to PostgreSQL
> 9.4.5 database.
> I'm doing the backup using pg_dump version PostgreSQL 9.2.4 in text
> file (SQL dump).
> I'm trying to restore it to P
On 2015/10/15 11:36, Kouhei Kaigai wrote:
>>> Once again, if FDW driver is responsible to construct join-tuple from
>>> the base relation's tuple cached in EPQ slot, this case don't need to
>>> kick remote query again, because all the materials to construct join-
>>> tuple are already held locally.
Hello, Horiguchi-san.
Sorry for late reply.
> explain analyze
> select data_x, data_y, num from check_test_div join inner_t on
> check_test_div.id + 1 = inner_t.id;
>
> Makes the mutation fail then result in an assertion failure.
>
> | TRAP: FailedAssertion("!(list_length(check_constr) ==
> |
On 2015.10.15 at 17:13:46 +0800, Craig Ringer wrote:
> On 14 October 2015 at 18:41, Victor Wagner wrote:
>
> > 5. Added new parameter readonly=boolean. If this parameter is false (the
> > default) upon successful connection check is performed that backend is
> > not in the recovery state. If so,
On 2015-10-15 17:05:33 +0800, Craig Ringer wrote:
> On 15 October 2015 at 16:48, Andres Freund wrote:
> > On 2015-10-15 16:02:23 +0800, Craig Ringer wrote:
> >> There's an oversight in replication origins support in logical
> >> decoding, where the origin node ID isn't passed correctly to callback
Hi guys,
I'm running some test.
However, I'm stuck in restoring a PostgreSQL 9.2.4 dump to PostgreSQL
9.4.5 database.
I'm doing the backup using pg_dump version PostgreSQL 9.2.4 in text
file (SQL dump).
I'm trying to restore it to PostgreSQL 9.4.5 usng psql.
The restoration error message was a
On Tue, Sep 29, 2015 at 7:52 PM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
>
> This is not a change of the direction, but rather of the approach.
> Hitting a process with a signal and hoping it will produce a meaningful
> response in all circumstances without disrupting its current
On 14 October 2015 at 18:41, Victor Wagner wrote:
> 5. Added new parameter readonly=boolean. If this parameter is false (the
> default) upon successful connection check is performed that backend is
> not in the recovery state. If so, connection is not considered usable
> and next host is tried.
On 15 October 2015 at 16:48, Andres Freund wrote:
> On 2015-10-15 16:02:23 +0800, Craig Ringer wrote:
>> There's an oversight in replication origins support in logical
>> decoding, where the origin node ID isn't passed correctly to callbacks
>> except for the origin filter callback. All other call
On 2015-10-15 16:02:23 +0800, Craig Ringer wrote:
> There's an oversight in replication origins support in logical
> decoding, where the origin node ID isn't passed correctly to callbacks
> except for the origin filter callback. All other callbacks see it as
> InvalidRepOriginId.
Only for the tran
On Thu, Oct 15, 2015 at 1:45 AM, Euler Taveira wrote:
> On 14-10-2015 17:35, kolo hhmow wrote:
>
>> Yes, but this is very ugly solution, becasue you have to restart
>> postgresql daemon each time you have added a new user.
>>
> >
> Restart != Reload. You can even do it using SQL.
>
Yes, this is
Hi all
There's an oversight in replication origins support in logical
decoding, where the origin node ID isn't passed correctly to callbacks
except for the origin filter callback. All other callbacks see it as
InvalidRepOriginId.
It's a one-line fix, but I've added support in test_decoding to
val
On Wed, Oct 14, 2015 at 3:29 AM, Robert Haas wrote:
>
> On Tue, Oct 13, 2015 at 2:45 AM, Amit Kapila
wrote:
> > Attached is rebased patch for partial seqscan support.
>
> Review comments:
>
> - If you're going to pgindent execParallel.c, you need to add some
> entries to typedefs.list so it doesn
On Thu, Oct 15, 2015 at 11:33 AM, Ivan Novick wrote:
> Hi,
>
> If we have two queries, Query A and Query B that both return same columns.
>
> If we do Union All View will postgresql execute Query A and then Query B
> sequentially?
>
> Does the work being discussed around parallel query have the p
On 2015.10.14 at 14:47:46 +0200, Shulgin, Oleksandr wrote:
>
> So what exactly would happen with this command: PGHOST=host1 psql -h host2
>
> Or this one: PGHOST=host1 psql host=host2
The right thing - value of the PGHOST environment variable is ignored,
and explicitely specified host is used.
Hello,
I confirmed that an epqtuple of foreign parameterized scan is
correctly rejected by fdw_recheck_quals with modified outer
tuple.
I have no objection to this and have two humble comments.
In file_fdw.c, the comment for the last parameter just after the
added line seems to be better to be a
84 matches
Mail list logo
