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 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
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 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 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 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 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 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 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
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 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
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 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.
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 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
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 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 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 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 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 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
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
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>
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
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
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 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
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
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
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
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
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 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 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 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 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 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 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 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 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
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.
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
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 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, 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
"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
"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
"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
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
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:
""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
Here are two questions related to PG8.0.1:
1. durability of "create tablespace" - what happens if several checkpoints
done after "create tablespace" then system crashes - without redo, will the
PG_VERSION file and symlinks survive in win32? Seems checkpoint didn't sync
the content of PG_VERSION fi
> There is no such thing as crash without redo: that is what WAL is all
> about. The creation of the tablespace will be correctly replayed from
> WAL. (Of course, this claim depends on various assumptions about
> whether fsync behaves per spec ... but if it does not, tablespace
> creation is har
"Christopher Kings-Lynne" <[EMAIL PROTECTED]>
> Running latest cvs on freebsd gives me errors in test strings and test
> errors, and completely hangs at this point:
I got a similar problem and system hangs randomly(esp. in test strings) in
win32-mingw. The problem I found is in pgunlink(). There
I encounter the similar problem in "make check" (win2k-mingw, 8.0.1). The
regression test could randomly fail due to "could not write block (Invalid
argument)" problem or could not "remove file" problem.
Regards,
Qingqing
p.s. I believe this could be a potential serious problem, so I forward it t
We have the following definition in fd.c:
typedef struct vfd
{
signed short fd; /* current FD, or VFD_CLOSED if none */
...
} Vfd;
but seems we use Vfd.fd as an integer, say in fileNameOpenFile() we have:
vfdP->fd = BasicOpenFile(fileName, fileFlags, fileMode);
So is there any special reas
"Harald Fuchs" <[EMAIL PROTECTED]> writes
> How about using an even coarser grain? Whenever something in the
> database in question changes, blindly throw away all cached plans for
> this DB.
>
If we clearly define what is "something in database in question", we have to
trace all the objects the
"Neil Conway" <[EMAIL PROTECTED]> writes
> I don't see that this is a major problem. If a plan A invokes a function
> B, then changes to B will need to invalidate A; that should be pretty
> easy to arrange. If B is a PL/PgSQL function that invokes a function C,
> it will probably cache a plan invo
"Bruce Momjian"
> I recieved this report of a failing set of queries:
>
> BEGIN;
> CREATE TABLE a (i INT);
> INSERT INTO a VALUES(1);
> DECLARE acur CURSOR FOR SELECT * FROM a;
> FETCH acur;
> \q
>
> It certainly looks like a simple set of queries.
>
> If this is done in 8.0.X the server shows:
>
"Neil Conway" <[EMAIL PROTECTED]>
> I've been taking a look at how to stop the planner from scribbling on
> its input. This is my first modification of any significance to the
> planner, so don't hesitate to tell me what I've gotten wrong :)
>
So is this change the preparation work of caching quer
"Tom Lane" <[EMAIL PROTECTED]> writes
> If your objection is that it's not being maintained, then that is no
> solution. Once it's out of the source code CVS it is *guaranteed* to
> not get updated to track source-code changes.
>
Is it possible that we insert some tags (like doc++ does) into sou
"Tom Lane" <[EMAIL PROTECTED]> writes
> It strikes me that the FlushRelationBuffers call is unnecessary and
> causes useless I/O, namely writing out pages into a file that's
> about to be deleted anyway. If we simply removed it then any buffers
> belonging to the victim relation would stay in mem
"Tom Lane" <[EMAIL PROTECTED]> writes
> So it'll get an error ... this scenario doesn't strike me as any worse
> than any other problem occuring in post-commit cleanup. The locks left
> around by the not-cleaned-up transaction would probably be a bigger
> issue, for example.
Yes, the result is a
This an item in the TODO list. But I am not sure how severe the problem is.
In my understanding, there are not so many conflicts but we may want to give
some hints to users of how to set proper GUC variables. For instance, if we
find "debug_print_parse" is set, we will suggest setting
"debug_pretty
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> We already have the ability to issue custom messages in assign_hooks,
> and I think that's sufficient in practice.
Yes, I agree this is already sufficient - seems we need to remove that TODO
item in the list.
>
> A bigger problem with making cross-variab
"Bruce Momjian" writes
> Removed. I think we have all the conflicting options fixed already:
>
One more thing, there is a small typo in TODO list: duplidated "Allow a warm
standby system to also allow read-only queries ".
Regards,
Qingqing
---(end of broadcast)--
"Srinivasa Perumal" <[EMAIL PROTECTED]> writes
>
> hi, is there is way undelete or recover the deleted row in a table in
postgres.iam layman, can anyone help me.
>
Here is one way but I am not sure it is a good one. The precondition is that
you didn't schedule any vacuum on your database.
Since P
"Oleg Bartunov" writes
> From my experiments I feel heap_blks_read is the table blocks read from
disk,
> well, sort of, and heap_blks_hit - from buffer. At least, I observed when
I
> repeat the same query several times (heap_blks_read+heap_blks_hit) doesn't
> changed while more blocks come from h
"Tom Lane" <[EMAIL PROTECTED]> writes
> Steve Crawford <[EMAIL PROTECTED]> writes:
> > On Monday 21 March 2005 11:40 am, Tom Lane wrote:
> >> However, given that there are 9334 tuples in 82282 pages, I'd say
> >> that autovacuum has already failed Steve rather badly :-(. There
> >> shouldn't be m
"Oleg Bartunov" writes
> One mystery remains, why stats show heap_blks_read > 0 for indexed search
?
> select 1 from foo where id=5
> I did pg_stat_reset() before run query.
>
There is no clustered index in PG so far, so all the data item has to be
stay in the heap. In brief, the executor ha
"Neil Conway" <[EMAIL PROTECTED]> writes
> PostgreSQL should invalidate a cached query plan when one of the objects
> the plan depends upon is modified.
It just comes into my mind that current cache invalidation implementation
may need to consider the future query result cache.
The question comes
""Mike G."" <[EMAIL PROTECTED]> writes
>
> If "1663/17269/1677179: Permission denied" refers to a file under the data
directory (I have found a folder 17269 that contains similiar names to
1677179) then it would seem postgres is trying to write data to a file that
does not exist.
>
I don't think
"Alvaro Herrera" <[EMAIL PROTECTED]> writes
> Because we can't reuse MultiXactIds at system crash (else we risk taking
> an Id which is already stored in some tuple), we need to XLog it. Not
> at the locking operation, because we don't want to log that one (too
> expensive.) We can log the curre
"Tom Lane" <[EMAIL PROTECTED]> writes
> While thinking about the use of hand-assigned OIDs for pg_proc and
> pg_operator, it occurred to me to wonder why we don't have hand-assigned
> OIDs for all system catalogs and indexes. Currently, most of the time
> that the C code wants to reference a speci
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes
> Is it possible to cluster system tables?
>
Ooops, I guess I mixed two concepts - oid and relfilenode. Those operations
change relfilenode but not oids. I don't think we could cluster system
tables.
template1=# select oid, relfilenode from pg
> > 2) Is it possible to write a where clause that can efficiently hit only
> > the tuples in the end of the table? If there is a way, then I could
> > test the idea without writing any code at all.
>
> Not sure, but you could try using the ctid column.
>
An alternative is to do a bulky ordered
The basic idea is to change register_dirty_segment() to
register_opened_segment().
That is, we don't care if a segment is dirty or not, if someone opened it,
then we will fsync it at checkpoint time. Currently,
register_dirty_segment() is called in mdextend(), mdwrite() and
mdtruncate(), this is c
"Tom Lane" <[EMAIL PROTECTED]> writes
> On platforms that I'm familiar with, an fsync call causes the kernel
> to spend a significant amount of time groveling through its buffers
> to see if any are dirty. We shouldn't incur that cost to buy marginal
> speedups at the application level. (In other
"Tom Lane" <[EMAIL PROTECTED]> writes
> It would be a reasonable
> bet for a kernel designer to assume that fsync() is generally going to
> have to wait for some I/O and so a bit of CPU overhead isn't really
> going to matter.
Reasonable.
>
> Adjusting such a global refcount would require global
<[EMAIL PROTECTED]> writes
> I have done the following Post to PSQL Performance, but Richard Huxton
> say it
> might be a better Idea to post it again on you List so i forward the
> message.
...
> It is exiting to see thadt Verison 8.0 has Tablespaces like ORACLE and
> DB/2,
> but i need Partition
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
""Magnus Hagander"" <[EMAIL PROTECTED]> writes
>
> Yeah, that should work. With one shared memory segment and one event for
> each process, of course. The event can be the same one as is used now,
> only it has to be named so it can be accessed externally.
>
Yes, the shared memory segment size co
""Magnus Hagander"" <[EMAIL PROTECTED]> writes
> > I assume that this will not break the use of pg_ctl to
> > deliver pseudo-signals. That would be a show-stopper.
>
> It shouldn't, but there is one concern: it has to be created in the
> global namespace. On older windows there is no different, bu
-- First part ---
In md.c/RememberFsyncRequest():
if (hash_search(pendingOpsTable, &entry, HASH_ENTER, NULL) == NULL)
ereport(FATAL,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of memory")));
pendingOpsTable uses "MdCxt" to allocate memory. So if "out of memory", we
actually have no
"Tom Lane" <[EMAIL PROTECTED]> writes
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
>
> "Unsafe" is a bit of an overstatement, when you evidently haven't
> analyzed the consequences of either choice of error level. That is,
> w
""Magnus Hagander"" <[EMAIL PROTECTED]> writes
>
> It may not be necessary at all. But what I meant is I don't know what
> the default permissinos ar eon a shared mem/event object in the global
> namespace. On the naemd pipe it's "creator/owner full" (so the postgres
> account itself can issue ki
I have simplified the code according to the discussion. Now there is no pipe
or signaling threads, process access shared memory directly to pass signals.
Seems everything works fine except pg_ctl. I now have two choices to fix it:
(1) Record Shared memory name (it is already there) and the offset
""Magnus Hagander"" <[EMAIL PROTECTED]>
> > Why not just use the pid in teh name, and have one segment
> > per backend?
> >
> > Being used only for signals you mean? That might work.
>
> That was my idea. We'll end up using three global namespace objects
> (mutex+event+shared memory) instead of
How do we force the dependency according to pg_dependency records? Seems
pg_dependency just records them and we follow the records by hand on
create or delete ...
Regards,
Qingqing
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> Deletion scans the entries and either deletes the dependent objects or
> raises error. It's not "by hand" particularly, at least not for
> anything outside dependency.c. If you were to write code that deleted
> objects directly without going through the
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> That should be impossible because drop/create take out locks at the
> table level. Can you provide a reproducible test case?
>
To reproduce it:
Concurrently execute the following sql script serveral times:
("without oids","tablespace testsp" should be op
"Tom Lane" <[EMAIL PROTECTED]> writes
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> > In general, code snippet like this:
>
> > if (hash_search(..., HASH_ENTER, ...) == NULL)
> > action_except_elog__ERROR__;
>
> > are conside
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> Why bother? Just write each page when you need to --- there's no law
> that says you must use P_NEW. The hash index type does something pretty
> similar, IIRC.
>
Is there any performance benefits if we have a mdextend_several_pages()
function in md.c? S
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> I very seriously doubt that there would be *any* win, and I doubt even
> more that it could possibly be worth the klugery you'd have to do to
> make it happen. Bear in mind that index access methods are two API
> layers away from md.c --- how will you tra
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> I very seriously doubt that there would be *any* win
>
I did a quick proof-concept implemenation to test non-concurrent batch
insertion, here is the result:
Envrionment:
- Pg8.0.1
- NTFS / IDE
-- batch 16 pages extension --
test=# insert into t
"Mark Wong" <[EMAIL PROTECTED]> writes
>
> http://developer.osdl.org/markw/postgrescvs/
>
The last two jump points looks nice! They are pulled from CVS on 5.30 and
6.1. Where the performance improvements come from? I could remember:
* 5.30: avoid unnecessary foregin key check
Seems CRC patch is
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> In other words, if FSM is wrong you will overwrite valid data? No
> thanks ... this is guaranteed to fail under simple concurrent usage,
> let alone any more interesting scenarios like FSM being actually out of
> date.
>
You are welcome ;-). The FSM race
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> This is not an issue except if the system might actually try to recover;
> which is not the case in the postmaster snippet you mention.
>
Yeah, you are right. I scratched elog/ereport(FATAL/PANIC), only found this
one might be a suspect:
In _hash_expand
"Bruce Momjian" writes
>
> One goal for 8.1 is to move /contrib/pg_autovacuum in to the backend. I
> think it has to be done in four stages:
>
> o move it into the backend and have it start/stop automatically
The start/stop routine is quite like Bgwriter. It requires PgStats to be
turned on. If
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> A small problem here is that until you get at least to step 3
> (backend-standard error handling), none of it is going to be acceptable
> to commit. So I don't entirely buy Bruce's notion of bite-size pieces
> of work. You can certainly work on it in tha
1 - 100 of 313 matches
Mail list logo
