On Thu, Aug 27, 2015 at 1:01 PM, Qingqing Zhou
<zhouqq.postg...@gmail.com> wrote:
> On Wed, Aug 26, 2015 at 5:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>
>> After looking at the code a bit, IMO the most reasonable thing to do is to
>
On Mon, Aug 31, 2015 at 2:12 AM, Oleg Bartunov wrote:
>
> AFAIK, XC/XL has already some customers and that is an additional pressure
> on their development team, which is now called X2. I don't exactly know how
> internal Huawei's MPPDB is connected to XC/XL.
>
Huawei's
On Wed, Aug 26, 2015 at 5:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
After looking at the code a bit, IMO the most reasonable thing to do is to
include this transformation in inline_set_returning_functions(), perhaps
renaming it to something like inline_srfs_and_ctes().
This is essentially
On Wed, Aug 19, 2015 at 10:32 AM, Qingqing Zhou
zhouqq.postg...@gmail.com wrote:
On Tue, Aug 18, 2015 at 5:59 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
BTW, did you register the patch on the upcoming commit-fest?
Not yet, it is in WIP status.
While I am working on the patch, I found some
On Fri, May 1, 2015 at 2:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Multiply-referenced WITH item (unless the outer query applies
identical constraints to each reference, which seems silly and not
worth the cycles to check for).
Not sure if I understand this correctly. Look at this query, CTE
On Tue, Aug 18, 2015 at 5:59 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
BTW, did you register the patch on the upcoming commit-fest?
Not yet, it is in WIP status.
I think it may be a helpful feature, if we can add alternative
subquery-path towards cte-scan on set_cte_pathlist() and choose
On Mon, Aug 17, 2015 at 6:40 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Here is one other thing I could learn from TPC-DS benchmark.
The attached query is Q4 of TPC-DS, and its result was towards SF=100.
It took long time to compete (about 30min), please see the attached
EXPLAIN ANALYZE
All look good to me,
Thank you,
Qingqing
On Wed, Aug 12, 2015 at 8:37 AM, Andres Freund and...@anarazel.de wrote:
Hi,
On 2015-08-11 01:15:37 +0200, Andres Freund wrote:
I'm too tired right now to look at this, but it generally looked sane.
Pushed your fix to master and 9.5, with two very
On Sun, Aug 9, 2015 at 8:24 AM, Robert Haas robertmh...@gmail.com wrote:
In step 1, AcceptInvalidationMessages() should process all pending
invalidation messages. So if step 2 did AcceptInvalidationMessages()
again it would be a no-op, because no messages should remain at that
point.
Attached patch fixes oversights converting buf_id to Buffer in
PrintBufferDescs() and InvalidateBuffer(). Especially for the latter,
the reason we haven't seen any reports of the issue might be that it
needs certain concurrent conditions to be true.
Along the line, it also changes all direct
On Mon, Aug 10, 2015 at 4:15 PM, Andres Freund and...@anarazel.de wrote:
That's a very nice catch! Did you trigger the error or just found it
when reading the code?
My fellow colleagues hit the issue during some stress: I am not clear
the exact repro but from the failed assertion, the cause
In cache invalidation logic, we have the following comment:
/*
* Now that we have the lock, check for invalidation messages, so that we
* will update or flush any stale relcache entry before we try to use it.
* RangeVarGetRelid() specifically relies on us for this. We can skip
* this in the
On Thu, Jul 30, 2015 at 2:42 PM, Jim Nasby jim.na...@bluetreble.com wrote:
I think a better option would be shoving it into a backend tuplestore and
just leaving it there (maybe with a command to clear it for the paranoid).
That gives a relation you can query against, insert into another
On Wed, Jul 29, 2015 at 11:26 AM, Piotr Stefaniak
postg...@piotr-stefaniak.me wrote:
+ Assert(path_rows != 0);
if (tuple_fraction = 1.0)
tuple_fraction /= path_rows;
}
This does not sounds right:
On Tue, Jul 28, 2015 at 6:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another point is that we decided a long time ago that EXPLAIN's plain-text
output format is not intended to be machine-parsable, and so objecting to
a design on the grounds that it makes machine parsing harder is pretty
On Tue, Jul 28, 2015 at 2:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You can do something like that in plpgsql, for example
declare t text;
for t in EXPLAIN SELECT ...
loop
insert into whatever values(t);
end loop;
I see - this is cool.
There are still something
On Mon, Jul 27, 2015 at 8:20 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I think this is a pretty neat idea, but I'm not sure this user interface
is a good one. Why not have a new option for EXPLAIN, so you would call
EXPLAIN (planner_stuff=on) and it returns this as a resultset?
On Tue, Jul 28, 2015 at 12:08 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I would have a tuplestore, and the planner code would push tuples to it.
After the planning is done, EXPLAIN can read and return tuples from the
store to the user.
Not sure if I got it: so EXPLAIN will return
On Thu, Jul 23, 2015 at 4:11 PM, Tatsuo Ishii is...@postgresql.org wrote:
Sounds like a great feature!
Thanks!
Attached is a draft patch implementing the idea. To play with it, you
shall create the follow two foreign tables:
CREATE EXTENSION file_fdw;
CREATE SERVER pglog FOREIGN DATA WRAPPER
On Tue, Jul 21, 2015 at 5:15 PM, Qingqing Zhou
zhouqq.postg...@gmail.com wrote:
Here is a proposal introducing some debugging infrastructure into the
core. The basic idea is to allow us to query the planner search space.
To so do, we can dump related information to csv files and use foreign
Here is a proposal introducing some debugging infrastructure into the
core. The basic idea is to allow us to query the planner search space.
To so do, we can dump related information to csv files and use foreign
table to query them. So here I propose two foreign tables:
create foreign table
On Thu, Jul 2, 2015 at 11:37 AM, CK Tan ck...@vitessedata.com wrote:
I am sorry to ask questions unrelated to the subject, but how is tracking
memory going to fix the HashAgg blow up problem? Is there a plan to make
HashAgg not blow up (i.e. spill the hash table)?
Your question is probably
On Fri, Jun 5, 2015 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So I really doubt that anyone would have any enthusiasm for saddling btree
with a similar mechanism. It's complicated (and has been the cause of
multiple bugs); it's hard to figure out when is the optimal time to flush
the
On Mon, May 4, 2015 at 1:23 PM, Robert Haas robertmh...@gmail.com wrote:
I fixed several whitespace errors, reverted the permissions changes
you included
Sorry about the permission changes - didn't notice that bite.
Thanks,
Qingqing
--
Sent via pgsql-hackers mailing list
On Thu, Apr 30, 2015 at 5:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think I'd have done many of these as
+ PlanState *outerPlan = outerPlanState(node);
rather than finding assorted random places to initialize the variables.
Agreed. Attached patch is revision along this line.
On Thu, Apr 30, 2015 at 8:02 AM, Robert Haas robertmh...@gmail.com wrote:
I don't mind the MSDOS newlines, but the UTF-16le bit is inconvenient.
UTF-8 would be much better, so I don't have to figure out how to
convert.
The patch is generated via github windows tool and that's possibly
why. I
On Fri, Apr 17, 2015 at 11:19 AM, Qingqing Zhou
zhouqq.postg...@gmail.com wrote:
Most commercial database employs a DMS storage model, where it manages
object mapping and freespace itself. So different objects are sharing
storage within several files. Surely it has historic reasons
On Sun, Apr 19, 2015 at 7:09 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I did literally the simplest thing I could think of as a proof of concept
patch, to see if it would actually fix things. I just jumped back a certain
number of blocks occasionally and prefetched them forward, then
On Sat, Feb 28, 2015 at 8:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
There would be cases where that would be a win, and there would be cases
where it wouldn't be, so I'd not be in favor of making the transformation
blindly. Unfortunately, given the current state of the planner that's
all we
Attached is a patch to assert there is no duplicated exit callbacks.
Along the way, I downgrade the runtime enough room check to an
assertion: the callbacks are registered in pretty fixed initialization
code path, thus assertion is good enough to prevent overlook there. If
we don't agree with
Hmm, the email text seems corrupted?
Regards,
Qingqing
On Wed, Apr 15, 2015 at 10:03 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
湏〠⼴㔱㈯‵㜰㔺′䵐楑杮楱杮娠潨⁵牷瑯㩥‾瑁慴档摥椠慰捴潴愠獳牥⁴
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Apr 15, 2015 at 1:40 PM, Andrzej Barszcz abus...@gmail.com wrote:
I knock once again with this : reparse query to XML ( last knock 5-6 years
before) .
What exactly reparse query to XML does?
Regards,
Qingqing
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
In executor context, outerPlanState(node) is the same as
node-ss.ps.lefttree. We follow this in most places except a few. This
patch clean up the outliers and might save us a few instructions by
removing indirection.
Most of changes are trivial. Except I take out an outerPlan nullable
check in
On Wed, Apr 15, 2015 at 2:04 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
His old posting:
https://www.postgresql.org/message-id/1247323023.16438.35.camel%40ab-desktop
Is this a proposal to have a better formatted (JSON etc)
debug_print_parse results?
Thanks,
Qingqing
--
Sent via
On Wed, Apr 15, 2015 at 5:19 PM, Lukas Fittl lu...@fittl.com wrote:
It'd be interesting to explore if there is some way to make this less
hack-ish, and enable tools to parse queries in a better way. Essentially
what is needed is some way to reliably translate SQL into an AST-like
output, from
I am playing git tip on windows 7/32 bits, with the backend compiled
with visual studio 2005 (I know, it is very old :-( ).
I encountered avl shutdown slowness twice, last night and this
morning: after a ctrl_c is hit, wait for another 60 seconds, server
shuts down. Here is one log:
as there is way to go back. So we can
insert HOLD_INTERRUPTS() just before it.
Thoughts?
Regards,
Qingqing
On Tue, Apr 7, 2015 at 10:54 AM, Qingqing Zhou
zhouqq.postg...@gmail.com wrote:
I am playing git tip on windows 7/32 bits, with the backend compiled
with visual studio 2005 (I know
On Tue, Apr 7, 2015 at 2:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That seems like (a) a hack, and (b) not likely to solve the problem
completely, unless you leave interrupts held throughout proc_exit(),
which would create all sorts of opportunities for corner case bugs
during on_proc_exit
On Tue, Apr 7, 2015 at 4:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Indeed, which is why I think a patch for this issue should not introduce
a new mode/context in which proc_exit() is executed.
Agree. Along this line, we can add an on_proc_exit hook simply
ereport(we are exiting) there. In this
On Tue, Apr 7, 2015 at 6:11 PM, Peter Geoghegan p...@heroku.com wrote:
No. For one thing, unique index enforcement still requires the tuples
to be treated as a conflict while the other transaction is running
IMV.
Not sure if I understand correctly: in uniqueness check, we see all
possible
The symptom is that the same join query yield different results with
MJ and NLJ/HJ. Here is a repro:
---
create table t1(a int);create table t2(b int);
insert into t1 values(10); insert into t2 values(2);
analyze t1; analyze t2;
set enable_mergejoin=on; set enable_nestloop=off; set
On Mon, Mar 2, 2015 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There is an issue if you do a dump and restore: the toast OIDs used in any
one table will be consecutive after that, because we load all the data for
each table sequentially.
With these consecutive oids, the aggravated oid
One scenario is to use an oid to identify a toast value. As the oid
generation is mono increased within a database instance, it can gets wrap
around after 2^32 generations. After that:
1. GetNewOidWithIndex() could gets unbounded performance as it needs to by
pass already in use values of its own.
SIGFPE is a synchornous signal and Windows will raise it if proper flag is
set (check out the example program):
http://msdn2.microsoft.com/en-us/library/kfy34skx.aspx
But seems we didn't use the above method. Instead, we use the same
methodology as other asynchrounous signals. My question
jkzhao [EMAIL PROTECTED] wrote
But, create user HU then connect PostgreSQL by HU is wrong.
If you do
postgres=# create user HU;
You will get the HU as you want. Usage of the quotation marks is in the
manual.
I'd like to know whether I can make PostgreSQL stands to the SQL92
In ShmemAlloc() we have:
newStart = BUFFERALIGN(newStart);
newSpace = (void *) (ShmemBase + newStart);
return newSpace;
Notice that though newStart is ALIGNOF_BUFFER, ShmemBase is not. Thus the
newSpace is not aligned as we disired.
Attached please find the patch.
Regards,
Qingqing
Andrew Hammond [EMAIL PROTECTED] wrote
Also, are there any other (simple for now) things I
should look at in the process?
The shared memory estimiation logic is in
ipc/ipci.c/CreateSharedMemoryAndSemaphores(). If you want to get an accurate
number, you need to consider:
(1) different
Katsuhiko Okano [EMAIL PROTECTED] wrote
The problem has occurred in my customer.
poor performance with Context Switch Storm occurred
with the following composition.
Usually, CS is about 5000, WIPS=360.
when CSStorm occurrence, CS is about 10, WIPS=60 or less.
Intel Xeon 3.0GHz*4(2CPU
Tom Lane [EMAIL PROTECTED] wrote
One idea that comes to mind is to have a compile time option to record
the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
would not be so hard to identify the culprit while trawling through
memory. The overhead costs would be so high that
On CVS tip:
$ postgres --single -Ddata postgres
PostgreSQL stand-alone backend 8.2devel
Segmentation fault (core dumped)
$ gdb -c core.18119
(gdb) bt
#0 pgstat_report_activity (cmd_str=0x67d25e IDLE) at pgstat.c:1484
1484beentry-st_changecount++;
(gdb) bt
#0 pgstat_report_activity
Tom Lane [EMAIL PROTECTED] wrote
postgres --single works for me. Maybe you need a make
distclean/rebuild?
Sorry, because I forget to say that you need to turn stats_command_string
on. When it is off, pgstat_report_activity() will return immediately so
nothing wrong could be observed.
Alvaro Herrera [EMAIL PROTECTED] wrote
But the problem (or at last a part of the problem) is not what context
each chunk is allocated in, but where did a given chunk come from (where
was it allocated), Which is why saving __FILE__/__LINE__ is useful.
Agreed. Maybe we should not clutter
ITAGAKI Takahiro [EMAIL PROTECTED] wrote
I'm interested in it, with which we could improve responsiveness during
checkpoints. Though it is Linux specific system call, but we could use
the combination of mmap() and msync() instead of it; I mean we can use
mmap only to flush dirty pages, not
As I follow Relyea Mike's recent post of possible memory leak, I think that
we are lack of a good way of identifing memory usage. Maybe we should also
remember __FILE__, __LINE__ etc for better memory usage diagnose when
TRACE_MEMORY is on?
Regards,
Qingqing
---(end of
As I read, the kill_prior_tuple optimization doesn't work for bitmap scan
code. To fix this problem, we have two choices.
One is still use the kill_prior_tuple trick in a modified way. Heap TIDs
recycling should not be a problem. This is because generally we always hold
pin of the last index page
Tom Lane [EMAIL PROTECTED] wrote
Really? An indexscan will release pin before returning no-more-tuples,
and had better do so else we leak pins during queries involving many
indexscans.
I guess I see your point. For the scan stages not returning no-more-tuples,
we can do kill, but the
Bruce Momjian pgman@candle.pha.pa.us wrote
Would some people please run the attached test procedure and report back
the results? I basically need to know the patch is an improvement on
more platforms than just my own. Thanks
Obviously it matches your expectation.
uname: Linux amd64
Josh Berkus josh@agliodbs.com wrote
The other is the connection pool architecture: shall we let
postmaster manage the slaves or let another process say slave-master to
handle them? Currently I am choosing the latter.
Hmmm. Why not the postmaster?
Not real reason just feel that's
Simon Riggs [EMAIL PROTECTED] wrote
Can we do the same for the file descriptors in fd.c?
Very often the total number of file descriptors is much less than the
maximum, so it would make sense to only maintain the LRU when we are
using more than 50%-75% of the maximum.
I am not against
Tom Lane [EMAIL PROTECTED] wrote
Hm? I don't see any improvement there:
I was referening this sentence, though I am not sure why that's the
expectation:
Bruce Momjian pgman@candle.pha.pa.us wrote
If the patch worked, the first and third times will be similar, and
the second time will be
When I read the post related to the battery-backed disks, I come to this
question: What can we improve/reduce if we have them? Since our fsync
methods is already be able support that (thought not automatically), we may
want to look into other parts. One issue is the xlog and our aim is (1)
reduce
letizia leo [EMAIL PROTECTED] wrote
Transaction T1 updates a given tuple -- xmax is set to T1 on that tuple
...
later on, T1 aborts... we believe that in this circumstance
HEAP_XMAX_INVALID should
be set on the tuple to signal that the tuple was not actually deleted by
T1 since this
Bruce Momjian pgman@candle.pha.pa.us wrote
-- After patch --
real0m1.275s
user0m0.097s
sys 0m0.160s
real0m4.063s
user0m0.663s
sys 0m0.377s
real0m1.259s
user0m0.073s
sys 0m0.160s
I assume the above is just running the same test three
Bruce Momjian pgman@candle.pha.pa.us wrote
Any idea why there is such a variance in the result? The second run
looks quite slow.
No luck so far. It is quite repeatble in my machine -- runing times which
show a long execution time: 2, 11, 14, 21 ... But when I do strace, the
weiredness
Bruce Momjian pgman@candle.pha.pa.us wrote
Added to TODO list.
One thing we tried in February was padding out the statically defined
locks with dummy lock definitions in the enum. This has the effect of
ensuring that the most contested locks are very definitely in their own
cache line
Tom Lane [EMAIL PROTECTED] wrote
Not really --- that patch was intended to ensure that LWLocks don't
unnecessarily cross two cache lines. It doesn't ensure that two
different LWLocks aren't sharing a cache line. You could do that
by increasing LWLOCK_PADDED_SIZE to the cache line size for
I may have some free time recently to work on the master-slave scan idea.
I've been able to support AS-IS both SeqScan and IndexScan. Are we still
interested in getting it into 8.2?
There are still some problems I am not quite sure the solution. One is the
Xid assignment -- we need this to assure
Tom Lane [EMAIL PROTECTED] wrote
You'd need two essentially equivalent versions of SearchSysCache, and
you'd lose the ability to make the error message identify what was being
searched for, so I vote no.
Both arguments are not necessarily true. This change is quite like what we
made to
I encounter a situation that the server can't shutdown when a boostrap
process does ReadBuffer() but gets an read error. I guess the problem may be
like this - the boostrap process can't read at line:
smgrread(reln-rd_smgr, blockNum, (char *) bufBlock);
So it does a FATAL exit and
Tom Lane [EMAIL PROTECTED] wrote
Do you have a test case to reproduce this problem?
According to the error message, the problem happens during reading
pg_database. I just tried to plug in this line in mdread():
+/* pretend there is an error reading pg_database */
+if
There are roughly 420 calls of SearchSysCache() and 217 of which are just
report cache lookup failed. Shall we put the elog in the SearchSysCache
itself?
Notice that most search is on the Oid field -- which is *not* user
visible, so I think most of them can safely let SearchSysCache handle the
Jim Nasby [EMAIL PROTECTED] wrote
Now that we've got a nice amount of tuneability in the bgwriter, it
would be nice if we had as much insight into how it's actually doing.
I'd like to propose that the following info be added to the stats
framework to assist in tuning it:
In general, I
Tom Lane [EMAIL PROTECTED] wrote
Yeah. The LIKE index optimization depends on seeing a constant LIKE
pattern at plan time --- otherwise the planner doesn't know what
indexscan parameters to generate. So a bound-parameter query loses.
AFAICS the problem is not restricted to LIKE, we can
Joshua D. Drake [EMAIL PROTECTED] wrote
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
E.g;
postgres=# select * from foo; update foo set bar = 'baz'; delete from
bing;
Would be a single transaction ? The begin/commit would be
ipig [EMAIL PROTECTED] wrote
in postgresql-8.1.3/src/backend/storage/lmgr/proc.c
there are 2 function InitProcess and InitDummyProcess, both use
if (MyProc != NULL)
elog(ERROR, you already exist); (line 215 and 315)
why use != ?
I guess you misread exist to exit? Try
Cristiano Duarte [EMAIL PROTECTED] wrote
Does anyone know how to discover the tables (with schemas or oid)
involved
on a select statement?
I tried EXPLAIN but it only reports the table names, not schemas or
oid.
In general, this is a pretty difficult problem - thinking you may do a
Dhanaraj M [EMAIL PROTECTED] wrote
2. *Invalidate prepared queries, like INSERT, when the table
definition is altered
*Invalidation means recompilation or deletion of the prepared stmt
here.*
*Both the items look similar. i.e) needs recompilation of the query
after altering the table.
Tom Lane [EMAIL PROTECTED] wrote
The thing that's nagging at me at the moment is the realization that a
partitioned hashtable will eat more shared memory than a single
hashtable. It wasn't that long ago that we had to do some hacking to
ensure that the buffer hashtable couldn't run out of
Jim C. Nasby [EMAIL PROTECTED] wrote
There a patched build available for testing? (I'd rather not have to
figure out how to get windows builds working, unless there's some kind
of instructions somewhere...)
--
Not yet - the patch is still pending.
Regards,
Qingqing
Tom Lane [EMAIL PROTECTED] wrote
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Apr 20, 2006 at 12:17:07PM -0500, Jim C. Nasby wrote:
Here's one to add to the list: running pgbench with a moderately heavy
load on an SMP box likes to trigger a state where the database (or
Magnus Hagander [EMAIL PROTECTED] wrote
I'm not sure why the win32 port chose to emulate the SysV
semaphore interface anyway. You could equally well have used
the Posix interface (src/backend/port/posix_sema.c). Or,
given Microsoft's NIH tendencies, you might have needed to
write a
Qingqing Zhou [EMAIL PROTECTED] wrote
So we might want to fix current win32/sema.c for two problems:
(1) semctl(SETVAL, val=0) - there is no other val than zero is used;
(2) concurrent access to sem_counts[];
Attached is a patch for the above proposed change -- but still, I hope we
don't
Qingqing Zhou [EMAIL PROTECTED] wrote
As I reviewed the win32/sema.c, there is some code that I am not clear,
can
anybody explain please?
There is another problem related to concurrent operations on win32 sema. Say
two processes are doing semop(+1) concurrently. Look at this code:
/* Don't
Tom Lane [EMAIL PROTECTED] wrote
Qingqing Zhou [EMAIL PROTECTED] writes:
After this, the proc-sem will be bumped to 1 unexpectedly ... Since
this
problem is rare, a possible fix is to put a critical section around line
1
to 7 and remove UnlockBuffers() accordingly.
No, that would make
We have a wait-pin-to-1 mechanism in LockBufferForCleanup() like this:
1: bufHdr-wait_backend_pid = MyProcPid;
2: bufHdr-flags |= BM_PIN_COUNT_WAITER;
3: PinCountWaitBuf = bufHdr;
4: UnlockBufHdr_NoHoldoff(bufHdr);
5: LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
6: /*
As I reviewed the win32/sema.c, there is some code that I am not clear, can
anybody explain please?
In semctl(SETVAL):
if (semun.val sem_counts[semNum])
sops.sem_op = -1;
else
sops.sem_op = 1;
/* Quickly lock/unlock the semaphore (if we can) */
if (semop(semId, sops, 1) 0)
Markus Schiltknecht [EMAIL PROTECTED] wrote
Hi,
On Sun, 2006-04-09 at 15:11 -0400, Tom Lane wrote:
You can't just retarget a backend to operate in another database, at
least not without major changes in that infrastructure.
Why not? What would be needed to retarget a backend to operate
Peter Eisentraut [EMAIL PROTECTED] wrote
Is there a reason for why you can't update the OID column other than that
no
one has bothered to code up the support for it?
AFAIK if two rows are with the same OID, we will think these two rows are
different versions of the same tuple. So if we allow
Markus Schiltknecht [EMAIL PROTECTED] wrote
Hi Qingqing,
As Tom pointed out, without big change, a backend on database D1 can't
connect to D2. This is because to connect to a database, we need to
initialize a lot of variables. So when you reconnect to another one on
the
fly, you have
Tom Lane [EMAIL PROTECTED] wrote
This is exactly the bit of optimism I was questioning. We've already
been sweating blood trying to reduce multiprocessor contention on data
structures in which collisions ought to be avoidable (ie, buffer arrays
where you hope not everyone is hitting the
Upon several requests of the master-slave patch source code, I sent it
here. This is a proof-of-concept implementation only to show it is
feasible only.
To play with it, applied it to cvs tip. When you key in a SQL like:
SELECT max(i) FROM t; // t with more than 20 records
You are
I have written some experimental code of doing master-slave seqscan in
PostgreSQL. During the work, I feel we had enough infrastructure to support
parallel query execution.
What I did is adding a new node PARA and plug it above the node that we want
to execute in parallel. In this stage, a PARA
Jonah H. Harris [EMAIL PROTECTED] wrote
Great work! I had looked into this a little bit and came to the same
ideas/problems you did, but none of them seemed insurmountable at all.
I'd be interested in working with you on this if you'd like.
Yes, I am happy to work with anyone on the
Josh Berkus josh@agliodbs.com wrote
Sure, although the important part is to find students. I'm not sure how
we
do that.
I noticed two email domains are @mit.edu and @cs.toronto.edu but I am afraid
both of them are not students any more :-)
Regards,
Qingqing
Tom Lane [EMAIL PROTECTED] wrote
The problem is that process IDs on Windows seem to be assigned without
much rhyme or reason and it seems to happen relatively frequently that a
new process will be assigned the same process ID as a process which
recently died.
That's an interesting theory,
Tom Lane [EMAIL PROTECTED] wrote
Redmond crowd should be able to figure out that recycling process IDs
instantly would be a stupid idea...)
Can you explain more of this? IMHO, if we rely on feature like this, the
difference is unstable-every-day vs. unstable-every-year.
Regards,
Qingqing
Juan Manuel Diaz Lara [EMAIL PROTECTED] wrote
bootparse.y:101:10: b4_file_name is not a valid filename
bison-2.1.exe -- d:\gnuwin32
Maybe it is bison's problem. I always use 1.875 since it has been there long
enough powerful enough ...
Regards,
Qingqing
---(end
Qingqing Zhou [EMAIL PROTECTED] wrote
Tom Lane [EMAIL PROTECTED] wrote
What we should be seeing, and don't see, is an indication of a backup
block attached to this WAL record. Furthermore, I don't see any
indication of a backup block attached to *any* of the WAL records in
Alex's printout
Tom Lane [EMAIL PROTECTED] wrote
This is pretty much what heapam and btree currently do, but on looking
at it I think it's got a problem: we really ought to mark the buffer
dirty before releasing the critical section. Otherwise, if there's an
elog(ERROR) before the WriteBuffer call is
Jonah H. Harris [EMAIL PROTECTED] wrote
Yeah, I noticed that one. How would you suggest setting
CLASS_TUPLE_SIZE in that case?
What if you put your char[64] before relhassubclass, then you don't change
CLASS_TUPLE_SIZE.
Regards,
Qingqing
---(end of
1 - 100 of 305 matches
Mail list logo