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 MPPDB is based on PG-XC an
On Thu, Aug 27, 2015 at 1:01 PM, Qingqing Zhou
wrote:
> On Wed, Aug 26, 2015 at 5:28 PM, Tom Lane 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
>> re
On Wed, Aug 26, 2015 at 5:28 PM, Tom Lane 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 the same as my c
On Wed, Aug 19, 2015 at 10:32 AM, Qingqing Zhou
wrote:
> On Tue, Aug 18, 2015 at 5:59 PM, Kouhei Kaigai 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 issues and re
On Fri, May 1, 2015 at 2:39 PM, Tom Lane 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 q is
reference
On Tue, Aug 18, 2015 at 5:59 PM, Kouhei Kaigai 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
> them according
On Mon, Aug 17, 2015 at 6:40 AM, Kouhei Kaigai 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 output.
>
Look at
All look good to me,
Thank you,
Qingqing
On Wed, Aug 12, 2015 at 8:37 AM, Andres Freund 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 minor changes
On Mon, Aug 10, 2015 at 4:15 PM, Andres Freund 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 is kinda
clear.
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 maths
On Sun, Aug 9, 2015 at 8:24 AM, Robert Haas 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.
>
That's what I think a
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 not-u
On Thu, Jul 30, 2015 at 2:42 PM, Jim Nasby 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 table, etc.
> --
This is
On Wed, Jul 29, 2015 at 11:26 AM, Piotr Stefaniak
wrote:
> + Assert(path_rows != 0);
> if (tuple_fraction >= 1.0)
> tuple_fraction /= path_rows;
> }
>
This does not sounds right: path_rows only used when
On Tue, Jul 28, 2015 at 6:13 PM, Tom Lane 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
> wrongheaded. I'd thi
On Tue, Jul 28, 2015 at 2:43 PM, Tom Lane 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 bothering
On Tue, Jul 28, 2015 at 12:08 PM, Alvaro Herrera
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 tuples to libpq client.
On Mon, Jul 27, 2015 at 8:20 PM, Alvaro Herrera
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?
Thank you for the feedb
On Thu, Jul 23, 2015 at 4:11 PM, Tatsuo Ishii 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 file_fdw;
create for
On Tue, Jul 21, 2015 at 5:15 PM, Qingqing Zhou
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
> table t
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 pg_p
On Thu, Jul 2, 2015 at 11:37 AM, CK Tan 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 answered here:
htt
On Fri, Jun 5, 2015 at 10:59 AM, Tom Lane 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 pending insertion
On Thu, Jun 11, 2015 at 4:03 PM, Alvaro Herrera
wrote:
> I've been trying to figure out a plan to enable native column stores
> (CS or "colstore") for Postgres. Motivations:
>
> * avoid the 32 TB limit for tables
> * avoid the 1600 column limit for tables
> * increased performance
>
And better co
On Mon, May 4, 2015 at 1:23 PM, Robert Haas 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 (pgsql-hackers@postgresql.org)
To make
On Thu, Apr 30, 2015 at 5:04 PM, Tom Lane 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. Except for a
On Fri, Apr 17, 2015 at 11:19 AM, Qingqing Zhou
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, but it
> has sev
On Thu, Apr 30, 2015 at 8:02 AM, Robert Haas 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 regenerated it in
On Sun, Apr 19, 2015 at 7:09 PM, Jeff Janes 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 resumed the
> regular b
On Sun, Mar 29, 2015 at 11:56 AM, Andres Freund wrote:
> I'm not sure whether the above is the best solution however. For one I
> think it's not necessarily a good idea to opencode this in hio.c - I've
> not observed it, but this probably can happen for btrees and such as
> well. For another, this
On Sat, Feb 28, 2015 at 8:24 AM, Tom Lane 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 could do reall
On Wed, Apr 15, 2015 at 5:19 PM, Lukas Fittl 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 an outside t
On Wed, Apr 15, 2015 at 2:04 PM, Alvaro Herrera
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 pgsql-hackers mailing li
On Wed, Apr 15, 2015 at 1:40 PM, Andrzej Barszcz 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 make changes
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 gr
Hmm, the email text seems corrupted?
Regards,
Qingqing
On Wed, Apr 15, 2015 at 10:03 AM, Heikki Linnakangas wrote:
> 湏〠⼴㔱㈯‵㜰㔺′䵐楑杮楱杮娠潨⁵牷瑯㩥‾瑁慴档摥椠慰捴潴愠獳牥⁴
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
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 th
On Tue, Apr 7, 2015 at 6:11 PM, Peter Geoghegan 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 tuples with a d
On Tue, Apr 7, 2015 at 4:01 PM, Tom Lane 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 way, we reuse
On Tue, Apr 7, 2015 at 2:32 PM, Tom Lane 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 hooks.
>
Hmm, loo
ce
that this ereport() is special 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
wrote:
> I am playing git tip on windows 7/32 bits, with the backend compiled
> with visual stud
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:
D:\pgsql\bin>
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 enable_hashjoi
On Mon, Mar 2, 2015 at 12:38 PM, Tom Lane 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 wrap around" can
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.
""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
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 is:
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
Index
"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 Po
"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.0
"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 hig
"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 obs
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 "") at pgstat.c:1484
1484beentry->st_changecount++;
(gdb) bt
#0 pgstat_report_activity (
"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 clut
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 b
"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 pa
"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 t
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
"Bruce Momjian" 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 disappered totally. H
"Bruce Momjian" 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 te
"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
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
"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" wrote
> If the patch worked, the first and third times will be similar, and
> the second time will be high.
>
-
"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 ag
"Josh Berkus" 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 clearer (but
"Bruce Momjian" 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 2.6.9-5.13smp #1 SMP
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
>
> 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 s
"Bruce Momjian" 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 and not sh
"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
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
"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 (r
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 shmem_exit
"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 gener
"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, w
""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 "
""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/commi
"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
"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 d
""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
>
> 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
"Tom Lane" <[EMAIL PROTECTED]> wrote
> Martijn van Oosterhout 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
> >> pgbench)
"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 a
""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 neede
"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) concur
"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
>
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: /* Wa
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) <
"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
"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
"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
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 s
"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
""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
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 no
"Josh Berkus" 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
---(end of broadc
"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,
Qin
"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 intere
"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
--
"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
&g
1 - 100 of 313 matches
Mail list logo
