On 5 January 2017 at 04:50, Michael Paquier wrote:
> The perldoc documentation is broken for the new routines.
...
> Attached is a patch to fix all those small issues.
Thanks, looks good, will apply.
> It may be a good idea to run perltidy on top of that to be honest...
Should we add that to
On 4 January 2017 at 21:20, Simon Riggs wrote:
> On 31 December 2016 at 08:36, Stas Kelvich wrote:
>> Here is resubmission of patch to implement logical decoding of two-phase
>> transactions (instead of treating them
>> as usual transaction when commit) [1] I’ve slightly polished things and used
On 2017/01/05 13:19, Ashutosh Bapat wrote:
Hmm. If I understand the patch correctly, it does not return any path
when merge join is allowed and there are merge clauses but no hash
clauses. In this case we will not create a foreign join path, loosing
some optimization. If we remove GetExistingLoca
On Wed, Jan 4, 2017 at 5:21 PM, Mithun Cy wrote:
I have re-based the patch to fix one compilation warning
@_hash_doinsert where variable bucket was only used for Asserting but
was not declared about its purpose.
--
Thanks and Regards
Mithun C Y
EnterpriseDB: http://www.enterprisedb.com
cache_h
On Wed, Jan 04, 2017 at 09:58:26PM -0800, David Fetter wrote:
> On Sun, Jan 01, 2017 at 07:57:33PM +0900, Michael Paquier wrote:
> > On Sun, Jan 1, 2017 at 12:34 PM, David Fetter wrote:
> > > I've rolled your patches into this next one and clarified the commit
> > > message, as there appears to ha
On Sun, Jan 01, 2017 at 07:57:33PM +0900, Michael Paquier wrote:
> On Sun, Jan 1, 2017 at 12:34 PM, David Fetter wrote:
> > I've rolled your patches into this next one and clarified the commit
> > message, as there appears to have been some confusion about the scope.
>
> Is there actually a meani
On Wed, Dec 21, 2016 at 10:53 PM, Robert Haas wrote:
> On a first read-through of this patch -- I have not studied it in
> detail yet -- this looks pretty good to me. One concern is that this
> patch adds a bit of code to XLogInsert(), which is a very hot piece of
> code. Conceivably, that migh
On Wed, Jan 4, 2017 at 2:57 PM, Andrew Borodin wrote:
> 2017-01-04 10:23 GMT+05:00 amul sul :
>> One more query, can we modify
>> BackgroundSessionStart()/BackgroundSession struct to get background
>> worker PID as well?
> I think since session always has a PID it's absoultley reasonable to return
On Thu, Jan 5, 2017 at 10:21 AM, Craig Ringer wrote:
> On 5 January 2017 at 09:19, Craig Ringer wrote:
>
>> so here's a rebased series on top of master. No other changes.
>
> Now with actual patches.
Looking at the PostgresNode code in 0001...
+=pod $node->pg_recvlogical_upto(self, dbname, slot_
On Thu, Jan 5, 2017 at 8:58 AM, Kouhei Kaigai wrote:
> Unfortunately, it was not possible. Probably, administrator privilege will be
> needed for this operation.
Adding a patch to a CF in progress indeed requires administrator privileges,
> May I add it to the CF:2017-03?
I can notice that the
On Thu, Jan 5, 2017 at 5:10 AM, Simon Riggs wrote:
> On 4 January 2017 at 03:54, Haribabu Kommi wrote:
>
>> Latest patch is attached.
>
> The "method" column should be called "auth" or "auth_method" or
> "authentication"
>
> I think we should have some tests, but I'll hear your views on that.
>
On Thu, Jan 5, 2017 at 1:58 AM, Simon Riggs wrote:
> On 4 January 2017 at 08:16, Craig Ringer wrote:
>> When committed I will update the decoding on standby series to omit
>> these pre-requisite patches.
>
> Committed, thanks.
I was planning a round of reviews of those patches, but you were fast
Tatsuo Ishii writes:
> In:
> https://www.postgresql.org/docs/devel/static/runtime-config-file-locations.html
> "Specifies the configuration file for Section 20.2, $B!H(BUser Name
> Maps$B!I(B
> user name mapping" looks pretty strange to me because a raw section
> name appears.
Yeah, it's def
On 2017/01/05 8:05, Tom Lane wrote:
> Ashutosh Bapat writes:
>> Right. But I think it's better to use attribute id, in case the code
>> raising this error changes for any reason in future.
>
> I agree. The parent's "tdhasoid" flag is definitely based on the
> existence of an ObjectIdAttributeNum
On Wed, Jan 4, 2017 at 8:24 PM, Stephen Frost wrote:
> Ashutosh,
>
> I realize you were replying to yourself, but you probably didn't need to
> include the entire thread below or to top-post.
Sorry, that was unintentional.
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> 1. pg_ex
>
>> Hmm. If I understand the patch correctly, it does not return any path
>> when merge join is allowed and there are merge clauses but no hash
>> clauses. In this case we will not create a foreign join path, loosing
>> some optimization. If we remove GetExistingLocalJoinPath, which
>> returns a p
On Thu, Jan 5, 2017 at 8:20 AM, Etsuro Fujita
wrote:
> On 2016/12/27 16:41, Etsuro Fujita wrote:
>>
>> On 2016/12/22 1:04, Ashutosh Bapat wrote:
>>>
>>> 2. We should try to look for other not-so-cheap paths if the cheapest
>>> one is
>>> paramterized. You might want to use get_cheapest_path_for_pa
On Thu, Jan 5, 2017 at 9:40 AM, Ashutosh Bapat
wrote:
>>
>>
>>> Hmm. If I understand the patch correctly, it does not return any path
>>> when merge join is allowed and there are merge clauses but no hash
>>> clauses. In this case we will not create a foreign join path, loosing
>>> some optimizati
>
>
>> Hmm. If I understand the patch correctly, it does not return any path
>> when merge join is allowed and there are merge clauses but no hash
>> clauses. In this case we will not create a foreign join path, loosing
>> some optimization. If we remove GetExistingLocalJoinPath, which
>> returns a
On 4 January 2017 at 01:16, Michael Paquier wrote:
> On Tue, Jan 3, 2017 at 6:23 AM, Jim Nasby wrote:
>> + /* Check if wal_segment_size is in the power of 2 */
>> + for (i = 0;; i++, pow2 = pow(2, i))
>> + if (pow2 >= wal_segment_size)
>> +
>
>> The code updating attinhcount and then updating the catalogs is same
>> for user defined attributes and OID. Should we separate it out into a
>> function and use that function instead of duplicating the code?
>
> Didn't really seem worth the trouble ... maybe if it gets any longer
> it'd be ap
On 2016/12/28 17:34, Ashutosh Bapat wrote:
On Wed, Dec 28, 2016 at 1:29 PM, Etsuro Fujita
wrote:
On 2016/12/28 15:54, Ashutosh Bapat wrote:
On Wed, Dec 28, 2016 at 9:20 AM, Etsuro Fujita
wrote:
On 2016/12/27 22:03, Ashutosh Bapat wrote:
If mergejoin_allowed is true and mergeclauselist is no
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander
> For the pg_ctl changes, we're going from removing all privilieges from the
> token, to removing none. Are there any other privileges that we should be
> worried about? I think you m
On Tue, Nov 29, 2016 at 6:27 AM, Tom Lane wrote:
> Thomas Munro writes:
>> I bet other allocators also do badly with "32KB plus a smidgen". To
>> minimise overhead we'd probably need to try to arrange for exactly
>> 32KB (or some other power of 2 or at least factor of common page/chunk
>> size?)
On 2016/12/27 22:03, Ashutosh Bapat wrote:
You wrote:
3. Talking about saving some CPU cycles - if a clauseless full join can be
implemented only using merge join, probably that's the only path available
in
the list of paths for the given relation. Instead of building the same
path
anew, should
On 2016/12/27 16:41, Etsuro Fujita wrote:
On 2016/12/22 1:04, Ashutosh Bapat wrote:
2. We should try to look for other not-so-cheap paths if the cheapest
one is
paramterized. You might want to use get_cheapest_path_for_pathkeys()
to find a
suitable unparameterized path by passing NULL for requir
On 4 January 2017 at 16:19, Craig Ringer wrote:
> On 4 January 2017 at 12:15, Craig Ringer wrote:
>
>> That's particularly relevant to you Simon as you expressed a wish to
>> commit the new streaming rep tests.
Simon committed 1, 2, 3 and 5:
* Extra PostgresNode methods
* pg_recvlogical --endpo
On 01/03/2017 11:56 PM, Tomas Vondra wrote:
Hi,
...
I'll push results for larger ones once those tests complete (possibly
tomorrow).
I just pushed additional results (from the additional scales) to the git
repositories. On the larger (16/32-cores) machine with 2x e5-2620, the
results look
On Thu, Jan 5, 2017 at 12:33 AM, Robert Haas wrote:
> On Wed, Jan 4, 2017 at 9:47 AM, Simon Riggs wrote:
>> On 4 January 2017 at 13:57, Robert Haas wrote:
>>> On Wed, Jan 4, 2017 at 3:05 AM, Simon Riggs wrote:
Strange response. Nothing has been assumed. I asked for tests and you
provi
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Thursday, January 05, 2017 5:29 AM
> To: Kohei KaiGai
> Cc: Kaigai Kouhei(海外 浩平) ; Jeevan Chalke
> ; pgsql-hackers@postgresql.org; Etsuro
> Fuji
In:
https://www.postgresql.org/docs/devel/static/runtime-config-file-locations.html
---
ident_file (string)
Specifies the configuration file for Section 20.2, “User Name Maps” user
name mapping (customarily called pg_ident.conf). This parameter
Hello, Peter,
I apologize for a silence since the last CF.
I've tested your last patch and have several nitpickings:
1. The fact COPY ignores GENERATED ALWAYS constraint (treats as
GENERATED BY DEFAULT) should be mentioned as well as rules.
2. Usually error message for identical columns (with
On 5 January 2017 at 08:35, Craig Ringer wrote:
> On 5 January 2017 at 01:49, Fabien COELHO wrote:
>>
>>> ok understand
>>
>>
>> Good. So we seem to agree that GUCS are transactional?
>
> No. We don't agree. They aren't.
Uh. I take that back.
craig=> SET x.s = 'x';
SET
craig=> BEGIN;
BEGIN
crai
On 5 January 2017 at 01:49, Fabien COELHO wrote:
>
>> ok understand
>
>
> Good. So we seem to agree that GUCS are transactional?
No. We don't agree. They aren't.
The effects of SET LOCAL are reverted whether you commit or rollback.
The effects of SET SESSION are never reverted, whether you comm
On Tue, Nov 29, 2016 at 8:36 PM, Haribabu Kommi
wrote:
>
>
> On Sat, Nov 26, 2016 at 4:48 PM, Tom Lane wrote:
>
>> Haribabu Kommi writes:
>> > Currently the casting is supported from macaddr to macaddr8, but not the
>> > other way. This is because, not all 8 byte MAC addresses can be
>> convert
On 01/04/2017 04:36 PM, Craig Ringer wrote:
> On 5 January 2017 at 08:35, Craig Ringer wrote:
>> On 5 January 2017 at 01:49, Fabien COELHO wrote:
>>> Good. So we seem to agree that GUCS are transactional?
>>
>> No. We don't agree. They aren't.
>
> Uh. I take that back.
>
> craig=> SET x.s = 'x
On 2 January 2017 at 22:24, Craig Ringer wrote:
>
>
> On 2 Jan. 2017 20:20, "Simon Riggs" wrote:
>
> On 21 December 2016 at 13:23, Simon Riggs wrote:
>
>> Fix it up and I'll commit. Thanks for the report.
>
> I was hoping for some more effort from Ants to correct this.
>
> I'll commit Craig's ne
Jim Nasby writes:
> I do think it's interesting that the data appeared to be completely fine
> until I actually ran whatever the first assembly instruction of the for
> loop is, so presumably it was fine after the sigsetjmp() call (which I'm
> assuming is what causes all the fuss to begin with.
Robert Haas [mailto:robertmh...@gmail.com] wrote:
>> Where you get into trouble there is that you might run CREATE
EXTENSION
>> from that session
Yes. I can see this problem. And, while I can imagine resolving it with
context belonging to the extension, separate from the current session's
context
Ashutosh Bapat writes:
> Right. But I think it's better to use attribute id, in case the code
> raising this error changes for any reason in future.
I agree. The parent's "tdhasoid" flag is definitely based on the
existence of an ObjectIdAttributeNumber system column, not on whether the
column's
On 1/3/17 9:20 PM, Amit Kapila wrote:
On Wed, Jan 4, 2017 at 3:47 AM, Jim Nasby wrote:
On 1/2/17 9:47 PM, Tom Lane wrote:
Correct coding would be
volatile TupleDesc desc = slot->tts_tupleDescriptor;
CallbackState * volatile myState = (CallbackState *) self;
PLyTypeInfo * volatile
On Thu, Jan 5, 2017 at 10:23 AM, Robert Haas wrote:
> On Tue, Dec 27, 2016 at 9:28 PM, Thomas Munro
> wrote:
>> On Wed, Dec 28, 2016 at 11:57 AM, Thomas Munro
>> wrote:
>>> But I'm starting to think that the best way might be to do BOTH of the
>>> things I said in my previous message: make dsa.c
On 01/04/2017 03:21 PM, Dilip Kumar wrote:
On Wed, Jan 4, 2017 at 8:05 AM, Tomas Vondra
wrote:
Attached is v22 of the patch series, rebased to current master and fixing
the reported bug. I haven't made any other changes - the issues reported by
Petr are mostly minor, so I've decided to wait a b
On Thu, Jan 5, 2017 at 7:41 AM, Robert Haas wrote:
> On Wed, Jan 4, 2017 at 2:17 AM, Michael Paquier
> wrote:
>> On Wed, Jan 4, 2017 at 12:48 AM, Robert Haas wrote:
>>> On Sun, Jan 1, 2017 at 4:38 AM, Thomas Munro
>>> wrote:
To be able to do this, the patch modifies the isolation tester so
On Tue, Nov 15, 2016 at 5:31 PM, Robert Haas wrote:
> I think we should develop versions of this that (1) allocate from the
> main shared memory segment and (2) allocate from backend-private
> memory. Per my previous benchmarking results, allocating from
> backend-private memory would be a substa
0003-Define-logical-replication-protocol-and-output-plugi-v16.patch.gz
looks good now, documentation is clear now.
Another fixup patch to remove excessive includes. ;-)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Servi
On Tue, Dec 13, 2016 at 10:46 AM, Robert Haas wrote:
> On Tue, Dec 13, 2016 at 10:41 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I find this a bit unclear, because the revised text kind of jumps back
>>> and forth between the floating-point and integer formats. Perhaps
>>> something like thi
On Tue, Dec 27, 2016 at 9:28 PM, Thomas Munro
wrote:
> On Wed, Dec 28, 2016 at 11:57 AM, Thomas Munro
> wrote:
>> But I'm starting to think that the best way might be to do BOTH of the
>> things I said in my previous message: make dsa.c register on
>> create/attach and also unregister before deta
On 31 December 2016 at 08:36, Stas Kelvich wrote:
> Here is resubmission of patch to implement logical decoding of two-phase
> transactions (instead of treating them
> as usual transaction when commit) [1] I’ve slightly polished things and used
> test_decoding output plugin as client.
Sounds go
On 1/4/17 3:35 PM, Pavel Stehule wrote:
> On 1/3/17 2:16 PM, Pavel Stehule wrote:
> > patch 0001 .. trivial cleaning
> > patch 0002 .. renaming lo_* to be_lo_* -- the prefix "be" is not what I
> > expect - maybe "pg" instead. More because the be-fsstubs.h will be
> > holds only
Fabien COELHO writes:
> Indeed. Here is the rebased version, which still get through my various
> tests.
I looked through this again, and I still think that the syntactic design
of the new command is seriously misguided, leading to an ugly and
unmaintainable implementation that may well block fu
On Wed, Jan 4, 2017 at 1:49 PM, Pavel Stehule wrote:
>
>>
>> so some possible design can be:
>>
>> DECLARE
>> PRAGMA UNCACHED_PLANS;
>> BEGIN
>> SELECT ... INTO ;
>> SELECT ... INTO ;
>> END;
>>
>> This respects Ada and PL/SQL style - probably easy implementation
>>
>> Regards
>>
>> Pavel
>
On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote
wrote:
> Patches 0001 to 0006 unchanged.
Committed 0001 earlier, as mentioned in a separate email. Committed
0002 and part of 0003. But I'm skeptical that the as-patched-by-0003
logic in generate_partition_qual() makes sense. You do this:
On 4 January 2017 at 20:30, Tom Lane wrote:
> Simon Riggs writes:
>> My next thought is ALTER SYSTEM support for pg_hba.conf, especially
>> since that would make it easier to do a formal test of Haribabu's
>> pg_hba view patch by adding each of the options one by one and then
>> juggling them.
>
2017-01-04 21:09 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 1/3/17 2:16 PM, Pavel Stehule wrote:
> > patch 0001 .. trivial cleaning
> > patch 0002 .. renaming lo_* to be_lo_* -- the prefix "be" is not what I
> > expect - maybe "pg" instead. More because the be-fsstubs.h
Simon Riggs writes:
> My next thought is ALTER SYSTEM support for pg_hba.conf, especially
> since that would make it easier to do a formal test of Haribabu's
> pg_hba view patch by adding each of the options one by one and then
> juggling them.
It's quite unclear from this spec what you have in m
On Mon, Jan 2, 2017 at 10:07 PM, Kohei KaiGai wrote:
> Oops, I oversight this patch was marked as "returned with feedback",
> not "moved to the next CF".
>
> Its status has not been changed since the last update. (Code was
> revised according to the last
> comment by Jeevan, but CF-Nov was time up
On 3 January 2017 at 12:34, Michael Paquier wrote:
> On Mon, Jan 2, 2017 at 10:55 PM, Simon Riggs wrote:
>> In the hope of making things better in 10.0, I remove my objection. If
>> people want to use wal_level = minimal they can restart their server
>> and they can find that out in the release n
My next thought is ALTER SYSTEM support for pg_hba.conf, especially
since that would make it easier to do a formal test of Haribabu's
pg_hba view patch by adding each of the options one by one and then
juggling them.
ALTER SYSTEM
ENABLE [LOCAL | REMOTE] ACCESS
FOR
[DATABASE | REPLICATION ]
[USER
On 4 January 2017 at 03:54, Haribabu Kommi wrote:
> Latest patch is attached.
The "method" column should be called "auth" or "auth_method" or "authentication"
I think we should have some tests, but I'll hear your views on that.
Perhaps we can include a test/sample pg_hba.conf for use in tests.
>
> so some possible design can be:
>
> DECLARE
> PRAGMA UNCACHED_PLANS;
> BEGIN
> SELECT ... INTO ;
> SELECT ... INTO ;
> END;
>
> This respects Ada and PL/SQL style - probably easy implementation
>
> Regards
>
> Pavel
>
some examples based on Ada doc
FUNCTION xxx RETURN int AS
PRAGMA yy
On 1/4/17 9:46 AM, Magnus Hagander wrote:
> How about we default max_replication_slots to -1, which means to use the
> same value as max_wal_senders?
> But you don't necessarily want to adjust them together, do you? They are
> both capped by max_connections, but I don't think they have any
On 4 January 2017 at 13:37, Craig Ringer wrote:
>> Moved to next CF with "needs review" state.
>
> Here's an updated series. It's on top of the entry
> https://commitfest.postgresql.org/12/883/ for PostgresNode TAP test
> enhancements.
>
> It corresponds exactly to patches [2,3,4] in the logical d
2017-01-04 19:56 GMT+01:00 Fabien COELHO :
>
> [...] It is on critical path, so every check increase computer time for
>> transaction end.
>>
>
> Hmmm... Everything executed is on the critical path...
>
> It is a very good thing that GUCs are transactional, and this should not
>>> be changed, it i
[...] It is on critical path, so every check increase computer time for
transaction end.
Hmmm... Everything executed is on the critical path...
It is a very good thing that GUCs are transactional, and this should not
be changed, it is a useful feature! Much more useful than non transactional
>
>
>>
>> >>
>> >> >> *) Some user visible mechanic other than forcing SQL through EXECUTE
>> >> >> to be able to control plan caching would be useful.
>> >> >
>> >> > fully agree.
>> >> >
>> >> > Have you some ideas?
>> >> >
>> >> > What about plpgsql option (function scope) -- WITHOUT-PLAN-CACHE
On Wed, Jan 4, 2017 at 2:17 AM, Michael Paquier
wrote:
> On Wed, Jan 4, 2017 at 12:48 AM, Robert Haas wrote:
>> On Sun, Jan 1, 2017 at 4:38 AM, Thomas Munro
>> wrote:
>>> To be able to do this, the patch modifies the isolation tester so that
>>> it recognises wait_event SafeSnapshot.
>>
>> I'm n
Pavan Deolasee wrote:
> A transaction then updates the second column in the table. So the
> refactored patch will do heap_getattr() on more columns that the master
> while checking if HOT update is possible and before giving up.
Thanks.
> 1-client
> Master Refac
On Tue, Dec 27, 2016 at 8:41 PM, Amit Langote
wrote:
> On 2016/12/27 19:07, Amit Langote wrote:
>> Attached should fix that.
>
> Here are the last two patches with additional information like other
> patches. Forgot to do that yesterday.
0001 has the disadvantage that get_partition_for_tuple() a
On Mon, Dec 26, 2016 at 5:46 AM, Amit Langote
wrote:
> On 2016/12/23 8:08, Robert Haas wrote:
>> On Thu, Dec 22, 2016 at 3:35 AM, Amit Langote
>> wrote:
>>> While working on that, I discovered yet-another-bug having to do with the
>>> tuple descriptor that's used as we route a tuple down a partit
On Tue, Jan 3, 2017 at 9:33 PM, Robert Haas wrote:
>
> On Mon, Jan 2, 2017 at 1:36 AM, Amit Kapila
wrote:
> > Okay, but I think if we know how much is the additional cost in
> > average and worst case, then we can take a better call.
>
> Yeah. We shouldn't just rip out optimizations that are inc
2017-01-04 18:49 GMT+01:00 Fabien COELHO :
>
> ok understand
>>
>
> Good. So we seem to agree that GUCS are transactional?
>
> The logic depends on transactions and on nesting level (nesting doesn't
>> depends on transactions only)
>>
>
> Yep, it probably also happens with LOCAL which hides the pr
ok understand
Good. So we seem to agree that GUCS are transactional?
The logic depends on transactions and on nesting level (nesting doesn't
depends on transactions only)
Yep, it probably also happens with LOCAL which hides the previous value
and restores the initial one when exiting.
Some small patches for 0002-Add-SUBSCRIPTION-catalog-and-DDL-v16.patch.gz:
- Add a get_subscription_name() function
- Remove call for ApplyLauncherWakeupAtCommit() (rebasing error?)
- Remove some unused include files (same as before)
- Rename pg_dump --no-create-subscription-slot to
--no-create
2017-01-04 17:58 GMT+01:00 Fabien COELHO :
>
> See attached scripts for instance.
>>>
>>
>> Your test shows so SET SESSION has not transactional behaviour - the
>> transactions fails, but the value is not reverted to NULL.
>>
>
> There are *two* function calls, the first fails and the second succ
On Tue, Jan 3, 2017 at 6:45 PM, Lewis, Ian (Microstar Laboratories)
wrote:
> One idea, which would likely be harder to implement on the server, but
> that would have less impact on third party tools and libraries, would be
> to configure case folding on a session basis. There would have to be
> so
2017-01-04 17:30 GMT+01:00 Fabien COELHO :
>
>
> Now we can this feature emulate with dblink, and there are patches in
>> commitfest based on background workers, and emulation will be cheaper.
>>
>
> I had not noticed that "background session" proposal. That's definitely an
> interesting feature t
On 4 January 2017 at 08:16, Craig Ringer wrote:
> On 4 January 2017 at 12:39, Craig Ringer wrote:
>
>> To keep things together, I've followed up on the logical decoding on
>> standby thread that now incorporates all these patches.
>
> Attached are the two patches discussed upthread, in their
> pr
See attached scripts for instance.
Your test shows so SET SESSION has not transactional behaviour - the
transactions fails, but the value is not reverted to NULL.
There are *two* function calls, the first fails and the second succeeds.
Here is the trace with a some comments:
[...]
##
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/4/17 10:57 AM, Tom Lane wrote:
> > I still maintain that the existing solution for passphrases is useless,
> > but in the interest of removing objections to the current patch, I'll
> > go make that happen.
>
> Sounds good.
Agreed
On 1/4/17 10:57 AM, Tom Lane wrote:
> I still maintain that the existing solution for passphrases is useless,
> but in the interest of removing objections to the current patch, I'll
> go make that happen.
Sounds good.
Looking around briefly (e.g., Apache, nginx), the standard approach
appears to
>
>> Um, what? No, not at all.
>>
>> GUCs are scoped, but not transactional, [...]
>>
>
> The documentation is very scarse, so I have tested it.
>
> All tests I have done with commit & rollback on session variables (SET
> SESSION) have shown a clean transactional behavior, with the value reverted
>
Now we can this feature emulate with dblink, and there are patches in
commitfest based on background workers, and emulation will be cheaper.
I had not noticed that "background session" proposal. That's definitely an
interesting feature to have for some use cases. Dblink implies a new
connec
Hello,
The security-related use-case you have presented stores the status of
the verification in a variable. If the variable is untransactional,
then it has been shown that the variable status > may say ok while the
verification has really really failed.
That's only a concern if the setting
>> > SELECT UNCACHED t.a, t.b FROM INTO a,b;
>>
>> Yeah -- this is pretty ugly admittedly. Maybe control directive is
>> ok, as long as you can set it mid function?
>>
>
> ADA uses for this purpose PRAGMA keyword - it is used for everything in
> ADA - cycle iteration optimization, ...the scope can
2017-01-04 16:49 GMT+01:00 Merlin Moncure :
> On Tue, Jan 3, 2017 at 2:15 PM, Pavel Stehule
> wrote:
> >
> >
> > 2017-01-03 20:54 GMT+01:00 Merlin Moncure :
> >>
> >> On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule
> >> wrote:
> >> > 2017-01-03 16:23 GMT+01:00 Merlin Moncure :
> >> >> *) Would als
On Wed, Jan 4, 2017 at 12:02 PM, Amit Kapila wrote:
> Review comments:
> 1.
> + bool is_partial);
> +
>
> Seems additional new line is not required.
Fixed
>
> 2.
> + * try_partial_mergejoin_path
> + * Consider a partial merge join path; if it appears useful,
> push it into
> + * the joinrel's pa
Peter Eisentraut writes:
> On 1/4/17 10:26 AM, Tom Lane wrote:
>> How will you know whether there's a pass phrase?
> One could register a password callback that remembers whether it was called.
Hmm ... actually, we don't even need to work that hard. If we simply
use the callback that's there no
On 1/4/17 10:26 AM, Tom Lane wrote:
> Andreas Karlsson writes:
>> Sorry, I was very unclear. I meant refusing the reload the SSL context
>> if there is a pass phrase, but that the rest of the config will be
>> reloaded just fine. This will lead to some log spam on every SIGHUP for
>> people wit
On Tue, Jan 3, 2017 at 2:15 PM, Pavel Stehule wrote:
>
>
> 2017-01-03 20:54 GMT+01:00 Merlin Moncure :
>>
>> On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule
>> wrote:
>> > 2017-01-03 16:23 GMT+01:00 Merlin Moncure :
>> >> *) Would also like to have a FINALLY block
>> >
>> > What you can do there?
>
On Tue, Jan 3, 2017 at 1:05 PM, Peter Eisentraut
wrote:
> On 11/7/16 5:31 PM, Merlin Moncure wrote:
>> Regardless, it seems like you might be on to something, and I'm
>> inclined to patch your change, test it, and roll it out to production.
>> If it helps or at least narrows the problem down, we o
On Wed, Jan 4, 2017 at 9:47 AM, Simon Riggs wrote:
> On 4 January 2017 at 13:57, Robert Haas wrote:
>> On Wed, Jan 4, 2017 at 3:05 AM, Simon Riggs wrote:
>>> Strange response. Nothing has been assumed. I asked for tests and you
>>> provided measurements.
>>
>> Sure, of zero-filling a file with d
Andreas Karlsson writes:
> Sorry, I was very unclear. I meant refusing the reload the SSL context
> if there is a pass phrase, but that the rest of the config will be
> reloaded just fine. This will lead to some log spam on every SIGHUP for
> people with a pass phrase but should otherwise work
Stephen Frost writes:
> Indeed, this is important functionality that people are using.
Who exactly are these people, and why haven't they complained about how
crappy the support is now? I'm *completely* unconvinced by the argument
that the way it has worked in the past is an important feature th
So I'm looking at this patch in the commit fest. I have only a general
understanding of temporal query processing.
What this patch does is to add two new clauses for FROM-list items,
NORMALIZE and ALIGN, which reshuffle a set of ranges into a new list
that can then be aggregated more easily. Fro
* Andreas Karlsson (andr...@proxel.se) wrote:
> On 01/04/2017 04:14 PM, Stephen Frost wrote:
> >* Andreas Karlsson (andr...@proxel.se) wrote:
> >>A possible solution might be to only add the error throwing hook
> >>when loading certificates during SIGHUP (and at Windows) and to work
> >>as before o
On 01/04/2017 04:14 PM, Stephen Frost wrote:
* Andreas Karlsson (andr...@proxel.se) wrote:
A possible solution might be to only add the error throwing hook
when loading certificates during SIGHUP (and at Windows) and to work
as before on startup. Would that be an acceptable solution? I could
wri
* Andreas Karlsson (andr...@proxel.se) wrote:
> On 01/04/2017 03:48 PM, Magnus Hagander wrote:
> >On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane >It does not; what would be the point, if the key would be lost at
> >SIGHUP?
> >
> >If we lost it, yes. But we could keep the old key around if it has
On Wed, Jan 4, 2017 at 4:35 PM, Amit Kapila wrote:
> In this new system, I
> think we can't remove undo entries of heap page till we clear
> corresponding index entries. I think we need to somehow collect the
> old values from undo corresponding to index and then scan the index
> remove the index
On 01/04/2017 03:48 PM, Magnus Hagander wrote:
On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane
That means storing the pass phrase in the memory of the postmaster,
which does not sound like a terribly good idea to me, but I have never
used keys with pass phrases for daemons so it might be a common so
1 - 100 of 145 matches
Mail list logo
