On Fri, Sep 14, 2018 at 4:17 PM, Tom Lane wrote:
> There's been quite a lot of input, from quite a lot of people, dating
> back at least as far as a well-attended session at PGCon 2016. I find
> it quite upsetting to hear accusations that core is imposing this out
> of nowhere. From my
Hi,
On 2018-09-22 15:27:24 +0900, Michael Paquier wrote:
> On Fri, Sep 21, 2018 at 06:26:19AM +, Tsunakawa, Takayuki wrote:
> > Agreed.
>
> Okay, I have pushed the patch with all your suggestions included.
Have there been discussions about the security effects of this change?
Previously the
On Fri, Sep 21, 2018 at 06:35:02PM -0400, Bruce Momjian wrote:
> Does the SQL standard have anything to say about CURRENT_TIMESTAMP in
> procedures? Do we need another function that does advance on procedure
> commit?
I found a section in the SQL standards that talks about it, but I don't
On Sat, Sep 22, 2018 at 12:46:31PM -0400, Andrew Dunstan wrote:
> Meanwhile, it would be good for people to think about creating a TAP testing
> regime for this.
Patch 0001 from this email, or something rather similar to that, could
be used:
I wrote:
> I'm strongly tempted to just remove the POLL_UNWANTED business
> altogether, as it seems both pointless and unportable on its face.
> Almost by definition, we can't know what "other" bits a given
> implementation might set.
> I'm not entirely following the point of including POLLRDHUP
On 09/20/18 00:44, Tom Lane wrote:
> Chapman Flack writes:
>> Would it be unprecedented / be unreasonable / break anything for the
>> install_jar function to simply force a CommandCounterIncrement
>> at the end of step 1 (after its temporary snapshot has been popped,
>> so the former/on-entry
> "Krasiyan" == Krasiyan Andreev writes:
Krasiyan> Hi,
Krasiyan> Patch applies and compiles, all included tests and building
Krasiyan> of the docs pass. I am using last version from more than two
Krasiyan> months ago in production environment with real data and I
Krasiyan> didn't find
Hi.
In my case. I tested with ibm power 8 and 9 computers. And it did not go
very well (Support teams Mexico / Spain / United States), tried to optimize
without giving more performance.
I have intel computers and what I see is that you have 2 core and if you do
not see badly you have a bit of
Honorable Concern,
I want to join GCI as a mentor, please guide me about the procedure, thanks
in anticipation.
--
Regards
Tahir Ramzan
MSCS Research Scholar
Google Summer of Code 2015 (CiviCRM)
Google Summer of Code 2016 (ModSecurity)
Outside Collaborator of SpiderLabs (Powered by TrustWave)
On Thu, Sep 20, 2018 at 3:52 PM Alexander Korotkov
wrote:
>
> On Thu, Sep 20, 2018 at 6:09 AM amul sul wrote:
> > Agreed, thanks for working on this.
>
> Pushed, thanks.
Please, find attached patch improving documentation about
letters/digits in to_date()/to_timestamp() template string. I
In the interest of advancing $subject, I recently started a little
skunkworks project to get old postgres running on modern systems so we
could test if we'd broken backwards compatibility somehow. This was
given a fillip a few days ago when my colleague Gianni Ciolli complained
that it uses
Fabien COELHO writes:
> The patch was not applying cleanly anymore for me, so here is a rebase of
> your latest version.
The cfbot doesn't like that patch, probably because of the Windows newlines.
Here's a version with regular newlines, and some cosmetic cleanup in the
configure
On Sat, Sep 22, 2018 at 9:55 AM Amit Kapila wrote:
> On Fri, Sep 21, 2018 at 11:06 PM Alexander Korotkov
> wrote:
> > While investigating ProcArrayGroupClearXid() code I wonder why do we
> have this loop instead of plain pg_atomic_exchange_u32() call?
>
> We can use pg_atomic_exchange_u32
On Mon, Jul 9, 2018 at 11:28 AM Haribabu Kommi wrote:
>
> On Mon, Jul 9, 2018 at 3:39 PM Haribabu Kommi
> wrote:
>>
>>
>> On Mon, Jul 9, 2018 at 12:24 PM Michael Paquier wrote:
>>>
>>> On Fri, Jul 06, 2018 at 05:10:18PM -0400, Alvaro Herrera wrote:
>>> > Ugh, it's true :-(
>>> >
On Mon, Sep 10, 2018 at 3:54 PM Tatsuo Ishii wrote:
>
> >> Hello Bradley & Tatsuo-san,
> >>
> ... references to the protocol version lacks homogeneity.
> ... I'd suggest to keep "the vX.0 protocol" for a short version,
> and "the version X.0 protocol" for long ...
> >>>
> >>> I
so 22. 9. 2018 v 8:48 odesÃlatel Hubert Zhang napsal:
> But it looks like redundant to current GUC configuration and limits
>
> what do you mean by current GUC configuration? Is that the general block
> number limit in your patch? If yes, the difference between GUC and
> pg_diskquota catalog is
On Fri, Sep 21, 2018 at 11:06 PM Alexander Korotkov
wrote:
>
> Hi!
>
> While investigating ProcArrayGroupClearXid() code I wonder why do we have
> this loop instead of plain pg_atomic_exchange_u32() call?
>
We can use pg_atomic_exchange_u32 instead of a loop. In fact, clog
code uses
Hi all,
Here are some rebased versions of the last two patches. No changes in
functionality, except a minor case sensitivity fix in the "completion
after commas" patch.
Edmund
01-psql-select-tab-completion-v8.patch
Description: Binary data
02-select-completion-after-commas.patch
>
> But it looks like redundant to current GUC configuration and limits
what do you mean by current GUC configuration? Is that the general block
number limit in your patch? If yes, the difference between GUC and
pg_diskquota catalog is that pg_diskquota will store different quota limit
for the
On Fri, Sep 21, 2018 at 06:26:19AM +, Tsunakawa, Takayuki wrote:
> Agreed.
Okay, I have pushed the patch with all your suggestions included.
--
Michael
signature.asc
Description: PGP signature
Hi
rebased against yesterday changes in tab-complete.c
Regards
Pavel
schema-variables-20180922-01.patch.gz
Description: application/gzip
21 matches
Mail list logo
