[sent again, previously sent as reply, instead of reply-all, thanks
Robert]
On 2013-08-09 09:09:08 -0400, Robert Haas wrote:
> On Fri, Jul 26, 2013 at 8:50 AM, Robert Haas wrote:
> > On Fri, Jul 26, 2013 at 5:34 AM, Andres Freund
> > wrote:
> >> It doesn't need to be the postmaster, but I think
I think this is utterly the won't way to think about this.
TCP is designed to be robust against transient network outages. They are
*not* supposed to cause disconnections. The purpose of keepalives is to
detect connections that are still valid live connections that are stale and
the remote end is
On Sat, Aug 10, 2013 at 12:26:43PM +0100, Greg Stark wrote:
> On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane wrote:
> > Any other client would behave the same
> > if it were killed while waiting for some backend query. So the right
> > fix would involve figuring out a way for the backend to kill itsel
On Mon, Aug 5, 2013 at 12:21 PM, Tom Lane wrote:
> David Gudeman writes:
>> For those who don't want to go to the link to see what I'm talking
>> about with query rewrites, I thought I'd give a brief description.
>> Foreign data wrappers currently do all of their work in the planning
>> phase but
On Sat, Aug 10, 2013 at 10:40 PM, Tom Lane wrote:
> Alvaro Herrera writes:
> > Hmm, the intention is that this code path mimics what the autovacuum
> > launcher does to establish its connection. It did work at some point;
> > maybe I broke this before commit. I will give it a look next week.
>
On Sat, Aug 10, 2013 at 10:57:56AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Fri, Aug 09, 2013 at 06:59:13PM -0400, Tom Lane wrote:
> >> Does that ameliorate your concern, or do you still want it to be DEBUG1?
>
> > I think of the "implicit sequence" messages we moved from NOTICE to DEBU
On Thu, Aug 08, 2013 at 04:42:11AM +, Kodamasimham Pridhvi (MT2012066)
wrote:
> With reference to "Add XML Schema validation and xmlvalidate functions
> (SQL:2008)" in ToDo list, we have gone through pgsql-mailing list but we
> didn't find any significant work in this area, so we are pr
On Sat, Aug 10, 2013 at 12:30 AM, Tom Lane wrote:
> Tatsuo Ishii writes:
>> I noticed pg_dump does not exit gracefully when killed.
>> start pg_dump
>> kill pg_dump by ctrl-c
>> ps x
>
>> 27246 ?Ds96:02 postgres: t-ishii dbt3 [local] COPY
>> 29920 ?S 0:00 sshd: ishii@pts/
Noah Misch writes:
> On Fri, Aug 09, 2013 at 06:59:13PM -0400, Tom Lane wrote:
>> Also, I'm not sure that the chattiness argument is relevant, because no
>> message will be emitted at all unless you're switching to some log target
>> different from the postmaster's initial stderr. So the message
Alvaro Herrera writes:
> Andrew Tipton wrote:
>> However, should one attempt to pass NULL for the dbname parameter, the
>> process will die with:
>> FATAL: database 0 does not exist
> Hmm, the intention is that this code path mimics what the autovacuum
> launcher does to establish its connection.
Andrew Tipton writes:
> The documentation for 9.4 says, in the "Background Worker Processes"
> section:
> Once running, the process can connect to a database by calling
> BackgroundWorkerInitializeConnection(char *dbname, char *username). This
> allows the process to run transactions and queries u
Andrew Tipton wrote:
> However, should one attempt to pass NULL for the dbname parameter, the
> process will die with:
>
> FATAL: database 0 does not exist
>
> BackgroundWorkerInitializeConnection() is essentially just a wrapper around
> InitPostgres(), passing it the supplied dbname and usernam
Pavel Stehule writes:
> I found so there are no simple API for working with LO from PL without
> access to file system.
What? See lo_open(), loread(), lowrite(), etc.
> These functions can be simplified if we supports some functions like
> encode, decode for LO
I do not see any good reason to
The documentation for 9.4 says, in the "Background Worker Processes"
section:
Once running, the process can connect to a database by calling
BackgroundWorkerInitializeConnection(char *dbname, char *username). This
allows the process to run transactions and queries using the SPI interface.
If dbnam
> On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane wrote:
>> Any other client would behave the same
>> if it were killed while waiting for some backend query. So the right
>> fix would involve figuring out a way for the backend to kill itself
>> if the client connection goes away while it's waiting.
I
On Sat, Aug 10, 2013 at 5:30 AM, Tom Lane wrote:
> Any other client would behave the same
> if it were killed while waiting for some backend query. So the right
> fix would involve figuring out a way for the backend to kill itself
> if the client connection goes away while it's waiting.
Well I'm
16 matches
Mail list logo
