Hello, Kimura-san.
At Thu, 07 Nov 2019 17:04:51 +0900, btkimurayuzk
wrote in
> > btkimurayuzk writes:
> >> I propose new simple sql query, which shows total block numbers in the
> >> relation.
> >> ...
> >> Of cource, we can know this value such as
> >> select (pg_relation_size('t') /
> >>
On 2019-11-06 15:49, Tom Lane wrote:
Peter Eisentraut writes:
On 2019-11-04 16:01, Tom Lane wrote:
Now that I've actually looked at the patched code, there's a far
more severe problem with it. Namely, that use of PG_FINALLY
means that the "finally" segment is run without having popped
the
+ VACOPT_RESUME = 1 << 8/* resume from the previous point */
I think this unused ENUM value is not needed.
Regards,
Yu Kimura
On Mon, Nov 4, 2019 at 11:13 AM Julien Rouhaud wrote:
>
> On Mon, Nov 4, 2019 at 4:58 AM Thomas Munro wrote:
> >
> > Unfortunately I haven't had time to work on it seriously, but here's a
> > quick rebase to get the proof-of-concept back into working shape.
Thanks! I also removed the test for
> I looked in the CREATE TRIGGER manual page and found this:
> https://www.postgresql.org/docs/12/sql-createtrigger.html
> If the trigger fires before or instead of the event, the trigger
> can skip the operation for the current row, or change the row
> being
On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote:
At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin
wrote in
On 11/6/19 1:55 PM, Grigory Smolkin wrote:
On 11/6/19 12:56 PM, Fujii Masao wrote:
On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin
wrote:
On 11/6/19 10:39 AM, Peter Eisentraut wrote:
> 2019年11月7日 上午12:08，Konstantin Knizhnik 写道：
>
>
>
> On 06.11.2019 16:24, 曾文旌(义从) wrote:
>> Dear Hackers
>>
>>
>> I attached the patch of GTT implementationI base on PG12.
>> The GTT design came from my first email.
>> Some limitations in patch will be eliminated in later versions.
>>
>>
2019-11-06 11:31 に Fujii Masao さんは書きました:
On Wed, Nov 6, 2019 at 6:23 AM Fabien COELHO
wrote:
Hello,
>>> - for (step = initialize_steps; *step != '\0'; step++)
>>> + for (const char *step = initialize_steps; *step != '\0'; step++)
>
> But I still wonder why we should apply such change here.
On Wed, Sep 25, 2019 at 10:24:05PM -0700, Ashwin Agrawal wrote:
> Thanks for reporting, I did indeed missed out contrib. Please find attached
> the v2 of the patch which includes the change required in contrib as well.
Okay, that makes sense. The patch looks good to me so I have switched
it to
Hi Kyotaro,
Le 07/11/2019 à 08:10, Kyotaro Horiguchi a écrit :
> Hello.
>
> At Wed, 6 Nov 2019 20:13:10 +0900, Etsuro Fujita
> wrote in
>> Hi Michael-san,
>>
>> On Wed, Nov 6, 2019 at 4:35 PM Michael Paquier wrote:
>>> On Wed, Nov 06, 2019 at 03:12:04PM +0900, Etsuro Fujita wrote:
On
Hello, Fujita-san.
At Thu, 7 Nov 2019 17:20:07 +0900, Etsuro Fujita
wrote in
> Only two people complaining about the wording? Considering as well
> that we use that wording in the docs and there were no complains about
> that IIRC, I don't feel a need to change that, TBH.
>
> > And perhaps
Hi Amit,
I am reading about this feature and reviewing it.
To start with, I reviewed the patch:
0005-Doc-changes-describing-details-about-logical-decodin.patch.
>prevent VACUUM from removing required rows from the system catalogs,
>hot_standby_feedback should be set on the standby. In spite of
At Thu, 07 Nov 2019 17:27:47 +0900 (JST), Kyotaro Horiguchi
wrote in
> "modified" is my mistake as in the just posted mail. But the most
> significant point in the previous mail is using "foreign tables using
> postgres_fdw" instead of "postgres_fdw foreign tables". And the other
> point is
Hello Eugen,
Thursday, November 7, 2019, 11:20:32 AM, you wrote:
>> I looked in the CREATE TRIGGER manual page and found this:
>> https://www.postgresql.org/docs/12/sql-createtrigger.html
>> If the trigger fires before or instead of the event, the trigger
>> can skip the
btkimurayuzk writes:
I propose new simple sql query, which shows total block numbers in the
relation.
...
Of cource, we can know this value such as
select (pg_relation_size('t') /
current_setting('block_size')::bigint)::int;
I don't really see why the existing solution isn't sufficient.
I
Horiguchi-san,
On Thu, Nov 7, 2019 at 4:11 PM Kyotaro Horiguchi
wrote:
> At Wed, 6 Nov 2019 20:13:10 +0900, Etsuro Fujita
> wrote in
> > On Wed, Nov 6, 2019 at 4:35 PM Michael Paquier wrote:
> > > On Wed, Nov 06, 2019 at 03:12:04PM +0900, Etsuro Fujita wrote:
> > > > On Wed, Nov 6, 2019 at
Hello Gilles. I made a silly mistake.
At Thu, 7 Nov 2019 09:05:55 +0100, Gilles Darold wrote in
> > FWIW, I see it a bit weird, too. And perhaps "prepare" should be in
> > upper case letters. Plus, any operation including a SELECT on a
> > temporary table inhibits PREAPRE TRANSACTION, but the
On Mon, Nov 4, 2019 at 9:59 PM Thomas Munro wrote:
>
> On Tue, Nov 5, 2019 at 4:18 AM Julien Rouhaud wrote:
> > On Mon, Nov 4, 2019 at 11:13 AM Julien Rouhaud wrote:
> > > On Mon, Nov 4, 2019 at 4:58 AM Thomas Munro
> > > wrote:
> > > > Here are some problems to think about:
> > > >
> > > > *
On Tue, Nov 05, 2019 at 08:50:54PM +0500, Ibrar Ahmed wrote:
> On Tue, Nov 5, 2019 at 7:18 AM Michael Paquier wrote:
>> That may have been me. I can take this one if there is nobody else
>> around.
Okay, so it is. I have begun browsing the patch history, and we have
a lt of work ahead.
>
I think that it may break --no-vacuum, and I thought that there may be
other option which remove things, eventually. Also, having a NO-OP looks
ok to me.
As far as I read the code, checkInitSteps() checks the initialization
steps that users specified. The initialization steps string that
"v"
Hello Horiguchi-san,
On Thu, Nov 7, 2019 at 3:10 PM Kyotaro Horiguchi
wrote:
> Mmm? See the bit in the patch cited below (v5).
>
> + /* Range check */
> + if (unlikely(!FLOAT8_FITS_IN_INT32(num)) || isnan(num))
>
> If compiler doesn't any fancy, num is fed to an arithmetic before
>
Hi,
On 2019-11-05 22:00:58 -0500, Chapman Flack wrote:
> On 11/05/19 18:54, Andres Freund wrote:
> > Hi,
> >
> > There's a few errors that we issue that are, often, much less bad than
> > they sound. The most common cases I immediately can recall are:
> >
> >
> > 1) Mentioning crash, once for
Hi,
On 2019-11-06 17:36:09 +0900, Kyotaro Horiguchi wrote:
> At Tue, 5 Nov 2019 15:54:22 -0800, Andres Freund wrote
> in
> > Hi,
> >
> > There's a few errors that we issue that are, often, much less bad than
> > they sound. The most common cases I immediately can recall are:
> >
> >
> > 1)
On Thu, Nov 07, 2019 at 11:50:25AM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> Good question. That's a historical choice, still I have seen cases
>> where those warnings are helpful while not making the logs too
>> verbose to see some congestion in the jobs.
>
> I kind of feel that
On Tue, Sep 03, 2019 at 10:00:08AM +0900, Fujii Masao wrote:
> Sorry for the long delay... Yes, I will update the patch if necessary.
Fujii-san, are you planning to update this patch then? I have
switched it as waiting on author.
--
Michael
signature.asc
Description: PGP signature
On Thu, Nov 7, 2019 at 10:20 PM Julien Rouhaud wrote:
> Attached 4th patch handles default collation. I went with an
> ignore_systempin flag in recordMultipleDependencies.
Thanks for working on this! I haven't looked closely or tested yet,
but this seems reasonable. Obviously it assumes that
Hello hackers,
Here's a draft patch that teaches PostgreSQL how to ask for collation
versions on Windows. It receives a pair of DWORDs, which, it displays
as hex. The values probably have an internal structure that is
displayed in a user-friendly way by software like Active Directory and
SQL
On Thu, Nov 07, 2019 at 09:25:40AM -0800, Andres Freund wrote:
> Let me take a look this afternoon. Swapped out of my brain right now
> unfortunately.
Thanks for the update.
--
Michael
signature.asc
Description: PGP signature
On Mon, Sep 30, 2019 at 11:38:05AM -0300, Alvaro Herrera wrote:
> On 2019-Sep-30, Joe Conway wrote:
>
> > I am not sure I will get to this today. I assume it is ok for me to move
> > it forward e.g. next weekend, or is that not in line with commitfest rules?
>
> You can commit whatever patch
On Fri, Nov 8, 2019 at 2:37 PM Michael Paquier wrote:
> On Fri, Nov 08, 2019 at 02:23:54PM +1300, Thomas Munro wrote:
> > Right, so this is basically a policy decision: do we assume that all
> > pre-13 indexes that depend on collations are potentially corrupted, or
> > assume that they are not?
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> >> Peter Eisentraut writes:
> >>> Using GUCs to control some of this creates yet another place where
> >>> permission information is kept, and with it questions about how to get
> >>> to it, how to edit it, or to back
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>>> Two things- first, this doesn't actually cover everything that the
>>> proposed GUCs do- specifically, the proposed GUCs give you a way to
>>> limit what specific extensions are allowed to be installed,
Hackers,
As discussed with Tom in [1] and again with Pavel and Alvaro in [2],
here is a partial WIP refactoring of the SPI interface. The goal is to
remove as many of the SPI_ERROR_xxx codes as possible from the
interface, replacing them with elog(ERROR), without removing the ability
of
On Thu, Nov 07, 2019 at 06:40:36PM +0900, Etsuro Fujita wrote:
> On Thu, Nov 7, 2019 at 5:28 PM Kyotaro Horiguchi
> wrote:
>> At Thu, 7 Nov 2019 17:20:07 +0900, Etsuro Fujita
>> wrote in
>>> Only two people complaining about the wording? Considering as well
That's like.. Half the folks
On Fri, Nov 8, 2019 at 9:41 AM Michael Paquier wrote:
>
> On Tue, Sep 03, 2019 at 10:00:08AM +0900, Fujii Masao wrote:
> > Sorry for the long delay... Yes, I will update the patch if necessary.
>
> Fujii-san, are you planning to update this patch then? I have
> switched it as waiting on author.
101 - 135 of 135 matches
Mail list logo
