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 t
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 agre
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 :-(
>>> > https://git.pos
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 instea
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 infrastructure.
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
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 think
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 ram
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)
Go
> "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 a
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 Acti
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 in
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:
https://www.postgresql.org/message-id/20180126080026.gi1
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
underst
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 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 perspecti
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 t
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 agre
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 :-(
>>> > https://git.pos
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 instea
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 infrastructure.
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
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 think
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 ram
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)
Go
> "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 a
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 Acti
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 in
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:
https://www.postgresql.org/message-id/20180126080026.gi1
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
underst
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 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 perspecti
32 matches
Mail list logo
