Re: [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility
От | Simon Riggs |
---|---|
Тема | Re: [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility |
Дата | |
Msg-id | CA+U5nMJujvmB1cMU7pFOuAeHZXE5xqXc5r22tQk8DJy3QXNDhQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: [RFC] CREATE QUEUE (log-only table) for londiste/pgQ
ccompatibility
|
Список | pgsql-hackers |
On 17 October 2012 21:25, Josh Berkus <josh@agliodbs.com> wrote: > >> It is not meant to be a full implementation of application level queuing >> system though but just the capture, persisting and distribution parts >> >> Using this as an "application level queue" needs a set of interface >> functions to extract the events and also to keep track of the processed >> events. As there is no general consensus what these shoul be (like if >> processing same event twice is allowed) this part is left for specific >> queue consumer implementations. > > Well, but AFAICT, you've already prohibited features through your design > which are essential to application-level queues, and are implemented by, > for example, pgQ. > > 1. your design only allows the queue to be read on replicas, not on the > node where the item was inserted. > > 2. if you can't UPDATE or DELETE queue items -- or LOCK them -- how on > earth would a client know which items they have executed and which they > haven't? > > 3. Double-down on #2 in a multithreaded environment. It's hard to work out how to reply to this because its just so off base. I don't agree with the restrictions you think you see at all, saying it politely rather than giving a one word answer. The problem here is you phrase these things with too much certainty, seeing only barriers. The "how on earth?" vibe is not appropriate at all. It's perfectly fine to ask for answers to those difficult questions, but don't presume that there are no answers, or that you know with certainty they are even hard ones. By phrasing things in such a closed way the only way forwards is through you, which does not help. All we're discussing is moving a successful piece of software into core, which has been discussed for years at the international technical meetings we've both been present at. I think an open viewpoint on the feasibility of that would be reasonable, especially when it comes from one of the original designers. I apologise for making a personal comment, but this does affect the technical discussion. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: