Currently PG win32 port mainly does the following to simulate signals:
(*) the process who kill the signal:
- put the signal in a named pipe, then it is done;
(*) the process who should receive the signal:
- a non-stop thread "pg_signal_thread" will read the signal from the pipe,
and start anot
Folks,
Josh Narins asked me to post this as he was unable to post it himself.
http://narins.net:4321/blog/subcountry.html
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
---(end of broadc
Bruce Momjian writes:
> Andrew - Supernews wrote:
>> What's _not_ a good idea is ignoring the EPIPE error from write(), which
>> seems to currently be reported via ereport(COMMERROR) which doesn't try
>> and abort the query as far as I can tell.
> Where are you seeing this? I looked from Postgre
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Plan B is for WAL replay to always be willing to extend the file to
>> whatever record number is mentioned in the log, even though this
>> may require inventing the contents of empty pages; we trust that their
>> contents won't matter because t
Plan B is for WAL replay to always be willing to extend the file to
whatever record number is mentioned in the log, even though this
may require inventing the contents of empty pages; we trust that their
contents won't matter because they'll be truncated again later in the
replay sequence. This s
Vikram Kalsi <[EMAIL PROTECTED]> writes:
> So, I suppose that during the query planning and optimization stage,
> the value of the original variables in the plan are somehow copied to
> the plan which is finally returned inside pg_plan_query().
Look in createplan.c --- there are a couple places in
Andrew - Supernews wrote:
> On 2005-05-01, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > The problem, as I understand it, is that if you have a long-running
> > query and the client process disappears, the query keeps running and
> > holds whatever resources it may have until it finishes. In f
On 5/25/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Jaime Casanova <[EMAIL PROTECTED]> writes:
> > I have added a function in sources and added appropiate lines in
> pg_proc.h
> > DATA(insert OID = 2560 ( get_view_column_defaultPGNSP PGUID 12 f f
> > t f i 1 2283 "25 25 21" _null_ _null_ _null_ g
Thanks Tom, that solved it...I added the new variables one at a time
and did do a "make clean" on the first occasion but I must have
forgotten to do it the second time...
I have another question-
The new variables that I've added to Plan and Path i.e.
hutz_tbl_benefit and hutz_idx_benefit are bein
Jaime Casanova <[EMAIL PROTECTED]> writes:
> I have added a function in sources and added appropiate lines in pg_proc.h
> DATA(insert OID = 2560 ( get_view_column_defaultPGNSP PGUID 12 f f
> t f i 1 2283 "25 25 21" _null_ _null_ _null_ get_view_column_default -
> _null_));
> DESCR("get default
I have added a function in sources and added appropiate lines in pg_proc.h
DATA(insert OID = 2560 ( get_view_column_defaultPGNSP PGUID 12 f f
t f i 1 2283 "25 25 21" _null_ _null_ _null_ get_view_column_default -
_null_));
DESCR("get default value for view column");
then make; make install; a
Manfred Koizar <[EMAIL PROTECTED]> writes:
> Another idea: WAL replay does not apply changes to nonexistent blocks,
> but it keeps a list (hash table, file, whatever) of those blocks.
> When a truncate WAL record is found, all entries for blocks affected
> by the truncation are removed from the lis
Vikram Kalsi <[EMAIL PROTECTED]> writes:
> 1.) New Variables ADDED to src/include/nodes/plannodes.h
> 2.) New Variables ADDED to src/include/nodes/relation.h
> ...
> However, after these modifications the server process crashes on
> running a Join query like
> "select s_suppkey,c_custkey from supp
On Wed, 18 May 2005 13:50:22 +0200, I wrote:
>The most important figure is, that at MaxSpeed (/O2) 2x32 is almost
>twice as fast as CRC32 while only being marginally slower than CRC32.
^
Silly typo! That should have been:
The most important figure is, that at MaxSpeed (/O2) 2
On Wed, 25 May 2005 11:02:11 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Plan B is for WAL replay to always be willing to extend the file to
>whatever record number is mentioned in the log, even though this
>may require inventing the contents of empty pages; we trust that their
>contents won't matt
Hello,
I've been using Postgresql-8.0.1 (Release date: 2005-01-31) for my
research work and I guess I finally need some help with it...
I'm not trying to modify the existing functionality, but I want to add
few things. In particular, I'm calculating two new Cost values and I
need to use them whil
It appears that SQL
submited via the latest JDBC driver won't get logged even if
log_min_duration_statement is set appropriately. From what I've found in the
archives, this is because the driver uses an "extended" version of the
protocol.
Could somebody point
me at the area of the source
Tom Lane wrote:
> Plan B is for WAL replay to always be willing to extend the file to
> whatever record number is mentioned in the log, even though this
> may require inventing the contents of empty pages; we trust that their
> contents won't matter because they'll be truncated again later in the
>
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
>
> > How hard would it be to have Postgres actually remove the gettimeofday
> > overhead from the EXPLAIN ANALYZE output?
>
> Personally, I dislike measurement tools that lie to you under the flag
> of producing more-
We've seen two recent reports:
http://archives.postgresql.org/pgsql-admin/2005-04/msg8.php
http://archives.postgresql.org/pgsql-general/2005-05/msg01143.php
of postmaster restart failing because the WAL contains a reference
to a page that no longer exists.
I can think of a couple of possible e
Greg Stark <[EMAIL PROTECTED]> writes:
> How hard would it be to have Postgres actually remove the gettimeofday
> overhead from the EXPLAIN ANALYZE output?
Personally, I dislike measurement tools that lie to you under the flag
of producing more-easily-interpreted results.
As an example of why th
I think this is the driver's problem. It appears that we are following
the spec, so lets leave this alone.
Regarding what an OUT parameter might mean. We already have some
facility in the FE/BE to indicate the types of the returning columns.
Directionality is implied by where in the bind messa
22 matches
Mail list logo
