On Mon, Dec 2, 2019 at 2:01 PM Dilip Kumar wrote:
>
> On Sun, Dec 1, 2019 at 7:58 AM Michael Paquier wrote:
> >
> > On Fri, Nov 22, 2019 at 01:18:11PM +0530, Dilip Kumar wrote:
> > > I have rebased the patch on the latest head and also fix the issue of
> > > "concurrent abort handling of the (sub
A small add-on to the generated columns feature: Add an ALTER TABLE
subcommand for dropping the generated property from a column, per SQL
standard.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 8aa4710e1f
On Fri, Dec 6, 2019 at 12:05 PM Rushabh Lathia
wrote:
>
>
> On Fri, Dec 6, 2019 at 1:44 AM Robert Haas wrote:
>
>> On Thu, Dec 5, 2019 at 11:22 AM Rushabh Lathia
>> wrote:
>> > Here is the whole stack of patches.
>>
>> I committed 0001, as that's just refactoring and I think (hope) it's
>> unco
On 12/8/19 8:50 PM, Mark Dilger wrote:
On 12/8/19 10:25 AM, Mark Dilger wrote:
I was
still expecting multiple patches, perhaps named along the
lines of:
unshadow.RedoRecPtr.patch.1
unshadow.wal_segment_size.patch.1
unshadow.synchronous_commit.patch.1
unshadow.wrconn.patch.1
On 12/8/19 10:25 AM, Mark Dilger wrote:
I was
still expecting multiple patches, perhaps named along the
lines of:
unshadow.RedoRecPtr.patch.1
unshadow.wal_segment_size.patch.1
unshadow.synchronous_commit.patch.1
unshadow.wrconn.patch.1
unshadow.progname.patch.1
unshadow.am_sy
On Sun, Dec 8, 2019 at 4:32 PM Amit Kapila wrote:
>
> On Sun, Dec 8, 2019 at 1:10 PM Hadi Moshayedi wrote:
> >
> > It seems that explanation for the contents of the pid file has moved to
> > pidfile.h, but the comments in CreateLockFile() still point to miscadmin.h.
> >
> > The attached patch up
Hello.
At Mon, 9 Dec 2019 01:30:33 +, Ranier Vilela wrote
in
> >I don't think I'm actually on board with the goal here.
> Ok, I understand.
>
> >Basically, if we take this seriously, we're throwing away the notion of
> >nested variable scopes and programming as if we had just a flat namesp
On Fri, Dec 06, 2019 at 06:18:48PM +0300, Nikolay Shaplov wrote:
> In the thread
> https://www.postgresql.org/message-id/2620882.s52SJui4ql@x200m
> I've suggested to split one big StdRdOption that is used for options storage
> into into Options structures individual for each relkind and each rela
On Fri, Dec 06, 2019 at 06:03:12PM +0900, Amit Langote wrote:
> On Wed, Dec 4, 2019 at 5:03 PM Michael Paquier wrote:
>> I see. That saved me some time, thanks. It is not really intuitive
>> to name routines about tuple conversion from tupconvert.c to
>> attrmap.c, so I'd think about renaming th
Thanks Konstantin,
Your suggestions are very helpful. I have added them into issues of
vectorize_engine repo
https://github.com/zhangh43/vectorize_engine/issues
On Wed, Dec 4, 2019 at 10:08 PM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
>
> On 04.12.2019 12:13, Hubert Zhang wrote:
>
Hi Pavel,
Thanks for your changes. More inline below:
On Sun, 8 Dec 2019 08:38:38 +0100
Pavel Stehule wrote:
> ne 8. 12. 2019 v 2:23 odesílatel Karl O. Pinc napsal:
> > On Mon, 11 Nov 2019 15:47:37 +0100
> > Pavel Stehule wrote:
> > > I implemented two functions - first minscale, second tr
On Sun, 08 Dec 2019 13:57:00 -0500
Tom Lane wrote:
> "Karl O. Pinc" writes:
> > FWIW, I bumped around the Internet and looked at Oracle docs to see
> > if there's any reason why minscale() might not be a good function
> > name. I couldn't find any problems.
>
> > I also couldn't think of a be
On Sat, 7 Dec 2019 at 07:21, Tom Lane wrote:
> Andrew Dunstan writes:
> > I've just been looking at that. load_external_function() doesn't
> > actually do anything V1-ish with the value, it just looks up the symbol
> > using dlsym and returns it cast to a PGFunction. Is there any reason I
> > ca
>I don't think I'm actually on board with the goal here.
Ok, I understand.
>Basically, if we take this seriously, we're throwing away the notion of
>nested variable scopes and programming as if we had just a flat namespace.
>That wasn't any fun when we had to do it back in assembly-code days, and
>I think it would be better to split this patch into separate files,
>one for each global variable that is being shadowed.
Ok, I agree.
> The reasonI say so is apparent looking at the first one in the patch,
>RedoRecPtr. This process global variable is defined in xlog.c:
> static XLogRecPtr Re
Hackers,
I'm thinking of submitting a patch, and would like to review my
design ideas with you all before doing so. I've thought about
this problem before, but I can't find any email where I might
have already proposed this. If I did, and this is a duplicate,
please forgive me. I'm not trying
On Wed, Nov 20, 2019 at 1:14 AM Juan José Santamaría Flecha
wrote:
> On Tue, Nov 19, 2019 at 12:49 PM Thomas Munro wrote:
>> On Wed, Nov 20, 2019 at 12:28 AM Amit Khandekar
>> wrote:
>> > On Windows, it is documented that ReadFile() (which is called by
>> > pg_pread) will return false on EOF bu
Buildfarm member hyrax has been intermittently failing the
deadlock-parallel isolation test ever since that went in.
I finally got around to looking at this closely, and what
seems to be happening is simply that isolationtester.c's
hard-wired three-minute timeout for the completion of any
one test
Hi folks,I’ve updated the patch, addressed the rescan issue, and restructured the tests.I’ve taken a slightly different approach this time, re-using the (already pipeline-supporting) machinery of the Materialize node, and extended it to allow an SFRM_Materialize SRF to donate the tuplestore it retu
Mark Dilger writes:
> I think it would be better to split this patch into separate files,
> one for each global variable that is being shadowed. The reason
> I say so is apparent looking at the first one in the patch,
> RedoRecPtr. This process global variable is defined in xlog.c:
>static X
"Karl O. Pinc" writes:
> FWIW, I bumped around the Internet and looked at Oracle docs to see if
> there's any reason why minscale() might not be a good function name.
> I couldn't find any problems.
> I also couldn't think of a better name than trim_scale() and don't
> have any problems with the
Ranier Vilela writes:
> This is the first part of the variable shadow fixes.
> Basically it consists of renaming the variables in collision with the global
> ones, with the minimum change in the semantics.
I don't think I'm actually on board with the goal here.
Basically, if we take this seriou
On 12/7/19 3:42 PM, Ranier Vilela wrote:
This is the first part of the variable shadow fixes.
Basically it consists of renaming the variables in collision with the global
ones, with the minimum change in the semantics.
make check pass all the tests.
I think it would be better to split this
Is there a way to force a meaningful parallel seq scan, or at least the
planning of one, when the planner wants a non-parallel one?
Usually I can do things like with with enable_* setting, but if I `set
enable_seqscan to off`, it penalizes the parallel seq scan 8 times harder
than it penalizes the
I reviewed your latest code, and it's nearly complete. mdimmedsync() syncs
only "active segments" (as defined in md.c), but smgrDoPendingSyncs() must
sync active and inactive segments. This matters when mdtruncate() truncated
the relation after the last checkpoint, causing active segments to beco
I wrote:
> So, just idly looking at the code in src/backend/port/win32/signal.c
> and src/port/kill.c, I have to wonder why we have this baroque-looking
> design of using *two* signal management threads. And, if I'm
> reading it right, we create an entire new pipe object and an entire
> new instan
I wrote:
> Amit Kapila writes:
>> IIUC, once the dispatch thread has queued the signal
>> (pg_queue_signal), the next CHECK_FOR_INTERRUPTS by the main thread
>> will execute the signal. So, if we move pg_queue_signal() before we
>> do WriteFile in pg_signal_dispatch_thread(), this race condition
Amit Kapila writes:
> IIUC, once the dispatch thread has queued the signal
> (pg_queue_signal), the next CHECK_FOR_INTERRUPTS by the main thread
> will execute the signal. So, if we move pg_queue_signal() before we
> do WriteFile in pg_signal_dispatch_thread(), this race condition will
> be close
On Sun, Dec 8, 2019 at 1:10 PM Hadi Moshayedi wrote:
>
> It seems that explanation for the contents of the pid file has moved to
> pidfile.h, but the comments in CreateLockFile() still point to miscadmin.h.
>
> The attached patch updates those pointers.
>
Your patch looks correct to me on a quic
On Sun, Dec 8, 2019 at 10:44 AM Amit Kapila wrote:
>
> On Sun, Dec 8, 2019 at 1:26 AM Tom Lane wrote:
> >
> > So, just idly looking at the code in src/backend/port/win32/signal.c
> > and src/port/kill.c, I have to wonder why we have this baroque-looking
> > design of using *two* signal management
30 matches
Mail list logo
