> We need some kind of concrete plan for what is a
> usable amount of functionality and what has to be done to get it.
>
This is exactly the type of discussion I'm after.
I'll start.
A usable amount of functionality would be the ability to start threads from:
- a background worker
These cas
>
> I see no good reason to believe that the signal handler issue is the only
> one. Even if it is,
> not being able to call any postgres infrastructure is a pretty huge
> handicap.
>
(changed emails to get rid of the nasty employer notice...)
It's at least a workable handicap that I'm happy to
Is $subject possible?
I feel like maybe the answer is no, but then I can also see some backend
code for similar things in copy.h.
Perhaps it’s possible via a function call not sending the SQL?
- James
>
> No. It'd be a wire protocol break, and even if it weren't I would not
> expect many clients to be able to deal with it. They're in the middle
> of a query cycle (for the SELECT or CALL that got you into SPI), and
> suddenly the backend asks for COPY data? What are they supposed to
> send, or
Hello Hackers!
Is it possible to get the current virtual txid from C somehow?
I've looked through the code, but can't seem to find anything other than
getting a NULL when there is no (real) xid assigned. Maybe I'm missing
something?
Cheers,
James
On Thu, 12 Jan 2017 at 12:06, Michael Paquier
wrote:
> On Thu, Jan 12, 2017 at 9:53 AM, James Sewell
> wrote:
> > What is needed to support this is the ability to configure Px with
> something like:
> >
> > 1 (P1, P2, P3), 1 (D1, D2, D3)
> >
> > Would th
Hi hackers,
I was talking about PostgreSQL and threading on IRC the other day - which I
know is a frowned upon topic - and just wanted to frame the same questions
here and hopefully get a discussion going.
On IRC RhodiumToad offered the following advice (after a standard there be
dragons here dis
On Tue, 23 Jun 2020 at 13:38, Tom Lane wrote:
> James Sewell writes:
> > I was talking about PostgreSQL and threading on IRC the other day -
> which I
> > know is a frowned upon topic - and just wanted to frame the same
> questions
> > here and hopefully get a discus
> Using multithreading in bgworker is possible if you do not use any
> Postgres runtime inside thread procedures or do it in exclusive critical
> section.
> It is not so convenient but possible. The most difficult thing from my
> point of view is error reporting.
>
Happy to be proved wrong, but I
On Tue, 23 Jun 2020 at 17:15, James Sewell
wrote:
> Using multithreading in bgworker is possible if you do not use any
>> Postgres runtime inside thread procedures or do it in exclusive critical
>> section.
>> It is not so convenient but possible. The most difficult thin
On Tue, 23 Jun 2020 at 17:26, Konstantin Knizhnik
wrote:
> On 23.06.2020 10:15, James Sewell wrote:
>
> Using multithreading in bgworker is possible if you do not use any
>> Postgres runtime inside thread procedures or do it in exclusive critical
>> section.
>>
Hackers,
In the hope of this not being derailed by larger/more unpopular pieces of
work, I'm attaching a tiny patch which I don't believe will have any
negative impact - but will remove one blocker for $subject (sigprocmask
usage is "unspecified" in multithreaded code [1]).
The patch replaces *si
ow I can map that to a PID - any thoughts?
Cheers,
James Sewell,
Suite 112, Jones Bay Wharf, 26-32 Pirrama Road, Pyrmont NSW 2009
*P *(+61) 2 8099 9000 <(+61)%202%208099%209000> *W* www.jirotech.com *F *
(+61) 2 8099 9099 <(+61)%202%208099%209000>
--
The contents of this email
ay I could find to currently solve
the problem.
Cheers,
James Sewell,
Suite 112, Jones Bay Wharf, 26-32 Pirrama Road, Pyrmont NSW 2009
*P *(+61) 2 8099 9000 <(+61)%202%208099%209000> *W* www.jirotech.com *F *
(+61) 2 8099 9099 <(+61)%202%208099%209000>
On Thu, 14 Feb 2019 at
> Yeah, possibly. I think that it could be tricky though to get that at
>> a global level in a cheap way. It makes also little sense to only
>> show the temp namespace OID if that information is not enough.
>>
>
> We could I guess add a field specifically for temp_namespace_xid or such.
> The que
On Mon, 18 Feb 2019 at 12:31, Michael Paquier wrote:
> On Sun, Feb 17, 2019 at 05:47:09PM +0100, Magnus Hagander wrote:
> > We could I guess add a field specifically for temp_namespace_xid or such.
> > The question is if it's worth the overhead to do that.
>
> That would mean an extra 4 bytes in
Hi all,
This is great stuff! My understanding is that this patch guarantees 0 data
loss for a logical replication stream if the primary crashes and a standby
which was marked as sync at failure time is promoted.
Is this correct?
James
--
James Sewell,
Chief Architect
Suite 112, Jones Bay
Exciting stuff! Really looking forward to having a play with this.
James Sewell,
*Chief Architect*
Suite 112, Jones Bay Wharf, 26-32 Pirrama Road, Pyrmont NSW 2009
*P *(+61) 2 8099 9000 <(+61)%202%208099%209000> *W* www.jirotech.com *F *
(+61) 2 8099 9099 <(+61)%202%208099%209000>
18 matches
Mail list logo
